02 · Mobile · 03 Scale
Mobile Scale: run it for many.
Deep native needs or platform teams. Native modules or native apps behind a shared, typed contract, with per-platform ownership.
- Users
- Tens of thousands and up
- Team
- Six or more engineers, often per platform
You are here if
- You need background sensors, heavy graphics, or platform health and payment APIs
- iOS and Android have separate owners
- Startup time and binary size are tracked as product metrics
- Compliance requires platform-native security features
At scale, mobile splits into a shared contract and platform-specific implementations. That can still be React Native with custom native modules, or it can be Swift and Kotlin apps sharing an API client generated from one schema. What matters for the agent is that each platform is its own explicit project with its own build and test command, and that the shared part is small, typed and generated.
What does not change: the API contract is still the source of truth, screens are still files, and the agent still runs the tests before you do.
01
Consumer · content & social
React Native with native modules, or native apps behind one API
Cross-platform where it works, native where it must, and a generated API client so both share one contract.
The stack
- Framework
- React Native (bare or Expo with custom dev client), with Swift and Kotlin modules where needed
- Data
- The product API with a CDN and edge caching for media
- Auth
- The product's provider
- Hosting
- EAS or your own CI for builds; staged rollouts in both stores
- Also
-
- Per-platform owners and code review
- Performance budgets for startup and scroll
- Detox or Maestro on device farms
Why agents do well here
3/5- The shared TypeScript layer remains the agent's home; native modules are isolated behind explicit interfaces it can implement one side at a time.
- Generated API clients keep the contract honest across the shared layer and any fully native screens.
- Strong per-platform conventions in Swift and Kotlin mean agent-written native code is reviewable by platform owners.
Avoid at this tier
- Going fully native because of one slow screen; profile first, then write one module.
- Sharing UI code between native apps through a home-grown layer.
- Letting the native and JavaScript sides drift on data models; generate both from the schema.
02
Companion · mobile face of a SaaS
Expo with custom dev client in the platform monorepo
The companion app stays cross-platform, adds the native capabilities enterprise customers ask for, and is owned by a mobile team.
The stack
- Framework
- Expo with a custom development client and config plugins
- Data
- The platform API, versioned and generated
- Auth
- Enterprise SSO through the platform's OIDC provider, device attestation
- Hosting
- EAS with per-tenant or per-environment channels
- Also
-
- MDM and enterprise distribution where required
- Shared design tokens and schema packages
- Detox or Maestro on device farms
Why agents do well here
4/5- Config plugins keep native configuration as code the agent can read and diff, instead of Xcode and Gradle changes it cannot see.
- The platform's generated client and schema packages keep the mobile app honest with a backend owned by other teams.
- Expo's conventions remain strong at this size, so agent-written screens match the ones a mobile team wrote.
Avoid at this tier
- Forking the app per enterprise customer; use configuration and feature flags.
- Native code outside config plugins and isolated modules.
- A mobile-only data model; the platform schema is still the source of truth.
03
Tool · offline-first utility
Native Swift and Kotlin behind one schema
When the tool is the platform integration itself, write it natively per platform and share only the data contract.
The stack
- Framework
- SwiftUI and Jetpack Compose
- Data
- On-device stores (SwiftData / Room) with a shared sync contract
- Auth
- Platform-native (Sign in with Apple, Credential Manager) where accounts exist
- Hosting
- Store releases per platform; a small sync API if needed
- Also
-
- OpenAPI or protobuf schema shared across platforms
- Per-platform CI with real-device tests
- Platform-specific extensions (widgets, watch, complications)
Why agents do well here
3/5- SwiftUI and Compose are declarative and heavily documented, so agent-written screens follow platform conventions well.
- Sharing only a schema, not code, keeps each platform project self-contained and readable by the agent in one sitting.
- Platform compilers and previews give fast, local feedback the agent can act on without a device.
Avoid at this tier
- A cross-platform UI layer on top of native code; you chose native for the platform, so use it.
- Diverging data models per platform; generate both from the shared schema.
- Sharing business logic through a language bridge unless the logic is large and stable.