How to Fix ModalBottomSheet Infinite Bounce in Jetpack Compose

How Did We Discover the Compose Bottom Sheet Bug in Production?

While working on a high-scale enterprise FinTech application, our team was tasked with modernizing the mobile user interface using Jetpack Compose. The system required a complex transaction filtering mechanism where users could select from hundreds of dynamically generated financial parameters. To maintain a clean user experience, we opted to house these filters inside a nearly full-screen bottom sheet.

During a comprehensive QA cycle, we realized an edge-case gesture was causing a severe UI glitch. When testing the filtering screen on an Android 12 device, a QA engineer found that pulling the bottom sheet handle slightly downward and then quickly flinging it upward with high velocity resulted in a continuous bouncing loop. Instead of smoothly snapping to its expanded state, the sheet uncontrollably jumped up and down.

In production applications handling financial data, erratic UI behaviors severely degrade user trust. Smooth, predictable interactions are non-negotiable. This challenge required a deep dive into the Compose gesture system, inspiring this article to help other teams avoid similar infinite bouncing loops when dealing with complex swipeable surfaces.

Why Did This Issue Impact Our FinTech Architecture?

The problem surfaced within a core component of our mobile design system: a standardized choice list component. Because this component was reused across dozens of screens for account selection, date picking, and transaction filtering, any instability here threatened the entire application flow.

The architecture relied heavily on Material 3’s ModalBottomSheet combined with a deeply nested scrollable container. To accommodate extensive lists without covering the top app bar, the bottom sheet was constrained to 90% of the maximum screen height. Because this was a foundational component, the solution had to be globally applicable, highly performant, and completely transparent to the engineers integrating it across different feature modules.

What Were the Symptoms of the ModalBottomSheet Failure?

The core symptom was a continuous, un-damped oscillation of the sheet’s vertical position. The issue consistently appeared when the sheet content was large enough to occupy the nearly full-screen constraint. If the list was short, the behavior appeared normal.

Our initial triage confirmed the environment: we were running Jetpack Compose BOM 2026.04.01 mapping to Material 3 version 1.4.0. We attempted several immediate configurations that failed to resolve the glitch:

• Upgrading the Material 3 dependency to a newer alpha release yielded the same infinite bounce.
• Replacing the standard scrollable Column with a LazyColumn did not stop the jump.
• Removing the heightIn(max = maxHeight * 0.9f) constraint entirely failed to alter the buggy fling physics.

How Did We Approach the Solution for the Bouncing UI?

Our diagnostics pointed toward an issue with how gesture velocities were being passed between the nested scrolling child and the parent sheet’s AnchoredDraggableState. In Jetpack Compose, when you fling a nested scrollable area, the unconsumed velocity is handed back to the parent. A fast upward fling, when the sheet was already near its maximum expansion anchor, resulted in extreme overshoot. The internal spring physics would attempt to pull the sheet back, but conflicting nested scroll dispatches caused it to infinitely over-correct.

Did We Consider Alternative Architecture Solutions?

We rigorously evaluated multiple paths to stabilize the component. Companies that hire software developer teams expect architectural rigor, so we did not just look for a quick patch; we mapped out the tradeoffs.

Could We Use BottomSheetScaffold Instead?

We considered swapping ModalBottomSheet for a persistent BottomSheetScaffold. While this bypassed the specific modal physics bug, it violated our UX requirements. A modal sheet dictates distinct focus management and a scrim background, which the standard scaffold does not natively mimic without extensive custom logic.

Could We Disable skipPartiallyExpanded?

By forcing the sheet to halt at a partially expanded state, we hoped the physics engine might stabilize the anchor points. However, the business logic required the sheet to open fully for large lists to minimize immediate user scrolling. Forcing a half-open state degraded the user experience.

Could We Limit the Fling Velocity Globally?

We analyzed intercepting the gesture directly to clamp the maximum velocity. While this stopped the bounce, it made the entire scrolling experience within the list feel sluggish and unresponsive, essentially punishing users who navigate lists quickly.

Could We Intercept the Nested Scroll Fling?

The most viable solution was to implement a custom NestedScrollConnection attached to the inner scrollable container. By selectively intercepting the upward fling velocity only when the sheet was already fully expanded, we could nullify the physics overshoot without degrading the standard scroll velocity. This is the level of targeted problem-solving we employ when clients hire android developers to stabilize their mobile platforms.

What Was the Final Implementation to Stop the Bouncing?

Our final fix leveraged Compose’s nested scrolling system. We created a targeted interceptor that monitors the onPreFling event. If the user initiates a strong upward fling (represented by a negative Y velocity) and the sheet’s target value is already set to Expanded, our connection consumes that specific velocity. This prevents the parent ModalBottomSheet from receiving the unmanageable momentum that triggers the infinite spring oscillation.

Below is the sanitized, production-ready implementation:

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun StabilizedModalChoiceList(
    idsList: List<String>,
    onClick: (String) -> Unit,
    onDismiss: () -> Unit,
) {
    val sheetState = rememberModalBottomSheetState(
        skipPartiallyExpanded = true
    )
    val scrollState = rememberScrollState()
    // Custom connection to consume upward fling when already expanded
    val nestedScrollConnection = remember {
        object : NestedScrollConnection {
            override suspend fun onPreFling(available: Velocity): Velocity {
                val isFlingingUp = available.y < 0
                val isExpanded = sheetState.targetValue == SheetValue.Expanded
                
                return if (isFlingingUp && isExpanded) {
                    // Consume the upward fling velocity to prevent overshoot bouncing
                    available
                } else {
                    Velocity.Zero
                }
            }
        }
    }
    ModalBottomSheet(
        onDismissRequest = { onDismiss() },
        sheetState = sheetState,
        containerColor = Color.White,
        dragHandle = { BottomSheetDefaults.DragHandle() }
    ) {
        BoxWithConstraints(
            modifier = Modifier.nestedScroll(nestedScrollConnection)
        ) {
            Column(
                modifier = Modifier
                    .fillMaxWidth()
                    .heightIn(max = maxHeight * 0.9f)
                    .background(Color.White)
                    .padding(16.dp)
                    .verticalScroll(scrollState)
            ) {
                idsList.forEach { id ->
                    // Generic button component
                    AppButton(
                        text = id,
                        onClick = { onClick(id) }
                    )
                    Spacer(Modifier.height(12.dp))
                }
            }
        }
    }
}

We validated this across various devices and Android versions. By targeting only the pre-fling velocity under a specific state constraint, we maintained 100% of the native scroll fluidity while completely eliminating the bouncing bug. This targeted architectural approach is a hallmark of why enterprises trust us when they hire app developer to create a mobile app that handles complex data flows.

What Are the Lessons for Engineering Teams Adopting Compose?

Encountering framework-level physics bugs is common when adopting modern declarative UI toolkits. Here are actionable insights your engineering teams can apply:

• Understand Nested Scroll Dispatch: Events in Compose propagate from the child outward. Always verify how nested scrollable containers hand off excess dragging or flinging velocity to their parent surfaces.
• Test Edge Case Gestures: Standard tapping and dragging rarely expose physics bugs. QA protocols must include rapid multi-directional flings, especially near layout constraints.
• Do Not Rely Solely on Version Upgrades: Upgrading dependencies (like moving to an alpha Material 3 release) is a valid diagnostic step, but should not replace root-cause analysis.
• Use Targeted Interceptors: When dealing with unmanageable framework behaviors, intercept events as close to the source as possible rather than overhauling the entire layout component.
• Monitor Constraint Interactions: Physics bugs frequently occur at the intersection of dynamic constraints (like maxHeight * 0.9f) and fixed state anchors.
• Build Predictable Components: If a base component like a bottom sheet shows instability, fix it at the generic wrapper level before feature teams integrate it across dozens of screens.

How Can You Avoid Compose UI Glitches in Your Next Project?

Resolving UI physics issues requires a deep understanding of gesture propagation and state management. By isolating the nested scroll handoff, we stabilized a critical component without compromising application architecture or user experience. When building complex mobile interfaces, prioritizing robust foundation layers prevents cascading failures in production. If your organization is facing complex architecture challenges, contact us to explore how our dedicated engineering teams can help accelerate and secure your deliverables.

Social Hashtags

#JetpackCompose #AndroidDev #Kotlin #Material3 #ComposeUI #AndroidDevelopment #MobileDevelopment #SoftwareEngineering