Interactive Gesture Animations for Mobile Apps

Interactive Gesture Animations for Mobile Apps

We build gesture animations that don’t stutter or feel cheap. Our team has 5+ years in mobile development and over 20 projects with custom animations. The difference between gesture and regular animations is that gesture animations are interruptible. A user drags a card, changes their mind midway, and it must return with physically accurate behavior—not just snap back, but spring with accumulated velocity. That’s interactive gesture animation—animation driven by the finger in real time.

If you’re unsure about timelines, contact us—we’ll estimate the scope and cost for free.

Why Velocity Synchronization Is the Main Challenge

The key parameter of any gesture animation is the connection between the gesture velocity at release (gestureRecognizer.velocity) and the final animation parameters. If they aren’t synchronized, you get a “jump”: the finger moves at one speed, but the object finishes at another.

On iOS, UIViewPropertyAnimator handles this natively via continueAnimation(withTimingParameters:durationFactor:):

@objc func handlePan(_ gesture: UIPanGestureRecognizer) {
    let translation = gesture.translation(in: view)
    switch gesture.state {
    case .changed:
        animator?.fractionComplete = translation.y / totalDistance
    case .ended:
        let velocity = gesture.velocity(in: view)
        let springVelocity = abs(velocity.y) / (totalDistance - translation.y)
        let timing = UISpringTimingParameters(dampingRatio: 0.8,
                                              initialVelocity: CGVector(dx: 0, dy: springVelocity))
        animator?.continueAnimation(withTimingParameters: timing, durationFactor: 0)
    default: break
    }
}

fractionComplete directly maps animation progress to gesture input. A value of 0.0 is start, 1.0 is end. The user literally drags the animation along. For deeper understanding, see UIKit documentation.

How to Implement Swipe-to-Dismiss Cards

The classic Tinder or to-do list pattern: the card follows the finger, at a threshold it flies away, below the threshold it returns.

Three parameters to calibrate:

• Release threshold—usually 30-40% of screen width or velocity > 800 pt/s
• Rotation angle—transform = CGAffineTransform(rotationAngle: translation.x / screenWidth * 0.3) creates physical feel
• Dismissal animation speed—must match gesture velocity, otherwise the card “hangs” in mid-air

On Android, we use ViewDragHelper or ItemTouchHelper for RecyclerView. ItemTouchHelper is good for lists but limited—custom feedback drawing requires overriding onChildDraw. In Flutter, Dismissible for simple cases, GestureDetector + AnimationController with fling() for complex ones. fling() directly accepts velocity from DragEndDetails.velocity.pixelsPerSecond—exactly the synchronization we explained.

Platform Comparison

Pull-to-Refresh with Custom Animation

Standard UIRefreshControl and SwipeRefreshLayout do not support custom indicator animations. We implement via ScrollView with negative offset: when contentOffset.y < -threshold, we drive a custom indicator with progress = abs(offset.y) / threshold. Lottie animation, bound to setProgress(), gives arbitrary design. Use LottieAnimationView.setProgress() on iOS and LottieDrawable.setProgress() on Android to precisely link animation progress to offset.

Drag & Drop with Physical Behavior

On iOS—UIDragInteraction + UIDropInteraction for cross-app DnD, UILongPressGestureRecognizer + UIViewPropertyAnimator for in-app. Important: when lifting an item, add a scale animation (1.05) and shadow—visual feedback “I’m holding the object.” On return—UISpringTimingParameters with high dampingRatio (0.9) for a “soft landing”.

Testing and Calibration

1. Enable Slow Animations in the simulator for visual debugging.
2. Run Xcode Instruments—Animation Hitches on a physical device, keep GPU frame time under 16ms (60fps).
3. Test all states: hold, fast swipe, retouch during animation.
4. Ensure animation parameters (damping, stiffness) match the design.

Gesture animations must be tested on physical devices—emulators don’t reproduce accurate touch physics. Slow Animations in the simulator helps catch artifacts, but real feel is only on hardware. On Android, check GPU frame time via Profile GPU Rendering. For release builds, ensure ProGuard does not remove Lottie classes: add -keep class com.airbnb.lottie.** { *; }.

To calibrate animations for your design, contact us—we’ll account for all nuances.

What’s Included

• Development of animation prototype with parameter calibration
• Integration with your design (Lottie, Rive, or Core Animation)
• Testing on 5+ physical devices
• Delivery of documented source code
• Support for 2 weeks after release

Typical timeline: 2–3 days per gesture animation pattern, including integration and calibration. Cost is determined after analysis of your specific requirements. We guarantee smooth 60fps on all devices. Get a consultation for your project—contact us for an evaluation.

Animations in Mobile Apps: Lottie, Rive, Spring, and Reanimated

We've built animations for dozens of projects — from game interfaces to bank-grade applications. We know how to achieve 120 fps even on Android with ProGuard. If an animation stutters, the problem isn't the tool but the approach. Below we show how we choose between Lottie and Rive, why Spring physics beats UIView.animate, and how Reanimated 3 pushes 60 fps on older devices. Get a consultation for your project — we'll assess the animation layer for free.

Why does UIView.animate break on complex scenarios?

UIView.animate(withDuration:) and ObjectAnimator on Android are fine for simple transitions. But as soon as the animation becomes interactive (user drags an element, speed depends on gesture), a different approach is needed.

On iOS, the right tool for gesture-driven animation is UIViewPropertyAnimator. It allows pausing, reversing, and modifying the animation in progress. A typical use case: a bottom sheet that follows the finger, continues with inertia after release, and snaps to the nearest position. With UIView.animate, this is either not possible or requires manual physics.

In SwiftUI, withAnimation works out of the box, but interactivity is limited — there's no direct analog to UIViewPropertyAnimator. A workaround is using .gesture(DragGesture()) + @GestureState + explicit position calculation. Or move to SwiftUI Animations API with Animation.spring(duration:bounce:) from iOS 17.

How does React Native Reanimated bypass the JS bridge?

React Native Animated API executes animations on the JS thread — this causes jank when the bridge is busy. Reanimated 3 solves this with worklets: functions that compile and run directly on the UI thread without crossing the JS bridge.

Example: parallax scroll header. With basic Animated.Value, fast scrolling drops FPS to 40-45 on mid-range Android. With Reanimated using useAnimatedScrollHandler, it stays at a stable 60 fps because all position calculations happen on the UI thread.

Reanimated 3 with useSharedValue, useAnimatedStyle, and withSpring/withTiming is the current standard for animations in React Native. Gesture Handler v2 is tightly integrated: useAnimatedGestureHandler replaces PanResponder and also runs on the UI thread.

Why can Lottie reduce FPS on Android?

Lottie exports After Effects animation as JSON. On iOS with lottie-ios it's stable, but on Android, complex effects (blur, particles, gradients) via Canvas rendering can cause drops to 30-40 fps. The solution: either simplify the animation or use Rive with hardware rendering. We tested: a 5 MB Lottie file with blur on Xiaomi Redmi Note 10 gave 48 fps, while the same animation in Rive (.riv 400 KB) gave 60 fps.

Lottie vs Rive: What to choose for interactive interfaces?

Both tools solve the task of "designer creates animation, developer adds the file." But they differ fundamentally.

The choice is simple: static decorative animation (splash screen, onboarding illustrations) — Lottie. Interactive UI elements with states — Rive. For example, a button with hover, pressed, loading, success states — one Rive animation with four states versus four separate Lottie files.

Spring physics and Hero transitions: how to achieve naturalness?

Spring animation feels natural because it simulates physics — mass, stiffness, and damping. In SwiftUI: Animation.spring(response:dampingFraction:). In Android Compose: spring(dampingRatio = Spring.DampingRatioMediumBouncy).

For Hero transitions (an element "flies" between screens), on iOS use UIViewControllerTransitioningDelegate + UIViewControllerAnimatedTransitioning. In SwiftUI with iOS 17 — matchedTransitionSource + navigationTransition(.zoom). On Flutter — Hero widget, which works out of the box.

How to avoid common mistakes in Hero transitions?

The animation starts fine, but on the target screen the element "jumps" to the final position. The reason: AutoLayout constraints are applied before the animation completes. Solution: call layoutIfNeeded() inside the animation block or use transform instead of frame changes.

What's included: animation layer turnkey

• Integration of Lottie/Rive files into the design system
• Code for gesture-driven transitions (bottom sheets, drawers, carousels)
• Testing on real devices (iOS 15–17, Android 10–14)
• Animation documentation (architecture, state keys)
• Support for design updates (30-day warranty)

We have 5+ years of experience in mobile development, over 30 projects with animations, certified iOS/Android developers.

Timelines

• Basic screen transitions and micro-interactions — 1 week.
• Lottie/Rive integration with design system — 3-5 days after receiving final files.
• Custom gesture-driven interactivity (sheet, drawer, physics carousel) — 1-2 weeks.

Contact us — we'll add animations turnkey in 2 weeks. First consultation is free.