Swipe Interactions
Swipe Interactions
Swipe interactions are touch gestures where users drag their fingers across the screen in a direction to trigger actions or navigate. These interactions are fundamental to mobile user experience, enabling efficient navigation, content dismissal, and action revelation. Cross-platform design systems must address platform-specific swipe conventions while providing consistent patterns within their component libraries.
What Are Swipe Interactions
Swipe interactions translate finger movement into application actions. Horizontal swipes might navigate between views, reveal list item actions, or dismiss content. Vertical swipes might refresh content, dismiss bottom sheets, or scroll through content. The direction, distance, and velocity of swipes all influence the resulting behavior.
Platform conventions heavily influence swipe expectations. iOS users expect right-to-left swipes on table cells to reveal delete actions. Android users expect similar patterns with slightly different visual treatment. Both platforms use vertical swipes for pull-to-refresh. These conventions create muscle memory that applications should leverage.
Swipe interactions provide efficiency that button-based interactions cannot match. Experienced users can perform swipe actions faster than locating and tapping buttons. However, swipes are hidden interactions that new users may not discover without guidance.
How Swipe Interactions Work
Swipe-to-reveal patterns expose actions on list items. Users swipe horizontally to reveal action buttons (delete, archive, share) without navigating to a detail view. This pattern increases efficiency for common actions on item collections.
Swipe-to-Reveal Patterns
iOS Convention:
- Swipe left to reveal trailing actions (destructive first)
- Swipe right to reveal leading actions (positive first)
- Full swipe completes primary action
- Actions appear as colored rectangles with icons/text
Android Convention:
- Swipe reveals background with action indication
- Full swipe typically completes the action
- Background color indicates action type
- Less common to reveal multiple actions
Swipe-to-dismiss removes content from view. Bottom sheets, modals, and cards often support swipe-down to dismiss. This pattern feels natural because it mimics pushing unwanted items away. Dismiss thresholds and momentum determine when swipes commit versus cancel.
Swipe navigation moves between views or pages. Onboarding flows, image galleries, and tab content often support horizontal swipe navigation. This pattern must not conflict with platform back navigation gestures.
Swipe velocity and distance calculations determine action commitment. Quick swipes might complete actions that slow swipes would not. Distance thresholds distinguish intentional swipes from accidental touches. These calculations significantly affect how natural swipes feel.
Key Considerations
- Platform back gesture conflicts must be avoided
- Swipe thresholds affect perceived responsiveness
- Animation during swipe provides feedback
- Undo mechanisms support recovery from swipe actions
- Accessibility alternatives must accompany swipe actions
- Testing requires actual swipe gestures on devices
Common Questions
How do design systems specify swipe thresholds and physics?
Threshold specifications define when swipes commit actions. Distance thresholds might require 40% travel before commitment. Velocity thresholds might commit quick swipes before reaching distance thresholds. These specifications ensure consistent behavior across component implementations.
Animation curves during swipe provide physics-based feedback. Content following finger movement should feel responsive. Rubber-band effects at boundaries indicate limits. Release animations should feel natural, whether completing or canceling actions.
Platform-specific tuning may be necessary. iOS and Android have different feeling swipes in native applications. Design systems should specify whether to match platform feel or maintain cross-platform consistency.
Token-based configuration allows consistent threshold values across components. Swipe distance thresholds, velocity thresholds, and animation durations can be defined as tokens, ensuring consistent feel across all swipeable components.
How do swipe interactions coexist with scrolling?
Directional disambiguation distinguishes swipes from scrolls. If a user initiates horizontal movement in a vertically scrolling list, the system must determine intent. Initial direction, consistency of movement, and locking behavior all contribute to correct disambiguation.
Gesture locking commits to one interpretation. Once the system determines a gesture is a swipe versus a scroll, it should lock to that interpretation for the gesture duration. Switching interpretations mid-gesture feels broken.
Nested scrolling contexts require careful handling. A horizontally swipeable card within a vertically scrolling list requires clear rules for when horizontal swipes activate versus when they scroll the card content.
Testing diagonal gestures reveals disambiguation issues. Users do not swipe in perfect horizontal or vertical lines. Testing with realistic gesture angles ensures disambiguation works correctly.
What accessibility considerations apply to swipe interactions?
Every swipe action needs a non-swipe alternative. Users who cannot perform swipe gestures must still access all functionality. Edit buttons revealing action menus provide traditional alternatives to swipe-to-reveal.
VoiceOver and TalkBack change swipe meaning. Swipe gestures navigate between accessible elements rather than triggering application actions. Applications must provide actions through accessibility menus or element actions.
Motor accessibility settings may adjust gesture sensitivity. iOS and Android allow users to adjust touch sensitivity. Swipe implementations should work correctly with these adjustments.
Custom actions in accessibility APIs expose swipe actions to assistive technology. iOS custom actions and Android accessibility actions make swipe-equivalent functionality available without gesture performance.
Summary
Swipe interactions provide efficient touch-based actions for navigation, dismissal, and action revelation. Cross-platform design systems must specify swipe thresholds, animation physics, and visual feedback while avoiding conflicts with platform gestures. Accessibility alternatives ensure all users can access swipe functionality regardless of motor ability or assistive technology use.
Buoy scans your codebase for design system inconsistencies before they ship
Detect Design Drift Free