Physics-Based Spring Animations in iOS Apps

Standard animations with fixed duration and easing curves look unnatural, especially in interfaces where responsiveness is critical: product cards, switches, pull-to-refresh. Spring animations solve this with a physical spring model. In one project, we replaced ease-in-out with spring animation for a product card — conversion increased by 12%. This isn't just cosmetic: correct physics boosts engagement and reduces cognitive load.

Why physics-based spring animations outperform standard ones?

Spring animations use spring physics: the element overshoots the target and bounces back, creating an elastic feel. Unlike standard easing curves, spring animations respond to gesture speed, direction, and can be interrupted. For example, when dragging a card upward, it elastically reaches the target position considering the release speed. For simple effects, usingSpringWithDamping works, but for interactive scenarios, a full physics model is needed: mass, stiffness, damping, initialVelocity. Spring animations are 3x more realistic than standard ones according to user ratings (A/B tests). Development time savings — up to 20% by avoiding complex easing curves.

How to set parameters for a realistic effect?

Spring animation parameters: mass, stiffness, damping, and initial velocity. For UIKit, use UISpringTimingParameters:

let timingParams = UISpringTimingParameters(
    mass: 1.0,
    stiffness: 170,
    damping: 26,
    initialVelocity: CGVector(dx: 0, dy: 0)
)
let animator = UIViewPropertyAnimator(duration: 0, timingParameters: timingParams)
    animator.addAnimations {
        self.cardView.transform = CGAffineTransform(scaleX: 0.95, y: 0.95)
    }
    animator.startAnimation()

Recommended values:

• stiffness: 300, damping: 30 — fast elastic animation (press feedback).
• stiffness: 120, damping: 14 — slow soft spring (bottom sheet appearance).
• stiffness: 400, damping: 40 — stiff without overshoot (switch).

Don't set duration — with spring timing it's ignored, the animation ends by spring decay.

Mass determines inertia: larger mass means longer oscillation buildup. Stiffness controls oscillation frequency: high values give fast but short movements. Damping is the decay rate: low values cause multiple oscillations, high values cause sluggish return. Initial velocity is critical for gesture-driven scenarios.

Recommended parameters for typical cases

What to do if animation is interrupted by a gesture?

In gesture-driven interfaces (e.g., user drags a card and changes mind), the animation should smoothly reverse with the current velocity. In UIKit, use UIViewPropertyAnimator.isInterruptible = true and continueAnimation(withTimingParameters:durationFactor:). In SwiftUI, correctly set initialVelocity via @GestureState and withAnimation. Otherwise, a jerk occurs due to velocity reset. More on interruptible animations in the UIViewPropertyAnimator documentation.

Comparison of APIs across iOS versions and SwiftUI

Step-by-step spring animation setup in UIKit

1. Define the final state of the element (frame, transform, alpha).
2. Choose parameters: mass (1.0), stiffness (150–300), damping (15–30) based on desired elasticity.
3. Set initialVelocity (CGVector) from current gesture speed if the animation is interrupted.
4. Create UISpringTimingParameters and pass to UIViewPropertyAnimator.
5. Add animations and call startAnimation().
6. For interruption — use isInterruptible and continueAnimation.

How we integrate spring animations

We offer a full implementation cycle:

• UX analysis: identify key interaction points where spring animations improve responsiveness.
• Physics model design: tune mass, stiffness, damping for each scenario.
• Implementation in UIKit (Swift) or SwiftUI, handling interruptions and velocity matching.
• Testing on different device generations (iPhone SE, iPhone Pro, iPad).
• Deployment and performance monitoring (FPS, GPU time).

What's included in the work

• UX analysis and physics parameter tuning.
• Animation implementation in UIKit or SwiftUI with interruption handling.
• Integration into existing UI (Autolayout, SwiftUI layout).
• Testing on multiple device generations (iPhone SE, iPhone Pro, iPad).
• Documentation of parameters and settings.
• 30-day post-delivery support.

Deliverables: commented source code, animation parameter documentation, device-specific tuning. We guarantee 30-day support after handover. Our experience: 5+ years of native iOS development and 30+ projects with custom animations. We are certified Apple developers, so we know all the nuances.

Ready to make your interface responsive? Get a consultation — we'll assess the complexity and propose the best solution. Request a project estimate — drop us a line.

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.