Mobile: Constrained, Reviewed, and User-Facing
Mobile development has constraints that web development does not: app store review (Apple and Google review every update — violations cause rejection), limited resources (battery, memory, storage on the device), offline capability (users lose connectivity on subways, planes, rural areas), platform design guidelines (Apple HIG, Material Design — violating them feels wrong to users), and deployment cadence (you cannot hotfix a mobile app — users must update through the store).
AI rules for mobile engineering encode: platform-specific patterns (SwiftUI for iOS, Jetpack Compose for Android, React Native or Flutter for cross-platform), app store requirements (privacy labels, required permissions, content ratings), offline-first architecture (local database, sync engine, conflict resolution), and performance standards (app launch in < 2 seconds, smooth 60fps scrolling, background task battery limits).
The AI must detect the platform: Swift/SwiftUI = iOS native. Kotlin/Jetpack Compose = Android native. React Native/TypeScript = cross-platform RN. Dart/Flutter = cross-platform Flutter. Each platform has different conventions, APIs, and patterns. AI rule: 'Detect the mobile platform from the project structure and generate platform-idiomatic code. iOS: follow Apple's design patterns (MVVM, Combine). Android: follow Google's patterns (MVVM, Kotlin Coroutines, Hilt DI).'
Platform-Specific AI Rules
iOS (SwiftUI): declarative UI with SwiftUI views, @State/@Binding/@ObservedObject for state management, async/await for concurrency, Core Data or SwiftData for persistence. AI rule: 'iOS: SwiftUI views for UI. MVVM architecture (View → ViewModel → Model). Networking: async/await with URLSession. Persistence: SwiftData (modern) or Core Data (legacy). Never use UIKit patterns in a SwiftUI project unless wrapping a UIKit component.'
Android (Jetpack Compose): declarative UI with Composable functions, ViewModel with StateFlow for state, Kotlin Coroutines for concurrency, Room for persistence, Hilt for dependency injection. AI rule: 'Android: Jetpack Compose for UI. MVVM (Composable → ViewModel → Repository). Networking: Retrofit with Kotlin Coroutines. Persistence: Room database. DI: Hilt. Follow the official Android architecture guide (UI layer → Domain layer → Data layer).'
Cross-platform (React Native): JavaScript/TypeScript with React Native components. AI rule: 'React Native: functional components with hooks. Navigation: React Navigation (stack, tab, drawer). State: Zustand, Redux Toolkit, or React Context. Networking: fetch or axios. Persistence: AsyncStorage for simple data, WatermelonDB or SQLite for complex data. Platform-specific code: Platform.select() or .ios.tsx/.android.tsx file extensions.'
In a SwiftUI project: generating UIKit patterns (UIViewController subclasses, storyboards, delegates) creates a confusing hybrid codebase. SwiftUI has its own declarative patterns for everything UIKit does imperatively. The exception: wrapping UIKit components that have no SwiftUI equivalent (using UIViewRepresentable). The AI must detect SwiftUI vs UIKit from the existing codebase and generate code exclusively in the project's paradigm.
Offline-First and Performance
Offline-first architecture: the app works without an internet connection. Data is stored locally and synced when connectivity is available. AI rule: 'Design for offline: every screen that displays data should read from the local database, not directly from the API. Network requests update the local database. The UI reads from the database (single source of truth). When offline: the app works with cached data. When online: sync in the background. Conflict resolution: last-write-wins for simple data, manual resolution for complex conflicts.'
App launch performance: users expect the app to be interactive within 2 seconds. AI rule: 'Optimize app launch: defer non-critical initialization (analytics, feature flags, push notification registration) to after the first screen renders. Use lazy loading for heavy modules. Cache the last-viewed screen state so the app appears to launch instantly (show cached content while fresh data loads in the background).'
Battery optimization: mobile OS enforces strict limits on background activity. AI rule: 'Background work: use the platform's background task API (iOS BGTaskScheduler, Android WorkManager). No continuous background polling — use push notifications to trigger sync. Location updates: use significant location changes, not continuous GPS (drains battery). The AI must respect platform battery limits — apps that drain battery get bad reviews and may be throttled by the OS.'
The perceived launch time matters more than the actual launch time. Pattern: on app launch, immediately display the cached version of the last screen the user was viewing (from the local database). In the background: fetch fresh data from the API. When fresh data arrives: update the UI seamlessly. The user sees content instantly (cached) and gets fresh data within seconds. This pattern makes the app feel instant even on slow networks.
App Store Compliance and Deployment
Apple App Store review: Apple reviews every update for compliance with the App Store Review Guidelines. Common rejection reasons: crashes and bugs, misleading metadata, privacy violations (accessing data without disclosure), in-app purchase violations (digital goods must use Apple IAP — 30% commission), and guideline 4.3 (spam/duplicate apps). AI rule: 'iOS apps: all digital purchases through Apple IAP. Privacy: accurately declare data usage in App Store Connect. No private APIs. No references to competing platforms in the UI.'
Google Play policies: similar to Apple but with some differences. AI rule: 'Android: digital purchases through Google Play Billing for apps distributed on Play Store. Target the latest API level (Google requires targeting recent Android versions). Declare all permissions with justification. Comply with the Families Policy if the app targets children.'
Deployment strategy: mobile app deployment differs from web. You cannot deploy instantly — users update on their own schedule. AI rule: 'Staged rollout: release to 5% → 20% → 50% → 100% of users. Monitor crash rates and user feedback at each stage. Feature flags: use remote configuration (Firebase Remote Config, LaunchDarkly) to enable features server-side without requiring an app update. This decouples feature launches from app releases.'
Without feature flags: to launch a feature, you submit an app update, wait for app store review (1-7 days), then users gradually update (days to weeks). With feature flags: the feature code ships in a regular update, disabled by default. When ready to launch: flip the flag server-side. All users with the latest version see the feature instantly. To roll back: flip the flag off. No app update needed. Feature flags are essential for mobile release management.
Mobile Engineering AI Rules Summary
Summary of AI rules for mobile engineering teams building iOS and Android applications.
- Platform detection: Swift/SwiftUI = iOS. Kotlin/Compose = Android. RN = cross-platform. Match conventions
- iOS: SwiftUI + MVVM + async/await + SwiftData. Follow Apple HIG
- Android: Compose + ViewModel + Coroutines + Room + Hilt. Follow Android architecture guide
- React Native: functional components + hooks + React Navigation + AsyncStorage/SQLite
- Offline-first: local database as single source of truth. Sync when online. Work when offline
- Performance: < 2s launch. Defer non-critical init. Cache last-viewed screen state
- Battery: platform background APIs only. No polling. Push-triggered sync. Significant location changes
- App store: IAP for digital goods (Apple/Google). Staged rollout. Feature flags for remote control