Skip to content
STACK IT FIRST
Install the skills
02 · Mobile · Scale · Tool

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.
Agent fit3/5 Scale · Run it for many Reviewed

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)
AGENTS.md + real projects on STACK IT FAST (opens in a new tab)

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.

How it fits together

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.

Folder layout

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

First five decisions

Lock these in before the agent writes the second feature. Each one removes a choice it would otherwise make differently every time.

  1. 01 Native UI toolkits
  2. 02 A shared schema with codegen
  3. 03 On-device stores per platform
  4. 04 Platform-native sign-in
  5. 05 Real-device CI per platform

When to move on

This is the top tier. From here the work is keeping the boundaries explicit, not changing the stack. The Mobile Scale page lists what stays the same.

Same tier, other profiles