Native vs cross-platform app: every store app is a native binary, so the question is what runs inside it

1. Does the app need to feel like the phone’s own apps, and follow the platform when it changes? Navigation, gestures, system sheets, accessibility, the new device shapes: native gets these from the platform’s own components, and platform changes arrive there first. The current example is iPhone Duo, where Apple’s standard containers adapt to the fold by themselves and an app built with an older SDK runs at “a familiar size and aspect ratio” until rebuilt — iPhone Duo apps: what changes. A cross-platform framework follows after the framework updates; a web view follows the browser engine.

2. Who will work on it in a year? A native project needs an iOS engineer and an Android engineer, or an AI agent that writes both; a React Native or Flutter project needs a developer in that framework; a web wrapper needs a web developer. Hiring, contracting and acquisition due diligence all read this column. Code export vs no-code lock-in covers what each leaves you owning.

3. Does a website already exist, and is the phone app the same product or a different one? If the web app is the product and the phone app is the same screens in your pocket, the wrapper is the shortest route, subject to Apple’s bar for it. If the phone app has its own jobs — camera, offline, notifications, widgets, the home screen — it is a different product and should be built as one, in whichever of the first two architectures question 1 picks.

The table compares the three architectures on the columns a product person decides on. Rows are architectures, not products; the builders that produce each are on cross-platform app builder and best native app builders.

What runs inside: SwiftUI on iPhone, Jetpack Compose on Android, in Swift and Kotlin. Codebases: two, one per platform — unless the tool writes the feature logic once and renders it natively on each, which is Modaal’s model: from its documentation, “Each feature’s logic — its state, the actions that change it, the effects it requests — is written once,” and “The iPhone app renders that state in SwiftUI; the Android app renders it in Jetpack Compose.” Follows the platform: first; new device classes, system components and accessibility arrive in these frameworks with each OS release, and Apple’s rule that from April 2027 uploads must be built with the iOS 27 SDK or later is a rule about exactly this layer. Who works on it: an iOS engineer, an Android engineer, or an AI agent writing both; the projects open in Xcode and Android Studio. Best for: camera, offline, notifications, widgets, the lock screen and StandBy, a paywall that has to pass review, anything where the phone is the product. Cost of the choice: two UI implementations, which is the reason the framework tier exists.

What runs inside: for React Native, JavaScript or TypeScript that “renders native UI on both iOS and Android” through a bridge to the platform’s components; for Flutter, Dart drawing its own widgets with the framework’s engine. Codebases: one, with platform-specific code where the framework does not reach. Follows the platform: after the framework does; a new system component or device class appears when the framework ships support for it. Who works on it: a React Native or Flutter developer; the project needs that toolchain in addition to Xcode and Android Studio. Best for: a product with mostly standard screens — lists, forms, feeds — where one team shipping to both stores matters more than the platform’s newest behaviour. The full decision against native, including what each framework reaches and what it does not, is on React Native vs native.

What runs inside: your web app, in a native web view, with plugins for the native APIs it needs; on iOS, apps that browse the web must use WebKit (guideline 2.5.6). Codebases: one — the website. Follows the platform: the browser engine’s pace; system navigation, sheets and device classes are re-implemented in web code or not at all. Who works on it: a web developer. Best for: a product whose web app is the product and whose phone app is the same screens with push notifications and an icon. The bar: Apple’s guideline 4.2, Minimum Functionality: “Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or ‘app-like,’ it doesn’t belong on the App Store.” What passes and what does not, with the three routes from a website, is on turn a website into an app. Whether the product needs an app at all is a prior question — do you actually need a native app?

The phone app is the product — it uses the camera, works offline, sends notifications, has widgets, sells a subscription through the store: native. If the objection is two codebases, the answer in 2026 is a tool that writes the feature once and renders it natively on both, rather than a framework in between.

One small team, two stores, standard screens, nothing platform-specific on the roadmap: a cross-platform framework, chosen on React Native vs native with the roadmap in hand — the moment a platform feature appears on it, the framework’s reach becomes the constraint.

A web app exists and the store version is the same product: a wrapper, built to clear guideline 4.2 by doing something the website does not — offline content, native navigation, push, camera.

Validating an idea, launch not planned: the fastest of the three; keep the spec, treat the build as disposable. When it graduates to a product, re-run question 1.

The native case with one project: in Modaal the PRD is the first prompt; the agent writes a plan you approve, then the feature logic once and the SwiftUI and Jetpack Compose screens for each platform; the Xcode and Android Studio projects stay on your disk. The Free plan covers one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually, €15 monthly, and adds both platforms and TestFlight — /pricing.