Why your app’s feedback can feel unfinished

Quality lives in the response

A polished screen can still feel unfinished when its response to input is uncertain. A dragged object snaps into place without acknowledgement. A save appears to finish before it really has. A tiny adjustment produces a large, unrelated buzz.

Haptics are one part of that response. Adding them everywhere will not rescue a confusing interaction, and their absence is not automatically a defect. The useful question is whether each response helps someone understand what just happened.

Audit one complete task

Choose a task with a beginning, an outcome and a plausible failure: save a document, rearrange a list or upload a file. Use a real iPhone and work through it at ordinary speed. Then repeat it quickly, with sound off, and with haptics off.

Write down the state changes rather than just the controls you touched:

This table makes a useful review note. Add columns for current behaviour, proposed change and test result. It often exposes a missing state before it exposes a missing haptic.

Listen for disagreement

Look for three kinds of disagreement. Meaning: the cue suggests success before the operation completes. Weight: a small visual motion is accompanied by an overwhelming impact. Timing: the tactile response arrives after the visible result.

Fix the state transition first. A perfectly timed success haptic is still wrong if the save failed. Next, align the feedback with the transition. Only then tune its character.

Standard feedback is often enough. UIKit separates selection, impact and outcome feedback, while SwiftUI can play feedback when a value changes. These are useful defaults for familiar interactions. UIKit feedback generators, SwiftUI sensory feedback

A more deliberate save flow

Imagine a save button that immediately plays a long buzz, even though the request can take several seconds. That feedback neither confirms the eventual outcome nor explains the wait.

Try this revision: keep the button’s visible press state; show progress while work runs; update the saved status on success; use an outcome haptic only at that success transition. On failure, retain the unsaved state and show the error. Do not play the same completion cue on both paths.

Now test a fast save, a slow save, a failure, two rapid presses and leaving the screen before completion. Those cases tell you more than repeatedly auditioning the happy-path sound.

If latency remains, ask engineering where resources are prepared. playPattern(from:) can start a stopped engine itself, adding delay. Starting and preparing before the critical interaction is a separate task from choosing the pattern. Core Haptics playback

Leave room for quiet

Do not give every visible change the same importance. A deliberate snap point may deserve feedback; every pixel traversed on the way there probably does not. An error may need a cue; refreshing a timestamp usually does not.

Repeat your task several times before signing it off. Ask whether the cue still clarifies the interaction once the novelty is gone. Apple’s guidance recommends restraint and consistent meanings, which are better review goals than simply counting how many controls vibrate. Playing haptics

Turn the audit into a small change

Choose one confusing moment, write down its intended meaning, and change one thing at a time. Compare the original and revised interaction on the same device. Keep the visible and accessible information complete in both versions.

Designing haptics without writing code shows how to audition a custom cue. A haptic design system helps preserve the decision once the first screen feels right.