[Due for payment 2026-07-21] iOS - AI promo modal - Transition animations stutter when moving between tiles on the carousel

[nlemma]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.15-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92007
Email or phone of affected tester (no customers): gatantm+665@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 12 mini, iOS 16.7, iPhone 16 Pro Max, iOS 18.7.7
App Component: Other

Action Performed:

1. Launch the app
2. Login to see the new promo
3. Swipe ot tap next to move between the tiles

Expected Result:

The animation is smooth between the tiles

Actual Result:

The transition animations stutter when moving between tiles on the carousel

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7184947_1781812032855.RPReplay_Final1781806150.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @gijoe0295

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #92007

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #92007 - "Concierge AI Feature Promo Modal" by @gijoe0295 (High confidence)
Related Issues: #90820 (feature implementation issue)

Recommendation: ROLL FORWARD

This is a brand-new feature that does not exist in production, and the symptom is an animation performance issue (stutter) rather than a functional break — a targeted performance fix to the new carousel/Lottie code is preferable to reverting an extensively-reviewed feature PR.

Assigned: @gijoe0295 (PR author), @ShridharGoel (approving reviewer), @mjasikowski (approving reviewer) from highest-confidence causing PR only
Labels: No label changes. DeployBlockerCash is correctly retained (App deploy is blocked, this is a frontend bug). No backend DeployBlocker label was present, so nothing to remove. Per the decision tree, since an App PR caused the issue we must keep DeployBlockerCash.

📋 Detailed Analysis

Evidence

• The issue describes stuttering transition animations on the "AI promo modal" carousel when swiping/tapping between tiles on iOS.
• PR Concierge AI Feature Promo Modal #92007 ("Concierge AI Feature Promo Modal") introduces exactly this feature. The issue body itself references this PR in the regression-test field, and melvin-bot auto-assigned the reporter as the merger of Concierge AI Feature Promo Modal #92007.
• The bug is staging-only ("Reproducible in production?: N/A - new feature, doesn't exist in prod"), and Concierge AI Feature Promo Modal #92007 is on the current StagingDeployCash checklist (Deploy Checklist: New Expensify 2026-06-18 #93956), merged 2026-06-18 12:51 UTC — well before the blocker was filed at 20:58 UTC the same day.
• This is a frontend-only change: the entire diff is in Expensify/App (React Native components, navigators, Lottie assets). There is no API/backend interaction in the carousel transition path, so the fix belongs in the App repo.

Verification

Affected/new files introduced by #92007 that own the carousel transition behavior:

• src/components/FeatureTrainingModal/FeatureTrainingModalCarouselBody.tsx (new) — the horizontal FlatList carousel with pagingEnabled, pagination dots, and scrollToIndex for swipe/tap navigation.
• src/components/FeatureTrainingModal/FeatureTrainingModalIllustration.tsx (new) — renders a Lottie animation per page and toggles play/reset based on isFocused.
• src/components/AIFeaturesPromoModal/index.tsx (new) — wires the three AI promo tiles (SpendAnalysis, ExpenseAssistant, CustomAgents Lottie animations) into the carousel.

Confirmed via gh pr view 92007 --json files that the PR adds all of these files plus the three .lottie assets in assets/animations/.

Root Cause

The carousel renders a full-weight Lottie animation for every page inside the horizontal FlatList, and all pages are mounted simultaneously. In FeatureTrainingModalIllustration.tsx, each Lottie is rendered with autoPlay={isFocused} and loop, while an effect calls animationRef.current.play(0) / reset() on focus change:

useEffect(() => {
  if (!isCarousel || !animationRef.current || isReduceMotionEnabled) {
    return;
  }
  if (isFocused) {
    animationRef.current.play(0);
  } else {
    animationRef.current.reset();
  }
}, [isFocused, isCarousel, isReduceMotionEnabled]);

On iOS, decoding/animating multiple Lottie animations on the JS/UI thread while a scrollToIndex/paging gesture is in flight competes for frame budget, producing the observed stutter during the inter-tile transition. The onViewableItemsChanged -> setCurrentPage state update (95% visibility threshold) also triggers a re-render of FeatureTrainingModalContent mid-transition, adding work right as the scroll settles.

Suggested roll-forward directions (for the assignees to evaluate):

• Pause/freeze non-focused Lottie animations more aggressively, or render only the focused page's animation, so only one animation runs during a swipe.
• Defer the currentPage/content re-render until the scroll fully settles (e.g. via onMomentumScrollEnd) to avoid re-rendering mid-transition.
• Consider removeClippedSubviews/windowing so off-screen Lottie views are not driving frames during the gesture.

[MelvinBot]

Proposal

⚠️ Medium confidence — this is a rendering-performance (jank) issue, so the exact dominant factor should be confirmed with on-device profiling (Xcode Instruments / Flipper). The analysis below is from static review of #92007.

What is the root cause of that problem?

The promo carousel renders every page's Lottie animation inside a horizontal FlatList (AIFeaturesPromoModal/index.tsx passes SpendAnalysis, ExpenseAssistant, CustomAgents). On iOS, lottie-react-native rasterizes frames on the main thread, the same thread that drives the paging scroll — so an actively looping animation and the swipe animation contend for frames, which reads as stutter. Two things make the hitch land right at the transition:

1. The newly-focused animation restarts as the scroll settles. currentPage only updates when a page passes the 95% visibility threshold (onViewableItemsChanged → setCurrentPage, CarouselBody:134-141). That flips isFocused, and the effect calls animationRef.current.play(0) (Illustration:70-82) — a full animation (re)start fired at the exact moment the swipe is still decelerating.
2. Every mounted cell re-renders on each page change. renderItem is an inline closure over currentPage with no memoization (CarouselBody:233-249), so each setCurrentPage re-renders all illustration cells — extra main-thread work at the worst time.

Off-screen animations are only .reset() on blur; there is no gesture-aware pause/deferral. Note the Lottie wrapper's perf guards (shouldLoadAfterInteractions, pause-on-navigate) are web/browser-only and don't apply on native iOS (Lottie/index.tsx).

What changes do you think we should make in order to solve the problem?

• Defer the focused animation's play(0) until the swipe settles — wrap it in InteractionManager.runAfterInteractions (mirroring the existing shouldLoadAfterInteractions pattern in Lottie) so the restart doesn't land mid-transition.
• Memoize the carousel cell (extract a React.memo'd item component) and drive updates via the FlatList extraData={currentPage} prop instead of re-creating renderItem on every page change, so only the two affected cells re-render.
• Pause off-screen animations rather than relying on a single focused/blurred state, and consider only mounting/playing the focused tile (render the first frame as a static placeholder for the rest).

What alternative solutions did you explore? (Optional)

• The reporter's lowest-end device is an iPhone 12 mini; part of the stutter may be device-specific and amplified by heavy/high-framecount .lottie source assets — worth checking the asset weight too.
• Confirming which factor dominates needs an on-device profile (Instruments Core Animation / Flipper), which I couldn't run here.

Investigation notes

• Carousel: horizontal FlatList, pagingEnabled, getItemLayout based on carouselViewportWidth (CarouselBody:222-250).
• Each page → FeatureTrainingModalIllustration → <Lottie ... autoPlay={isFocused} loop> (Illustration:163-171).
• All affected files are in Expensify/App, so the fix can be made in this repo.
• No duplicate open issues found in a quick scan.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93985) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.