Implementing Parallax Scrolling Effect in Mobile Apps

Your client asks for parallax scrolling? The first implementation often results in jank – FPS drops to 45 on devices like iPhone SE 2nd gen. We've figured out how to do it right on iOS and Android without performance dips. Our engineers, with 5+ years of experience, have implemented parallax in 30+ projects, and we're sharing the working approaches. Our services start at $500 for a simple hero parallax, with typical costs between $2,000 and $5,000 for full list implementation.

Parallax creates visual depth: the background moves slower than the content. But if you tie the animation to the main thread, you get 40 FPS instead of 60. On older Android devices, it's even worse – down to 35 FPS. We guarantee smoothness on iOS 15+ and Android 11+.

Why Parallax on the Main Thread Is Evil

Handling scroll through delegates (scrollViewDidScroll, OnScrollListener) blocks the UI thread: every frame triggers a layout recalculation. Correct approaches tie into the draw pass: layoutSubviews in UIKit, graphicsLayer in Compose, MotionLayout on Android. They avoid extra measure/layout calls, saving up to 30% of computational resources.

Choosing the Right API for Parallax Scrolling

The choice depends on the platform and complexity. Below is a table of approaches and performance:

Additionally, when using MotionLayout, FPS on Pixel 4 increased from 40 to 60 (Google animation recommendations). Our implementation using MotionLayout is 1.5x faster than naive scroll listener approach on Android.

How to Implement Parallax in 3 Steps

1. Prepare the image: Make it higher than the container by cellHeight * coefficient (0.3) on each side to avoid empty edges.
2. Bind to rendering: On iOS, use layoutSubviews in the cell; on Android, use onDrawOver in ItemDecoration or graphicsLayer in Compose.
3. Test on weak devices: Check FPS on iPhone SE 2nd gen (iOS) and Pixel 4 (Android). If drops exceed 5 FPS, reduce the coefficient to 0.2.

Implementation Examples

iOS: UIKit

override func layoutSubviews() {
    super.layoutSubviews()
    guard let superview = superview else { return }
    let cellFrameInSuperview = convert(bounds, to: superview)
    let parallaxOffset = cellFrameInSuperview.minY * 0.3
    heroImageView.transform = CGAffineTransform(translationX: 0, y: -parallaxOffset)
}

iOS: SwiftUI

ScrollView {
    LazyVStack {
        ForEach(items) { item in
            GeometryReader { geo in
                let offset = geo.frame(in: .global).minY
                Image(item.imageName)
                    .resizable()
                    .scaledToFill()
                    .frame(height: 250)
                    .offset(y: offset * 0.3)
                    .clipped()
            }
            .frame(height: 200)
        }
    }
}

Android: MotionLayout

<MotionScene>
    <Transition motion:constraintSetStart="@id/start" motion:constraintSetEnd="@id/end"
        motion:duration="1000">
        <OnSwipe
            motion:touchAnchorId="@id/nestedScrollView"
            motion:touchAnchorSide="top"
            motion:dragDirection="dragUp"
            motion:moveWhenScrollAtTop="true" />
    </Transition>
    <ConstraintSet android:id="@+id/start">
        <Constraint android:id="@+id/heroImage"
            android:translationY="0dp" ... />
    </ConstraintSet>
    <ConstraintSet android:id="@+id/end">
        <Constraint android:id="@+id/heroImage"
            android:translationY="-60dp" ... />
    </ConstraintSet>
</MotionScene>

Android: Compose

val listState = rememberLazyListState()

LazyColumn(state = listState) {
    itemsIndexed(items) { index, item ->
        val itemOffset by remember {
            derivedStateOf {
                val itemInfo = listState.layoutInfo.visibleItemsInfo.find { it.index == index }
                itemInfo?.let { (listState.layoutInfo.viewportEndOffset / 2f) - (it.offset + it.size / 2f) } ?: 0f
            }
        }
        Box(modifier = Modifier.height(200.dp).fillMaxWidth()) {
            Image(
                painter = painterResource(item.imageRes),
                contentDescription = null,
                modifier = Modifier
                    .fillMaxSize()
                    .graphicsLayer { translationY = itemOffset * 0.3f },
                contentScale = ContentScale.Crop
            )
        }
    }
}

FPS Measurement Results

What’s Included in Our Work

• Analysis of the current screen and parallax prototyping.
• Animation architecture design (platform-specific approach selection).
• Integration on iOS (UIKit/SwiftUI) and Android (MotionLayout/Compose).
• Optimization: FPS testing on real devices (iPhone SE, Pixel 4).
• Delivery of source code, documentation, and maintenance recommendations.
• Access to project repository and a 1-hour training session for your team.

Timelines

Parallax for a hero image on a single screen: half a day. Parallax in a list with many elements (RecyclerView / LazyColumn / LazyVStack): 1–2 days. Cost is calculated individually.

Get a consultation for your project — we’ll find the optimal implementation. Contact us for a detailed estimate.

Typical Parallax Implementation Mistakes

The first mistake is animating on the main thread. Using scrollViewDidScroll to calculate and apply offset directly blocks the UI thread. On iPhone SE 2nd gen, this drops FPS from 60 to 40–45. The correct approach is to offload transformations to layoutSubviews (UIKit) or graphicsLayer (Compose), where they execute during the rendering phase, not layout.

The second mistake is insufficient image size. If the image height equals the container height, dark edges appear during scrolling. Add cellHeight × parallaxFactor on the top and bottom during resource preparation. We allocate a margin of 30–40% of the cell height.

The third mistake is lack of caching. Parallax in LazyVStack or LazyColumn without image caching (Kingfisher, Coil, Glide) causes drops when scrolling back up – reloading takes 200–500 ms. We recommend setting up a memory cache of 100 MB and a disk cache of 500 MB.

The fourth mistake is testing only on flagship devices. iPhone 15 Pro and Pixel 9 handle any implementation fine. Problems appear on iPhone SE 2nd gen and Xiaomi Redmi 9T. We always test on three generations of devices before final delivery.

Avoiding these mistakes will give you smooth parallax without quality compromises.

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.