React Native and Flutter UI Recipes

Mobile development with AI tools is tricky because platform-specific behavior matters. A component that works in a web preview will crash on a real device if it uses unsupported APIs. These recipes produce code that accounts for iOS/Android differences, handles safe areas, respects platform conventions, and uses native modules correctly.

What You Will Walk Away With

• React Native component recipes with platform-specific handling
• Flutter widget recipes with Material and Cupertino design
• Navigation patterns for both frameworks with deep linking
• Performance recipes for lists, animations, and image loading

---

Recipe 1: Platform-Adaptive Navigation (React Native)

Scenario: Your app needs tab navigation on iOS and drawer navigation on Android, following each platform’s conventions.

Navigation scaffolding touches many files at once — the navigator, every screen, the param types, and the deep-link config — so the tool you reach for changes how you drive it.

Cursor

Open the navigation folder and use agent mode so it edits RootNavigator.tsx, the screen files, and linking.ts in one pass. Drop a checkpoint before accepting — platform-split navigators are the classic case where the AI gets the iOS branch right and silently breaks the Android headerShown defaults, and you want a one-click rollback.

Claude Code

Run headless so it writes the navigator, screens, and RootStackParamList in a single turn: claude -p "build the platform-adaptive navigator described in linking.ts and wire all four screens". Add a PostToolUse hook on *.tsx that runs tsc --noEmit so a missed param type fails immediately instead of at runtime.

Codex

Spin up a worktree so the navigation rewrite stays isolated from the rest of the app while you review the iOS-vs-Android split. Once the diff is clean, push the branch and let the Cloud reviewer check the deep-link map before you merge.

Tip

Create a platform-adaptive navigation system using React Navigation v7. (1) Define a RootNavigator that detects the platform and renders BottomTabNavigator on iOS or DrawerNavigator on Android. (2) Both contain the same 4 screens: Home, Search, Notifications, Profile. (3) For iOS: use @react-navigation/bottom-tabs with SF Symbols icons, haptic feedback on tab press, and a floating action button above the tab bar. (4) For Android: use @react-navigation/drawer with Material 3 styling, user header with avatar, and section dividers. (5) Both share the same stack screens within each tab/drawer item. (6) Add deep linking mapping URLs like myapp://profile/123 to screens with params. (7) Handle Android back button: pop nested stack first, exit confirmation on root. Type all params with RootStackParamList. Write a test verifying deep link resolution.

Expected output: Root navigator, iOS tabs, Android drawer, deep linking config, typed params, and tests.

---

Recipe 2: Responsive Layout System (React Native)

Scenario: Your app must work on phones, tablets, and foldables with different layouts at each breakpoint.

Tip

Create a responsive layout system. (1) useResponsive() hook returning { width, height, breakpoint, isPhone, isTablet, isFoldable, orientation }. Breakpoints: phone (<600), tablet (600-1024), desktop (>1024). Detect foldables via hinge geometry API. (2) ResponsiveGrid component rendering 1 column on phone, 2 on tablet portrait, 3 on tablet landscape using FlatList numColumns. (3) ResponsiveStack rendering children vertically on phone, horizontally on tablet. (4) MasterDetail layout: on phone show list then navigate to detail; on tablet show list (1/3) and detail (2/3) simultaneously. (5) useScaledSize(baseSize) scaling proportionally to screen width relative to 375px base. Test layout changes by mocking Dimensions.

Expected output: useResponsive hook, three layout components, useScaledSize hook, and tests.

---

Recipe 3: Custom Widget Library (Flutter)

Scenario: Your Flutter app needs a branded design system working across iOS and Android.

Tip

Create a widget library in lib/widgets/. (1) AppButton with variants (primary, secondary, outline, ghost, destructive), sizes (sm, md, lg), loading spinner, disabled state, optional icons. Uses Theme.of(context). Cupertino rounded corners on iOS, Material ripple on Android. (2) AppTextField with label, helper text, error text, prefix/suffix icons, obscure toggle for passwords. (3) AppCard with optional header, body, footer, configurable elevation. (4) AppAvatar with circular image, initials fallback, loading shimmer, online/offline badge. (5) AppBottomSheet with drag handle, snap points (half/full screen), dismissible. (6) AppTheme class with light() and dark() factory methods defining all tokens. (7) WidgetBook showcase screen displaying every variant. Write widget tests for each.

Expected output: Five widget files, theme class, widget book, and widget tests.

---

Recipe 4: Performant Feed List (React Native)

Scenario: Your feed screen shows 1000+ items with images and stutters when scrolling. Pull-to-refresh feels laggy.

Tip

Build a high-performance feed using FlashList from @shopify/flash-list. (1) Replace FlatList with FlashList, set estimatedItemSize. (2) Create FeedItem wrapped in React.memo with comparison on id and updatedAt only. (3) Use react-native-fast-image with priority:normal for visible items, priority:low for prefetch. Shimmer placeholder while loading. (4) Pull-to-refresh with native RefreshControl, prepend new items without losing scroll position, show “X new items” banner for background refreshes. (5) Infinite scroll with onEndReached at threshold 0.5, footer spinner, handle no-more-items. (6) Scroll-to-top on active tab tap. (7) Memoize renderItem and keyExtractor. Test that the list renders without dropped frames.

Expected output: Feed screen with FlashList, memoized FeedItem, FastImage loading, and performance test.

---

Recipe 5: Offline-First Architecture (React Native)

Scenario: Your field service app must work without connectivity. Users enter data offline and it syncs when connected.

A sync engine spans models, an adapter, hooks, and UI — and the tricky part is the last-write-wins conflict logic, which is easy to get subtly wrong. How you supervise that differs by tool.

Cursor

Build it in agent mode across the model and adapter files, but checkpoint right before the sync-adapter step and review that diff on its own — conflict resolution is where the AI quietly drops the syncStatus reconciliation. The inline diff view makes the timestamp-comparison logic easy to scan line by line.

Claude Code

Generate the models and adapter headless, then make the sync logic provable: claude -p "write WatermelonDB sync tests: create offline, go online, assert last-write-wins" and add a PostToolUse hook running the offline-then-online test on every edit to sync/*.ts. You want the conflict path covered by a test, not by hope.

Codex

Use a worktree to develop the sync engine in isolation, then push and let the Cloud reviewer focus on the conflict-resolution path specifically — a fresh reviewer catches the dropped-write edge case that the author (human or AI) glossed over.

Tip

Implement offline-first with WatermelonDB. (1) Define models: WorkOrder (id, title, status, assignedTo, description, syncStatus), Photo (id, workOrderId, uri, caption, syncStatus), Note (id, workOrderId, content, syncStatus). (2) Sync adapter: on connectivity change (NetInfo), compare timestamps, push local changes (last-write-wins), pull server changes, mark synced. (3) Queue mutations offline with sync queue. Show “pending sync” badge on unsynced items. (4) Photos: store locally in app documents, upload during sync, replace URI after upload. (5) useNetworkStatus() hook: { isOnline, pendingSync, lastSyncedAt, syncNow() }. (6) Offline banner showing count of pending changes. Test: create offline, go online, verify sync.

Expected output: WatermelonDB models, sync engine, network hooks, offline banner, and sync tests.

---

Recipe 6: State Management with Riverpod (Flutter)

Scenario: Your Flutter app uses Provider everywhere. Migrate to Riverpod for testability and type safety.

Tip

Set up Riverpod v2 with code generation. (1) Install flutter_riverpod, riverpod_annotation, riverpod_generator. (2) auth_provider.dart: @riverpod AsyncNotifier managing auth state, login/logout/refresh, token persisted to secure storage. (3) todo_provider.dart: @riverpod AsyncNotifier with CRUD, optimistic updates, auto-refetch on auth change via ref.watch. (4) filter_provider.dart: simple @riverpod for filter state plus derived filteredTodosProvider combining todos with filter. (5) Use ref.watch for reactive, ref.read for one-time callbacks. (6) Override providers in tests with ProviderContainer. (7) Add riverpod_lint. Write widget tests overriding providers with mocks.

Expected output: Three provider files, widget tree integration, and widget tests with mock overrides.

---

Recipe 7: Native Module Integration (React Native)

Scenario: You need NFC tag reading not covered by existing libraries.

Cursor

Use agent mode so it generates NativeNfc.ts, the Swift class, and the Kotlin class in one edit, then keep the iOS Simulator and an Android emulator in split panes to eyeball both bridges. Because native changes do not hot-reload, accept the checkpoint and trigger a full rebuild rather than expecting Fast Refresh to pick them up.

Claude Code

Generate .swift, .kt, and .ts in a single headless pass, then wire the rebuild into a hook so you never test stale binaries: add a PostToolUse hook matching *.swift and *.kt that runs npx expo prebuild --clean (or cd ios && pod install for bare RN). The terminal-first flow means the native rebuild is one command away from the edit.

Codex

Open a worktree so the Swift and Kotlin work stays isolated from your JS feature branch — native module edits often need an Xcode/Gradle sync that you do not want polluting the main checkout. Review the TurboModule spec diff in the Codex IDE extension before syncing the native projects.

Tip

Create a React Native Turbo Module for NFC. (1) TypeScript spec in src/NativeNfc.ts: readTag() returning { id, type, payload }, startScanning(options), stopScanning(), events for onTagDiscovered and onError. (2) iOS Swift implementation: CoreNFC, NFCNDEFReaderSessionDelegate, Info.plist permission, bridge events. Handle unavailable NFC on older devices. (3) Android Kotlin: NfcAdapter, AndroidManifest intent filters, onNewIntent discovery, bridge events. (4) useNfc() hook: { isAvailable, isScanning, lastTag, startScan, stopScan, error }. (5) Handle permissions: request on first scan, settings link if denied. Test hook with mocked native module.

Expected output: TurboModule spec, iOS Swift, Android Kotlin, useNfc hook, and tests.

---

Recipe 8: Card Swipe Animations (React Native)

Scenario: You need smooth 60fps animations for a swipeable card stack.

Tip

Build a swipeable card stack with react-native-reanimated v3 and react-native-gesture-handler. (1) SwipeableCard using Gesture.Pan() mapping translationX to rotation and like/nope overlay opacity. (2) On release: if past threshold (150px), animate off-screen. Otherwise spring back to center. Use withSpring for return, withTiming for exit. (3) CardStack rendering top 3 cards with scale/translateY depth offsets. Dismissed top card animates next up. (4) Vertical swipe up for “super like” with scale+rotate animation. (5) Undo button animating last card back. (6) All animations on UI thread via useSharedValue and useAnimatedStyle. (7) Haptic feedback at swipe threshold. Test gesture detection with mock events.

Expected output: SwipeableCard, CardStack, undo logic, haptic integration, and gesture tests.

---

Recipe 9: Platform-Adaptive Design (Flutter)

Scenario: Your Flutter app looks identical on iOS and Android. Users expect platform-native patterns.

Tip

Create platform-adaptive widgets in lib/adaptive/. (1) AdaptiveScaffold rendering Scaffold on Android, CupertinoPageScaffold on iOS with matching app bars and nav. (2) AdaptiveDialog using AlertDialog on Android, CupertinoAlertDialog on iOS with same API. (3) AdaptiveSwitch using Switch.adaptive. (4) AdaptiveTextField using TextField on Android, CupertinoTextField on iOS with consistent validation. (5) AdaptiveDatePicker showing Android picker dialog or iOS date wheel. (6) PlatformHelper class overridable in tests. (7) AdaptivePage base class with platform-specific transitions: right-to-left on iOS, bottom-to-top on Android. Test each widget on both platforms by mocking Platform.isIOS.

Expected output: Six adaptive widgets, PlatformHelper, base page class, and cross-platform tests.

---

Recipe 10: Push Notifications (React Native)

Scenario: Your app needs push notifications on both platforms with deep linking to specific screens.

Tip

Implement push using @notifee/react-native and @react-native-firebase/messaging. (1) Configure Firebase with google-services.json and GoogleService-Info.plist. Request permissions with pre-permission screen. (2) notifications/setup.ts: register device token, handle refresh, configure Android channels (Orders high, Messages default, Promotions low). (3) notifications/handlers.ts: background handler and foreground handler showing Notifee notifications. (4) notifications/deeplink.ts: parse data and navigate — order to OrderDetail, message to Chat, promo to Offers. Handle cold-start from notification. (5) useNotifications() hook: { permission, requestPermission, token, lastNotification }. (6) Test handling and deep link resolution.

Expected output: Firebase config, setup, handlers, deep link parser, hook, and tests.

---

Recipe 11: GoRouter Navigation (Flutter)

Scenario: Your navigation is scattered Navigator.push calls with no type safety. You need declarative routing.

Tip

Set up GoRouter. (1) app_router.dart with GoRouter: shell route for main scaffold persisting bottom nav, nested routes per tab, parameterized /products/:id, redirect for auth. (2) Typed route helpers via go_router_builder: ProductRoute(id).go(context). (3) Deep linking: Android intent filters and iOS universal links. (4) Route guards: refreshListenable watches auth, redirect checks state, protected routes redirect to login with return URL. (5) Per-route transition animations. (6) Android back button: pop inner stack first, double-tap to exit on root. (7) Analytics: log route changes via observers. Test resolution, redirects, and deep linking.

Expected output: Router config, typed helpers, deep link config, guards, and navigation tests.

---

Recipe 12: App Store Submission Preparation

Scenario: Your app is feature-complete. Prepare for App Store and Play Store submission.

Submission prep is mostly config edits plus a verification script, so this is the recipe where a scripted, repeatable run pays off most.

Cursor

Let agent mode edit Info.plist and build.gradle together, then run the build-verification script from the integrated terminal. The visual diff is handy for catching a wrong versionCode or a stray debug entitlement before you ship.

Claude Code

This is the strongest fit for headless scripting: have it generate a prepare-release.sh that bumps versions, builds both platforms, and greps the release bundle for console.log and debug deps — then run it in CI so every release candidate is verified the same way. The build-verification step is exactly the kind of repeatable gate the CLI was built for.

Codex

Kick the release prep off as a Cloud task from a fresh worktree and have it open a PR with the config changes plus RELEASE_CHECKLIST.md. A reviewer signs off on the version bumps and signing config on the PR before anything reaches the stores.

Tip

Prepare this React Native app for store submission. (1) iOS Info.plist: All privacy usage descriptions, bundle identifier, version, build number, ATS enabled, device capabilities. (2) Android build.gradle: applicationId, versionCode/Name, minSdkVersion 24, targetSdkVersion 35, release signing, ProGuard/R8. (3) Both: Generate app icons at all sizes from 1024x1024 source. Configure splash screens. (4) Build verification script: builds release for both platforms, verifies no console.log in production, no debug dependencies in release. (5) Generate RELEASE_CHECKLIST.md: test on real devices, verify deep links, check analytics, test push notifications, verify in-app purchases, screenshot all screens.

Expected output: Updated native configs, icon script, build verification script, and release checklist.

---

When Recipes Break

Caution

Common mobile development pitfalls:

• Web API usage: If the AI generates localStorage or window.innerWidth, it will crash on device. Verify React Native/Flutter APIs are used.
• Hot reload limits: Native module changes require full rebuild. If the AI edits native code, note the rebuild requirement.
• Gradle conflicts: The most common AI error is adding dependencies incompatible with your Gradle/AGP version. Verify compatibility.
• Simulator vs device: Code working in the iOS simulator may fail on device due to missing entitlements or permissions.

What Is Next

• Expo recipes for managed workflow patterns
• Flutter recipes for deeper Flutter workflows
• React Native recipes for advanced React Native patterns