Kinetic physics and swipe gestures
The lock screen on iOS slides up. Rauno Freiberg reads that motion as a lesson: the lock screen is, in essence, just an overlay that can be dismissed by swiping up, and within that framing so is an app. Learn to unlock and you have already learned to dismiss an application. In Invisible Details of Interaction Design he then looks closely at what happens when you do dismiss an app into the Dynamic Island. The gesture retains the momentum and the angle at which it was thrown. It is never perfectly centred and never consistent in timing, because you are not.
His comparison is a playing card. The movement builds on our sense of physics from the real world, like how swiping a card across a table would feel. He is careful about the limits of the comparison: a real card would exhibit less bounce, since it is conceptually lighter and does not magnetically morph into something at the end of its flight. The interface is not simulating a card. It is borrowing enough of the card’s behaviour that your hand already knows what to expect.
The second question in this section is the one that sounds trivial until you build it: when does a swipe trigger an action? The naive model is press down, move a little, release, then act. After building a few touch interactions in SwiftUI, Rauno realised that is not always the expectation. Sometimes the action should happen during the swipe. His rule is that lightweight actions, such as displaying overlays or opening search, feel more natural to trigger while swiping, after an arbitrary amount of distance. He illustrates it with his SwiftUI prototype of Jason Yuan’s MercuryOS, which unlocks at the moment the titles snap into place: “It feels expected to trigger an action when elements moving during the gesture reach their logical, final position.” Waiting for the gesture to end would make that interface feel broken and give less affordance.
Destructive actions are the opposite case. The iOS App Switcher will never dismiss an app before the gesture ends, no matter how far you have dragged or how much of the app is already off-screen. Rauno explains why in terms of intent. Dismissing an app is destructive, and it would not feel nice for the app to vanish halfway through a swipe. What if you changed your mind and accidentally crossed the threshold? You could lose progress. Triggering on gesture end, regardless of distance, is how the interface makes sure it responds to what you meant rather than to where your finger happened to be.
The same end-triggered rule buys you something else: peeking. Because nothing commits until you let go, it is lightweight to briefly drag another screen into view while scanning for an app, without committing to it, and to interrupt the gesture by changing direction. Figure 1 lets you feel the difference. Drag the card past the dashed line in each mode and watch when the action fires: the lightweight action triggers during the swipe once you have moved far enough, the destructive one waits for release. Try crossing the line and then dragging back before letting go.
What the figure should leave you with is that the trigger timing is a design decision, not a default, and that the right answer depends on the cost of being wrong. If an action is cheap to undo, let the interface respond as soon as the moving elements reach their final position; the early response is the affordance. If it is expensive, keep the whole gesture reversible and commit only on release. And in both cases let the thing you are dragging keep the momentum and angle you gave it, because a gesture that lands identically every time stops feeling like yours.