Comparison
Native (Swift/Kotlin) vs. cross-platform — is one codebase actually enough?
Fully native means two separate apps: Swift for iOS, Kotlin for Android, written and maintained independently. Cross-platform means one codebase that ships to both. This isn't React Native vs. Flutter — it's whether you should be writing platform code at all.
| Fully Native (Swift + Kotlin) | Cross-Platform (React Native) | |
|---|---|---|
| Codebases to maintain | Two — every feature is built, tested, and fixed twice | One, with small platform-specific branches where they're needed |
| Languages | Swift/SwiftUI on iOS, Kotlin/Jetpack Compose on Android | TypeScript, plus native modules in Swift or Kotlin when required |
| Typical build cost | Roughly 1.7–2x a single-platform build | About 30–40% over one platform — and it covers both |
| New OS feature access | Day one — new APIs are available the moment Apple or Google ships them | Usually weeks to months behind, unless you bridge it yourself |
| UI rendering | Platform-native by definition | Real platform components — genuinely native UI, not a WebView |
| Performance ceiling | Highest — matters for games, AR, real-time video, heavy on-device work | Indistinguishable from native for business apps on the New Architecture |
| Hardware and OS integration | Unrestricted — widgets, watch apps, CarPlay, HealthKit, background modes | Common cases covered; deep integrations need a native module |
| Feature drift risk | Real — iOS and Android versions diverge over time without discipline | Low — one implementation, one behavior |
| Who can maintain it | An iOS specialist and an Android specialist, both retained | Any competent TypeScript developer, including your web team |
| Release cadence | Two builds, two submissions, two regression passes per release | One build pipeline, both stores from the same commit |
| Best for | Games, AR, wearables, and apps where the OS itself is the product | Booking, ordering, loyalty, portals, field tools, API-driven apps |
When fully native is the honest answer
Some apps really are native projects. If the product is a game, an AR experience, a camera app doing real-time processing, or anything leaning on on-device machine learning, you want direct access to Metal, ARKit, Core ML, and their Android equivalents — not a bridge to them.
The same is true when the operating system is the feature: an Apple Watch companion, home screen widgets and Live Activities, CarPlay or Android Auto, continuous background location for a fleet, or HealthKit integration for a clinical workflow. These live in platform territory, and building them through an abstraction layer costs more than writing them natively did.
There's also the team argument. If you already employ iOS and Android developers, native is what your people can maintain. Choosing a stack your own team can't support is a slow-motion mistake regardless of which stack it is.
What people get wrong about “we'll just build it native”
- The cost isn't double at launch — it's double forever. Every bug fix, every OS update, every new screen gets implemented twice, reviewed twice, and QA'd twice. The build quote is the small half of that number.
- The two apps drift. A tweak lands on iOS and doesn't make it to Android. Six months on, your two apps behave differently in ways nobody documented, and support can't tell which one a customer is describing.
- “Native is faster” is a benchmark claim, not a user experience. For a booking flow, an ordering screen, or a customer portal, the bottleneck is your API and the user's connection. Nobody has ever noticed the framework in an app that spends its life waiting on a network request.
- Cross-platform has an escape hatch, and most people don't know it. React Native lets you drop into Swift or Kotlin for the one screen or one integration that needs it, then return to shared code for the other 95%. You're not choosing between all-native and no-native.
- Two native codebases mean two hiring problems. Losing your Android developer stalls half your product. A TypeScript codebase draws from a far larger pool, and the developer who builds your API can read the app.
- “We'll rewrite it native once we scale” almost never happens. Companies that outgrow cross-platform tend to rewrite the two or three screens that need it, not the app. Plan for that, not for a rebuild you'll never fund.
Where ArdinGate Studios lands
We build in React Native, and the work that comes through the door is almost entirely the kind that fits it: companion apps for service businesses, ordering and loyalty tools, booking flows, and field apps for contractors. These are API-driven products. Their success depends on shipping quickly, staying maintainable, and being affordable for a small business — not on squeezing out frames.
When one piece of a project needs to reach deeper than the framework does, we write that piece as a native module in Swift or Kotlin inside the same app. That covers most “but we need native for X” requirements without paying for two codebases.
And when a project genuinely belongs in fully native territory — a game, an AR product, a watch-first experience — we'll say so before you spend anything. Talking someone into the wrong stack costs us more than turning down the work does.
Want to know which one your app actually needs?
Send us the feature list. We'll tell you which parts cross-platform handles cleanly, which parts need native code, and what that means for the quote.
Get a recommendation