A swipe gesture is a touch interaction in which the user places a finger on the screen and slides it in a direction before lifting it, so that the system recognizes the movement as a command rather than a tap. In mobile UX, swipes are used to scroll, page between views, reveal hidden actions, dismiss items and navigate the system, which makes them one of the most frequent inputs on any touchscreen device.
A swipe differs from a tap by its movement distance and direction, and from a slow drag by its speed and intent. Because swipes carry no visible label, their success depends on clear affordances, consistent conventions and careful handling of conflicts with other gestures.
How a swipe gesture is recognized
The operating system receives a stream of touch events: touch down, a series of move events and touch up, each with coordinates and a timestamp. A gesture recognizer decides that a swipe occurred when the finger travels beyond a touch slop threshold, a small distance that separates intentional movement from finger jitter, and when the motion follows a dominant direction.
Recognizers also measure velocity at release. A short, fast flick can count as a swipe even if the distance is small, while a long, slow movement is often treated as a drag that follows the finger. Many interfaces combine both: content tracks the finger during the drag, and the release velocity decides whether it completes the action or snaps back.
| Parameter | What it measures | Typical design consideration |
|---|---|---|
| Touch slop | Minimum movement before a gesture starts | A few density-independent points to ignore jitter |
| Distance threshold | How far the finger must travel to commit | Often a fraction of the item or screen width |
| Fling velocity | Speed at the moment of release | Fast flicks commit even below the distance threshold |
| Direction tolerance | Allowed angle from the main axis | Separates horizontal swipes from vertical scrolling |
| Edge zone | Area near the screen edge | Reserved for system gestures on many devices |
Common types of swipe gestures
Swipes serve several distinct purposes, and users learn them as conventions rather than as discoverable controls. The table lists the main patterns in mobile interfaces.
| Pattern | Direction | Typical purpose | Example |
|---|---|---|---|
| Scroll swipe | Vertical or horizontal | Move through content | Scrolling a feed |
| Paging swipe | Horizontal | Switch between peer views | Image carousel, onboarding screens |
| Swipe to reveal | Horizontal on a list row | Show contextual actions | Archive or delete buttons in a mail list |
| Swipe to dismiss | Down or sideways | Close a sheet, card or notification | Dismissing a bottom sheet |
| Edge swipe | From a screen edge inward | System or back navigation | Gesture navigation back action |
| Pull to refresh | Down at the top of a list | Reload content | Refreshing an inbox |
Some patterns are system-owned. On devices with gesture navigation, a swipe up from the bottom edge goes home and a swipe from the side edge goes back, so apps must avoid placing their own critical swipes in those system gesture zones.
Swipe gestures compared with other touch interactions
Choosing a swipe instead of a tap or a long press changes discoverability, speed and error risk. The comparison helps decide which interaction suits a given action.
| Interaction | Discoverability | Speed for experts | Accidental activation risk |
|---|---|---|---|
| Tap | High, visible button | Fast | Low |
| Swipe | Low to medium, needs hints | Very fast | Medium during scrolling |
| Long press | Low, hidden | Slow | Low |
| Drag | Medium, handle can be shown | Moderate | Low to medium |
| Pinch | Medium for media content | Fast | Low |
The usual rule is that swipes should be shortcuts, not the only path. A swipe-to-delete row should also offer the action through a menu or an edit mode, so users who never discover the gesture can still complete the task.
Designing reliable swipe interactions
A well-designed swipe gives continuous visual feedback: the item moves with the finger, the revealed action changes color or icon when the commit threshold is crossed, and a light haptic tick confirms the moment. This feedback lets users cancel by reversing direction before they lift the finger.
- Show an affordance, such as a partially visible next card or a hint animation on first use.
- Keep directions consistent across the app, for example always archiving with the same swipe direction.
- Offer undo for destructive swipes instead of a confirmation dialog that slows experts down.
- Respect the thumb zone, since horizontal swipes near the middle of the screen are easiest for one-handed use.
- Avoid gesture conflicts between nested scroll views, carousels and system edges.
Both major design systems give guidance. Material Design describes swipe-to-dismiss and list item actions with clear thresholds, and Apple’s Human Interface Guidelines recommend leading and trailing swipe actions on table rows while warning against overriding standard system gestures.
Accessibility and common pitfalls
Swipes can exclude users with motor impairments and users who rely on screen readers, because assistive technologies reassign many gestures. With VoiceOver or TalkBack active, a single-finger swipe moves the focus between elements instead of scrolling, so every swipe action needs an accessible alternative, such as a custom accessibility action or a visible button.
| Problem | Cause | Fix |
|---|---|---|
| Users never find the action | No visual hint | Add a hint animation or visible secondary control |
| Rows are deleted by accident | Low threshold, no undo | Raise the threshold and add an undo snackbar |
| Back gesture triggers instead of carousel | Swipe area overlaps the system edge | Inset the carousel or exclude a limited edge area |
| Vertical scrolling feels sticky | Direction tolerance too wide | Lock the axis after the first movement |
| Screen reader users are blocked | Action exists only as a swipe | Expose a custom accessibility action |
A non-technical view
A swipe is when you slide your finger across the screen, like turning the page of a magazine or brushing a card off a table. The phone notices which way your finger moved and how fast, and treats that movement as an instruction.
Swipes are quick once you know them, but you cannot see them, unlike a button. Good apps give small hints and always offer another way to do the same thing.
A concrete example
A team building a task manager app wanted users to complete tasks with a right swipe and postpone them with a left swipe. In early testing, several participants deleted tasks by accident while scrolling, and others never discovered the postpone action at all.
The designers raised the commit threshold to about half the row width, added a color change and a haptic tick at the threshold, and introduced an undo snackbar after every swipe. They also added a short hint animation on the first launch and kept both actions in a long-press menu with screen reader actions. In the next test round, accidental completions disappeared and most participants used the swipe within the first few minutes.