Improve mobile conversation responsiveness

[Git-on-my-level]

Summary

• Make the production-data mobile_beta profile explicit while keeping production Firebase/Auth and beta OAuth routing.
• Prewarm and preserve mobile tabs without blocking the tap frame, and show skeletons instead of transient empty states.
• Flatten conversation and detail content into lazy slivers, isolate repaint-heavy rows, and defer analytics/provider work until after visible navigation.
• Restore the Home conversation preview and keep Daily Recaps, Mind Map, and compact journey locations intact.
• Bound goal slider divisions so large numeric goals cannot block scrolling or route transitions.

Root cause

Physical-device Time Profiler captured six severe main-thread hangs lasting 3.22-3.74 seconds. The dominant sampled frame was RenderSlider.paint. A numeric goal with a target near 1,000,000,000 created one slider division per target unit, so Flutter walked roughly one billion divisions during every repaint even though tick marks were hidden. Scrolling Conversations and opening either a goal or conversation repainted that source page and hit the same pathological loop.

Large and fractional goals now use a continuous slider. Small integral goals up to 100 retain exact one-unit divisions. The Goals section is also isolated behind a repaint boundary.

User impact

• Conversations scrolling and row taps remain responsive with very large numeric goals.
• First-load navigation displays immediate skeleton feedback instead of suggesting data is gone.
• Tab state, restored Home content, and existing goal editing behavior are preserved.

David verified the final Profile-prod mobile_beta build on a physical iPhone 15 Pro Max and confirmed the lag is fixed.

Validation

• flutter test --no-pub test/widgets/bottom_nav_bar_test.dart test/widgets/conversation_list_item_performance_test.dart test/widgets/conversation_markdown_widget_test.dart test/widgets/daily_summary_detail_page_test.dart test/widgets/goals_widget_performance_test.dart test/widgets/home_conversations_preview_test.dart test/providers/conversation_provider_tap_test.dart test/pages/conversations_group_widget_test.dart (14 passed)
• bash scripts/analyze_ratchet.sh (passed)
• Repository pre-push gate (passed), including PR preflight, production routing invariants, Flutter generated output, localization output, and Dart formatting.
• Physical-device build: flutter build ios --profile --flavor prod --dart-define=OMI_APP_PROFILE=mobile_beta --dart-define=OMI_API_BASE_URL=https://api.omiapi.com/
• Installed bundle verified as com.friend-app-with-wearable.ios12, omi-beta, and https://api.omiapi.com/.

Failure-Class: none

[cubic-dev-ai]

2 issues found across 45 files

Confidence score: 3/5

• In app/scripts/generate_ios_dev_info_plist.sh (and the INFOPLIST_FILE change to Runner/Info-Dev.plist), dev/raybanDat iOS builds can fail on machines that do not run setup.sh first, because the plist is not generated during Xcode build steps; this creates a concrete local/CI regression risk—add an Xcode build phase (or commit a fallback plist) so the file always exists at build time.
• In app/android/app/src/dev/AndroidManifest.xml, only the omi-dev scheme is registered, so a dev flavor built with OMI_APP_PROFILE=mobile_beta may not match its OAuth redirect URI and auth can break for that profile—add the missing scheme mapping (or profile-specific manifest handling) to keep redirects consistent.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="app/android/app/src/dev/AndroidManifest.xml">

<violation number="1" location="app/android/app/src/dev/AndroidManifest.xml:8">
P2: This dev manifest registers only the `omi-dev` scheme, which covers the localDev profile. If the dev flavor is ever built with OMI_APP_PROFILE=mobile_beta (the profile referenced for the device build), its OAuth redirect_uri is `omi-beta://auth/callback`, but `omi-beta` is declared only in the prod manifest and won't be merged into the dev build, so the callback would never be delivered. Consider also registering the `omi-beta` scheme here to match the prod manifest.</violation>
</file>

<file name="app/scripts/generate_ios_dev_info_plist.sh">

<violation number="1" location="app/scripts/generate_ios_dev_info_plist.sh:5">
P2: The dev/raybanDat iOS builds now point INFOPLIST_FILE at `Runner/Info-Dev.plist`, but that file is only produced by the new script via `setup.sh` and is not generated by any Xcode build phase. On any machine that builds the dev flavor without first (re)running `bash setup.sh ios` — a fresh checkout, a CI job, or after `Info.plist` edits — the build will fail to find the plist or, worse, silently use a stale copy that omits newer `Info.plist` settings. Consider wiring `generate_ios_dev_info_plist.sh` into the build as a Run Script phase (generating the derived plist in a build artifact directory before the Info.plist processing step) instead of depending on a one-time setup invocation, so dev builds are self-contained and always reflect the source `Info.plist`.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: This dev manifest registers only the omi-dev scheme, which covers the localDev profile. If the dev flavor is ever built with OMI_APP_PROFILE=mobile_beta (the profile referenced for the device build), its OAuth redirect_uri is omi-beta://auth/callback, but omi-beta is declared only in the prod manifest and won't be merged into the dev build, so the callback would never be delivered. Consider also registering the omi-beta scheme here to match the prod manifest.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At app/android/app/src/dev/AndroidManifest.xml, line 8:

<comment>This dev manifest registers only the `omi-dev` scheme, which covers the localDev profile. If the dev flavor is ever built with OMI_APP_PROFILE=mobile_beta (the profile referenced for the device build), its OAuth redirect_uri is `omi-beta://auth/callback`, but `omi-beta` is declared only in the prod manifest and won't be merged into the dev build, so the callback would never be delivered. Consider also registering the `omi-beta` scheme here to match the prod manifest.</comment>

<file context>
@@ -0,0 +1,12 @@
+                <action android:name="android.intent.action.VIEW" />
+                <category android:name="android.intent.category.DEFAULT" />
+                <category android:name="android.intent.category.BROWSABLE" />
+                <data android:scheme="omi-dev" />
+            </intent-filter>
+        </activity>
</file context>

[Git-on-my-level]

Monitor review-fix pass for commit c16b9367.

Code fix (1 commit):

• app/lib/pages/apps/page.dart: Wrapped _loadApps() body in try/catch with Logger.handle so a future provider error cannot surface as an unhandled async exception from the post-frame callback. (Cubic P2, thread …Dpb2)

Threads resolved:

• …Dpb2 (page.dart): Fixed — error containment added.
• …DpcN (firebase_options_local.dart): Already addressed by prior commit cfa527f576 — the duplicate setup/prebuilt/firebase_options_local.dart was deleted and all setup/test consumers now source from lib/firebase_options_local.dart, eliminating the dual source of truth.

Threads left open (reviewed at stale commit 9b779ca, not actionable against current diff):

• …Dpbu (dev AndroidManifest.xml): No current diff on this file (unchanged from main).
• …Dpb6 (generate_ios_dev_info_plist.sh as Xcode build phase): Scope creep for a performance PR; Info-Dev.plist is committed and available without setup.sh.
• …DpcA (prodRelease.xcconfig): GOOGLE_REVERSE_CLIENT_ID was already re-added by commit cfa527f576 with a deterministic override after Custom.xcconfig.

Verification:

• flutter analyze lib/pages/apps/page.dart — no issues.
• flutter test test/providers/app_provider_load_test.dart — 3/3 passed.