How to Achieve Stable 60 FPS in Mobile Animations

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
How to Achieve Stable 60 FPS in Mobile Animations
Complex
~2-3 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    562

How to Achieve Stable 60 FPS in Mobile Animations

We often see that 60 FPS means 16.67 ms per frame. If any frame takes more than 17 ms, Instruments will show a dropped frame. On 120 Hz displays (ProMotion), the threshold is even tighter: 8.3 ms. Users of iPhone 13 Pro and Pixel 8 physically feel this. Our task is to stay within this limit under any scenario.

Why Animation Stutters on Real Devices

Before optimization, open Xcode Instruments with the Core Animation template. Run on a real device (the simulator doesn't count: it has a different GPU). Watch two graphs: FPS and CPU Usage. Red bars on the FPS graph indicate dropped frames.

On Android, use Android Profiler in GPU/CPU mode plus Systrace for detailed tracing. In Developer Options, enable Profile GPU Rendering (displays bars on screen): if the orange zone (Draw) and red zone (Sync/Upload) regularly exceed the 16ms line, there's a problem.

A typical finding: animating shadow properties (shadowRadius, shadowOffset on CALayer) recalculates Gaussian blur on the CPU every frame. On an iPhone SE 2nd gen, this can take 8–10 ms just for the shadow.

The Main Principle: GPU Layers vs. CPU Rendering

Animating only transform and opacity is not a recommendation—it's a law of performance. These properties are processed directly by the Compositor thread without main thread involvement and without calling drawRect:.

Everything else triggers the Layout → Display → Prepare → Commit cycle:

Property Rendered On Dropped frames
transform, opacity GPU Compositor No
backgroundColor GPU (CALayer) Rarely
bounds, frame CPU → GPU Often
cornerRadius + masksToBounds CPU (offscreen) Often
shadowPath (static) GPU No
shadowRadius (dynamic) CPU Very often

cornerRadius with masksToBounds = true causes offscreen rendering. For each such layer, Core Animation performs an additional render pass. In Instruments: Debug → Color Offscreen-Rendered highlights them yellow. Fix: set layer.shadowPath statically or use a vector image mask.

How to Identify Problematic Animations: UIKit

shouldRasterize — Use With Caution

layer.shouldRasterize = true caches the layer as a bitmap. It helps if content doesn't change. It kills performance if it does: the cache is invalidated every frame and redrawing becomes more expensive than without it. Check via Instruments → Color Hits Green and Misses Red: red means invalidation, no help.

drawRect vs. CALayer

Overriding drawRect: is a nuclear option. If it's called during animation (e.g., bounds change), the main thread is busy drawing. Alternative: put static content in a separate CALayer with contents = image.cgImage, animate only transform.

CADisplayLink for Custom Animations

If writing custom animations with CADisplayLink, tie it to preferredFramesPerSecond:

let displayLink = CADisplayLink(target: self, selector: #selector(tick))
displayLink.preferredFrameRateRange = CAFrameRateRange(
    minimum: 60,
    maximum: 120,
    preferred: 120
)
displayLink.add(to: .main, forMode: .common)

On ProMotion devices, this allows animations to run at 120 FPS. Without specifying the range, the system might lock to 60 even on a 120 Hz display.

Lottie: Common Performance Issues

Lottie defaults to .automatic render mode. On complex animations with masks and trim paths, this often means CPU rendering. Force switch:

animationView.renderingEngine = .coreAnimation

The Core Animation engine renders via CALayers without main thread participation. Limitation: some complex effects (gradients via trim paths, certain blending modes) are not supported. Check with Lottie Diagnostics.

More about working with LottieTo reduce load, we recommend replacing complex masks with simple shapes or using vector graphics.

Compose: Recommendations

Use Modifier.graphicsLayer instead of directly changing layout parameters:

// Bad: triggers relayout every frame
Box(modifier = Modifier.size(animatedSize))

// Good: only GPU transform, layout stable
Box(modifier = Modifier
    .size(100.dp)
    .graphicsLayer { scaleX = animatedScale; scaleY = animatedScale }
)

graphicsLayer works similarly to layer.transform in UIKit—outside the layout pass.

Avoid using remember { mutableStateOf() } inside animation lambdas. Every state update via mutableStateOf triggers recomposition. Use Animatable directly, or animateFloatAsState which updates only the graphicsLayer without recomposing the screen.

Typical Optimization Cases from Our Practice

In a client's app, a list with custom cells dropped to 40 FPS during scrolling. Cause: each cell had layer.cornerRadius = 12 with masksToBounds = true and layer.shadowRadius = 8. Double offscreen render pass per cell. Solution: corner radius via UIBezierPath mask (single GPU pass), shadow via shadowPath with a precomputed CGPath. FPS returned to a stable 60. We guarantee similar results when working with your project.

Performance Comparison: UIKit vs. Compose

Technology Typical FPS Drop Main Thread Load Recommendation
UIKit with transform/opacity 0–2% Low Animate only these properties
UIKit with bounds/corner 10–20% High Replace with GPU layers
Compose with graphicsLayer 0–5% Low Use graphicsLayer
Compose with mutableStateOf 5–15% Medium Use Animatable

Optimization Process

  1. Profile with Instruments / Android Profiler on real devices (at least one slow device from the target audience).
  2. Identify offscreen rendering, expensive draw calls, CPU animations.
  3. Fix one by one, measuring after each change.
  4. Regression test on devices of different tiers.

What the Work Includes

  • Detailed audit of current animations with a report.
  • Fix problematic areas (replace properties, optimize layers).
  • Remeasure FPS on control devices.
  • Recommendations for further development.

We have been in mobile development for over 7 years and have optimized animations in 20+ projects. Our specialists are certified by Apple and Google. Apple Core Animation Programming Guide and Android Profiler are our primary tools.

Contact us to request an audit or optimization of your application. Get a consultation on specific issues—we will evaluate your project in one day.

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.

Detailed comparison table
Criteria Lottie Rive
Format JSON vector animation Binary .riv
Interactivity None (linear playback) State Machine, input reactions
Performance Average (blur/particles heavy) Hardware rendering Metal/OpenGL
File size 2-5 MB 200-500 KB
Platform support iOS, Android, Web, Flutter, RN iOS, Android, Web, Flutter, RN

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.