Rozwój mobilny z narzędziami AI jest trudny, ponieważ zachowanie specyficzne dla platformy ma znaczenie. Komponent działający w podglądzie webowym zawali się na prawdziwym urządzeniu, jeśli używa nieobsługiwanych API. Te przepisy generują kod uwzględniający różnice iOS/Android, obsługują bezpieczne obszary, respektują konwencje platformy i prawidłowo używają modułów natywnych.
Przepisy komponentów React Native z obsługą specyficzną dla platformy
Przepisy widgetów Flutter z designem Material i Cupertino
Wzorce nawigacji dla obu frameworków z deep linkingiem
Przepisy wydajności dla list, animacji i ładowania obrazów
Scenariusz: Twoja aplikacja potrzebuje nawigacji zakładkowej na iOS i nawigacji szufladowej na Android, zgodnie z konwencjami każdej platformy.
Utwórz system nawigacji adaptacyjny dla platformy używając React Navigation v7. (1) Zdefiniuj RootNavigator wykrywający platformę i renderujący BottomTabNavigator na iOS lub DrawerNavigator na Android. (2) Oba zawierają te same 4 ekrany: Home, Search, Notifications, Profile. (3) Dla iOS: użyj @react-navigation/bottom-tabs z ikonami SF Symbols, haptycznym feedbackiem przy naciśnięciu zakładki i pływającym przyciskiem akcji nad paskiem zakładek. (4) Dla Android: użyj @react-navigation/drawer ze stylowaniem Material 3, nagłówkiem użytkownika z avatarem i separatorami sekcji. (5) Oba współdzielą te same ekrany stosu wewnątrz każdego elementu zakładki/szuflady. (6) Dodaj mapowanie deep linkingu URL typu myapp://profile/123 do ekranów z parametrami. (7) Obsługuj przycisk wstecz Android: najpierw pop zagnieżdżonego stosu, potwierdzenie wyjścia na root. Typuj wszystkie params z RootStackParamList. Napisz test weryfikujący rozwiązywanie deep linków.
Oczekiwany wynik: Nawigator root, zakładki iOS, szuflada Android, konfiguracja deep linkingu, typowane params i testy.
Scenariusz: Twoja aplikacja musi działać na telefonach, tabletach i składanych urządzeniach z różnymi layoutami dla każdego punktu przerwania.
Utwórz system responsywnego layoutu. (1) Hook useResponsive() zwracający { width, height, breakpoint, isPhone, isTablet, isFoldable, orientation }. Punkty przerwania: phone (<600), tablet (600-1024), desktop (>1024). Wykrywaj składane przez API geometrii zawiasów. (2) Komponent ResponsiveGrid renderujący 1 kolumnę na telefonie, 2 na tablecie portrait, 3 na tablecie landscape używając FlatList numColumns. (3) ResponsiveStack renderujący dzieci pionowo na telefonie, poziomo na tablecie. (4) Layout MasterDetail: na telefonie pokaż listę, następnie nawiguj do szczegółów; na tablecie pokaż listę (1/3) i szczegóły (2/3) jednocześnie. (5) useScaledSize(baseSize) skalujący proporcjonalnie do szerokości ekranu względem bazy 375px. Testuj zmiany layoutu mockując Dimensions.
Oczekiwany wynik: Hook useResponsive, trzy komponenty layoutu, hook useScaledSize i testy.
Scenariusz: Twoja aplikacja Flutter potrzebuje brandowanego systemu designu działającego na iOS i Android.
Utwórz bibliotekę widgetów w lib/widgets/. (1) AppButton z wariantami (primary, secondary, outline, ghost, destructive), rozmiarami (sm, md, lg), spinnerem ładowania, stanem wyłączonym, opcjonalnymi ikonami. Używa Theme.of(context). Zaokrąglone rogi Cupertino na iOS, ripple Material na Android. (2) AppTextField z etykietą, tekstem pomocniczym, tekstem błędu, ikonami prefix/suffix, przełącznikiem obscure dla haseł. (3) AppCard z opcjonalnym nagłówkiem, ciałem, stopką, konfigurowalnym elevation. (4) AppAvatar z okrągłym obrazem, fallbackiem inicjałów, shimmerem ładowania, odznaką online/offline. (5) AppBottomSheet z uchwytem przeciągania, punktami przyciągania (half/full screen), dismissible. (6) Klasa AppTheme z metodami fabrycznymi light() i dark() definiującymi wszystkie tokeny. (7) Ekran showcase WidgetBook wyświetlający każdy wariant. Napisz testy widgetów dla każdego.
Oczekiwany wynik: Pięć plików widgetów, klasa motywu, widget book i testy widgetów.
Scenariusz: Twój ekran feedu pokazuje 1000+ elementów z obrazami i zacina się przy przewijaniu. Pull-to-refresh czuje się opóźnione.
Zbuduj wysokowydajny feed używając FlashList z @shopify/flash-list. (1) Zamień FlatList na FlashList, ustaw estimatedItemSize. (2) Utwórz FeedItem owinięty w React.memo z porównaniem tylko id i updatedAt. (3) Użyj react-native-fast-image z priority:normal dla widocznych elementów, priority:low dla prefetch. Placeholder shimmer podczas ładowania. (4) Pull-to-refresh z natywnym RefreshControl, dołączaj nowe elementy bez utraty pozycji przewijania, pokazuj banner “X nowych elementów” dla odświeżeń w tle. (5) Nieskończone przewijanie z onEndReached przy threshold 0.5, stopce spinner, obsługa no-more-items. (6) Scroll-to-top przy tapnięciu aktywnej zakładki. (7) Memoizuj renderItem i keyExtractor. Testuj, że lista renderuje się bez porzuconych klatek.
Oczekiwany wynik: Ekran feedu z FlashList, zmemoizowany FeedItem, ładowanie FastImage i test wydajności.
Scenariusz: Twoja aplikacja serwisowa w terenie musi działać bez łączności. Użytkownicy wprowadzają dane offline i synchronizują się po połączeniu.
Zaimplementuj offline-first z WatermelonDB. (1) Zdefiniuj modele: WorkOrder (id, title, status, assignedTo, description, syncStatus), Photo (id, workOrderId, uri, caption, syncStatus), Note (id, workOrderId, content, syncStatus). (2) Adapter synchronizacji: przy zmianie łączności (NetInfo), porównaj timestampy, wypchnij lokalne zmiany (last-write-wins), pociągnij zmiany serwera, oznacz zsynchronizowane. (3) Kolejkuj mutacje offline z kolejką synchronizacji. Pokazuj badge “oczekująca synchronizacja” na niezsynchronizowanych elementach. (4) Zdjęcia: przechowuj lokalnie w dokumentach aplikacji, uploaduj podczas synchronizacji, zamień URI po uploadzie. (5) Hook useNetworkStatus(): { isOnline, pendingSync, lastSyncedAt, syncNow() }. (6) Banner offline pokazujący liczbę oczekujących zmian. Testuj: twórz offline, przejdź online, weryfikuj synchronizację.
Oczekiwany wynik: Modele WatermelonDB, silnik synchronizacji, hooki sieciowe, banner offline i testy synchronizacji.
Scenariusz: Twoja aplikacja Flutter używa wszędzie Provider. Migruj do Riverpod dla testowalności i bezpieczeństwa typów.
Skonfiguruj Riverpod v2 z generowaniem kodu. (1) Zainstaluj flutter_riverpod, riverpod_annotation, riverpod_generator. (2) auth_provider.dart: @riverpod AsyncNotifier zarządzający stanem uwierzytelniania, login/logout/refresh, token persystowany do secure storage. (3) todo_provider.dart: @riverpod AsyncNotifier z CRUD, optymistycznymi aktualizacjami, auto-refetch przy zmianie auth przez ref.watch. (4) filter_provider.dart: prosty @riverpod dla stanu filtra plus pochodny filteredTodosProvider łączący todos z filtrem. (5) Użyj ref.watch dla reaktywnego, ref.read dla jednorazowych callbacków. (6) Override providerów w testach z ProviderContainer. (7) Dodaj riverpod_lint. Napisz testy widgetów overridujące providery z mockami.
Oczekiwany wynik: Trzy pliki providerów, integracja drzewa widgetów i testy widgetów z mock overrides.
Scenariusz: Potrzebujesz czytania tagów NFC nieobsługiwanego przez istniejące biblioteki.
Multi-file editing Cursora generuje kod natywny obok TypeScript jednocześnie.
Claude Code generuje pliki .swift, .java i .ts w jednym promptcie — idealnie dla modułów natywnych.
Codex pracuje na plikach natywnych i JavaScript równolegle używając izolacji worktree.
Utwórz moduł Turbo React Native dla NFC. (1) Specyfikacja TypeScript w src/NativeNfc.ts: readTag() zwracający { id, type, payload }, startScanning(options), stopScanning(), eventy dla onTagDiscovered i onError. (2) Implementacja iOS Swift: CoreNFC, NFCNDEFReaderSessionDelegate, uprawnienie Info.plist, eventy bridge. Obsługuj niedostępne NFC na starszych urządzeniach. (3) Android Kotlin: NfcAdapter, filtry intent AndroidManifest, odkrywanie onNewIntent, eventy bridge. (4) Hook useNfc(): { isAvailable, isScanning, lastTag, startScan, stopScan, error }. (5) Obsługuj uprawnienia: żądaj przy pierwszym skanie, link do ustawień jeśli odrzucone. Testuj hook z mockowanym modułem natywnym.
Oczekiwany wynik: Specyfikacja TurboModule, iOS Swift, Android Kotlin, hook useNfc i testy.
Scenariusz: Potrzebujesz płynnych animacji 60fps dla stosu kart do przesuwania.
Zbuduj stos kart do przesuwania z react-native-reanimated v3 i react-native-gesture-handler. (1) SwipeableCard używający Gesture.Pan() mapującego translationX na rotację i opacity nakładki like/nope. (2) Przy zwolnieniu: jeśli poza progiem (150px), animuj poza ekran. W przeciwnym razie sprężynuj z powrotem do środka. Użyj withSpring dla powrotu, withTiming dla wyjścia. (3) CardStack renderujący górne 3 karty z przesunięciami głębokości scale/translateY. Odrzucona górna karta animuje następną w górę. (4) Pionowe przesunięcie w górę dla “super like” z animacją scale+rotate. (5) Przycisk cofnij animujący ostatnią kartę z powrotem. (6) Wszystkie animacje na wątku UI przez useSharedValue i useAnimatedStyle. (7) Haptyczny feedback przy progu przesuwania. Testuj wykrywanie gestów z mock events.
Oczekiwany wynik: SwipeableCard, CardStack, logika cofnij, integracja haptyczna i testy gestów.
Scenariusz: Twoja aplikacja Flutter wygląda identycznie na iOS i Android. Użytkownicy oczekują natywnych wzorców platformy.
Utwórz adaptacyjne widgety platformy w lib/adaptive/. (1) AdaptiveScaffold renderujący Scaffold na Android, CupertinoPageScaffold na iOS z dopasowanymi paskami aplikacji i nav. (2) AdaptiveDialog używający AlertDialog na Android, CupertinoAlertDialog na iOS z tym samym API. (3) AdaptiveSwitch używający Switch.adaptive. (4) AdaptiveTextField używający TextField na Android, CupertinoTextField na iOS z spójną walidacją. (5) AdaptiveDatePicker pokazujący dialog pickera Android lub koło dat iOS. (6) Klasa PlatformHelper overridowalna w testach. (7) AdaptivePage klasa bazowa z przejściami specyficznymi dla platformy: right-to-left na iOS, bottom-to-top na Android. Testuj każdy widget na obu platformach mockując Platform.isIOS.
Oczekiwany wynik: Sześć adaptacyjnych widgetów, PlatformHelper, klasa bazowa strony i testy międzyplatformowe.
Scenariusz: Twoja aplikacja potrzebuje powiadomień push na obu platformach z deep linkingiem do konkretnych ekranów.
Zaimplementuj push używając @notifee/react-native i @react-native-firebase/messaging. (1) Skonfiguruj Firebase z google-services.json i GoogleService-Info.plist. Żądaj uprawnień z ekranem pre-permission. (2) notifications/setup.ts: zarejestruj token urządzenia, obsługuj odświeżanie, konfiguruj kanały Android (Orders high, Messages default, Promotions low). (3) notifications/handlers.ts: handler tła i handler pierwszoplanowy pokazujący powiadomienia Notifee. (4) notifications/deeplink.ts: parsuj dane i nawiguj — zamówienie do OrderDetail, wiadomość do Chat, promo do Offers. Obsługuj cold-start z powiadomienia. (5) Hook useNotifications(): { permission, requestPermission, token, lastNotification }. (6) Testuj obsługę i rozwiązywanie deep linków.
Oczekiwany wynik: Konfiguracja Firebase, setup, handlery, parser deep linków, hook i testy.
Scenariusz: Twoja nawigacja to rozproszone wywołania Navigator.push bez bezpieczeństwa typów. Potrzebujesz deklaratywnego routingu.
Skonfiguruj GoRouter. (1) app_router.dart z GoRouter: shell route dla głównego scaffoldu persystującego dolną nawigację, zagnieżdżone trasy per zakładka, sparametryzowane /products/:id, przekierowanie dla auth. (2) Typowane helpery tras przez go_router_builder: ProductRoute(id).go(context). (3) Deep linking: filtry intent Android i uniwersalne linki iOS. (4) Guardy tras: refreshListenable obserwuje auth, redirect sprawdza stan, chronione trasy przekierowują do loginu z return URL. (5) Animacje przejść per trasa. (6) Przycisk wstecz Android: najpierw pop wewnętrznego stosu, podwójne tapnięcie do wyjścia na root. (7) Analityka: loguj zmiany tras przez observers. Testuj rozwiązywanie, przekierowania i deep linking.
Oczekiwany wynik: Konfiguracja routera, typowane helpery, konfiguracja deep linków, guardy i testy nawigacji.
Scenariusz: Twoja aplikacja jest kompletna funkcjonalnie. Przygotuj się do zgłoszenia do App Store i Play Store.
Przygotuj tę aplikację React Native do zgłoszenia do sklepu. (1) iOS Info.plist: Wszystkie opisy użycia prywatności, bundle identifier, wersja, numer buildu, ATS włączony, możliwości urządzenia. (2) Android build.gradle: applicationId, versionCode/Name, minSdkVersion 24, targetSdkVersion 34, podpisywanie release, ProGuard/R8. (3) Obie: Generuj ikony aplikacji we wszystkich rozmiarach ze źródła 1024x1024. Konfiguruj ekrany splash. (4) Skrypt weryfikacji buildu: buduje release dla obu platform, weryfikuje brak console.log w produkcji, brak zależności debug w release. (5) Generuj RELEASE_CHECKLIST.md: testuj na prawdziwych urządzeniach, weryfikuj deep linki, sprawdź analitykę, testuj powiadomienia push, weryfikuj zakupy in-app, zrób screenshoty wszystkich ekranów.
Oczekiwany wynik: Zaktualizowane konfiguracje natywne, skrypt ikon, skrypt weryfikacji buildu i checklist release.
