iOS haptics

Build tactile feedback for iOS apps using SwiftUI or UIKit. Preserve the app's deployment target and choose APIs available to it. Use system feedback for standard interactions and Core Haptics when the design needs an authored pattern. Hardware support and user preferences still matter. Use animate for visual motion when the two need coordination.

Design the interaction first

Inspect the affected flow, its state owner, and any existing feedback. Check native controls before adding feedback they may already provide. For a bug fix, keep the intended design unless the evidence calls for a change.

Use Experience First when deciding whether feedback helps the interaction. Name what the user should learn through touch. Apply Apple's design principles to the proposed event:

Separate press, acceptance, and completion. Give each feedback event one meaning and one owner. Keep the same meaning consistent across the feature. Prefer a small set of distinct responses over a different pattern for every control.

For each chosen event, settle its trigger, visual landmark, desired feel, and cancellation or stop condition. Include sound when it belongs to the requested experience. A sentence is enough for one event; use a table for a larger flow.

Choose the feel and the playback path

Read Designing touch, sound, and motion when choosing or tuning feedback. It covers system meanings, pattern controls, shared timing, and worked designs. Choose rhythm and duration before strength; stronger feedback cannot repair the wrong trigger.

Start with system feedback: selection for discrete changes, impact for contact and snapping, and success, warning, or error for meaningful outcomes. SwiftUI uses sensoryFeedback; UIKit uses selection, impact, and notification generators. Read Standard feedback for triggers, API availability, and implementation. Tie feedback to real state transitions or explicit events.

Use Core Haptics when the design needs a distinct rhythm, an intensity envelope, a sustained texture, or authored audio and touch on one timeline. Read Custom playback for pattern construction, AHAP, engine ownership, and recovery. A custom animation alone does not justify a custom haptic engine.

These paths share the same event design and preferences. Select one owner for each event; do not emit through both paths for the same result. Reuse the app's feedback infrastructure when it fits. A single modifier needs no global service.

Keep feedback optional and current

Honor the app's existing haptics preference and system suppression. Preserve visible and accessible confirmation when touch or sound is absent. Use hardware capabilities for custom playback, not a list of device names.

Tie feedback to the UI the user actually sees. A cancelled action must not emit completion. An old async result must not produce feedback for a new interaction. If an operation outlives its screen, let the remaining UI decide whether feedback still belongs there. When reduced motion changes the visual sequence, align the haptic with the new event timing rather than an old animation delay.

Verify behavior, then tune on a device

Use Prove It Works to match each claim to its evidence. The hardware checks below establish tactile quality and timing in the actual interaction.

Compile examples and changes for the app's supported iOS versions using the project's Swift concurrency settings. Check ordinary use, repeated outcomes, failure, cancellation, and preferences. Add tests for meaningful event-selection or lifecycle branches; a mock proves requests, not sensations.

Compare the proposed feel on supported physical hardware in the real flow:

1. Fix onset against the visible event.
2. Adjust duration and rhythm at normal and rapid interaction speeds.
3. Tune strength and sharpness without changing both at once.
4. Compare touch and sound separately, then with motion together.

For custom playback, also check first use, background return, interruptions, and stopping sustained effects. Record device and OS details. Treat power state and settings as test conditions rather than presumed explanations for failure.

For missing feedback, inspect the event, preference, hardware, owner lifetime, and playback errors. For late or repeated feedback, inspect state changes, duplicate emission, queued work, and stale callbacks before altering intensity.

Deliver the event choices, their design reasons, and the checks that ran. Include custom assets and stop/recovery behavior where used. A simulator or recording cannot establish tactile quality; explicitly name any device tuning still needed.

Design basis: Apple's haptic design principles.