02 · Mobile · 03 Scale

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.

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 reviewPerformance budgets for startup and scrollDetox or Maestro on device farms

Framework docs

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.

At scale, consumer apps either keep React Native and add native modules for the hot paths, or move to native apps that share only the API contract. Either way, the shared part is small, generated and typed, and each platform has an owner and its own test command.

apps/mobile/      React Native app, src/, modules/<native-module>/ {ios, android, index.ts}
apps/ios/ apps/android/   only if you go native
packages/api-client/      generated from the API's OpenAPI document

First five decisions: profile before writing native code, one interface per native module, generated clients everywhere, staged rollouts, and device-farm tests on the flows that make money.

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 requiredShared design tokens and schema packagesDetox or Maestro on device farms

AGENTS.md + real projects on STACK IT FAST

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.

The companion app is now a product in its own right, with a team, enterprise requirements and native capabilities. Expo with a custom dev client keeps those capabilities as code while the app stays cross-platform and inside the platform monorepo.

apps/mobile/      app/, src/features/, plugins/ (config plugins), modules/
packages/schema/  packages/api-client/  packages/tokens/

First five decisions: custom dev client not a bare workflow, config plugins for every native change, enterprise SSO through the shared provider, feature flags over forks, and device-farm tests per release.

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 platformsPer-platform CI with real-device testsPlatform-specific extensions (widgets, watch, complications)

Framework docs

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.

Some tools are the platform: sensors, widgets, health data, background processing. At that point native per platform is the honest choice. Keep the shared surface to a schema and, if needed, a sync API, and let each platform be a complete project with its own tests.

ios/              SwiftUI app, Features/<workflow>/, Persistence/
android/          Compose app, feature/<workflow>/, data/
schema/           OpenAPI or .proto, codegen for both platforms

First five decisions: native UI toolkits, a shared schema with codegen, on-device stores per platform, platform-native sign-in, and real-device CI per platform.