On this page 9 sections
I build native Apple apps in Swift and SwiftUI, so you should read this knowing that. I’ve also built with Expo and React Native: an early app version of my StromaScape site used them. Each approach has a place, and the right one depends on your situation more than on anyone’s preference.
The options
Native iOS (Swift and SwiftUI). The app is written in Apple’s own language with Apple’s own frameworks. Android needs a separate native app in Kotlin if you want one.
React Native. Write the app in JavaScript or TypeScript with React, and it renders real native components on iOS and Android. Expo is a popular toolkit around it that handles much of the build and release work.
Flutter. Write the app in Dart; Flutter draws its own interface on both platforms rather than using the system’s components.
Kotlin Multiplatform. Share business logic (networking, data, rules) written in Kotlin between platforms, and build each interface natively, in SwiftUI on iOS. Compose Multiplatform can share the interface too.
A web app or progressive web app. A website that works well on phones, which can be added to the Home Screen. No App Store involved.
What actually differs
Feel and platform fit
Native apps get the platform’s behaviour for free: navigation, gestures, text input, scrolling physics, Dynamic Type, VoiceOver, and the design changes Apple introduces each year. React Native uses native components, so it’s close; Flutter draws its own, so it can look identical on both platforms, which is a strength for strongly branded apps and a weakness when users expect iOS conventions.
For many business apps, such as forms, lists and bookings, users won’t notice the difference if the cross-platform app is built well. For apps where feel is the product, they often do.
Access to new Apple features
Widgets, Live Activities, App Intents and Siri, Apple Watch apps, HealthKit and on-device Apple Intelligence features arrive first, and sometimes only, as Swift APIs. Cross-platform apps can use them, but usually through native code written for that feature, which means you need Swift skills anyway. If your roadmap leans on these, native has a clear edge. Widgets, App Intents and Live Activities shows what’s involved.
Apple Watch
A watchOS app is written in Swift and SwiftUI regardless of how the phone app is built. If a watch app is part of the plan, budget for native work on that part.
Shared code and team size
One cross-platform codebase can mean one team building one set of features for both platforms. That saving is real, but rarely a simple halving: platform-specific work, two sets of store submissions, testing on both, and native bridges for some features all remain. Kotlin Multiplatform aims at the middle ground, sharing the logic that’s identical and keeping each interface native.
Long-term maintenance
Every approach needs upkeep when Apple and Google ship new OS versions each year. Cross-platform apps also depend on the framework keeping pace with both platforms, and on third-party plugins being maintained. Native apps depend on fewer layers. Neither is maintenance-free; the maintenance guide covers what to expect.
Hiring and handover
Ask who will look after the app in two years. If your company already has web developers who know React, React Native may let them contribute. If the app will be handed to an agency or freelancer, Swift and Kotlin skills are widely available, as are React Native and Flutter skills; less common frameworks narrow the field.
When each option tends to fit
These are typical considerations, not rules:
| Your situation | Often a good fit |
|---|---|
| Your customers are mostly on iPhone, or you’re starting with one platform to test demand | Native iOS first |
| Deep use of Apple features: widgets, Live Activities, Apple Watch, HealthKit, Siri | Native iOS |
| You need iOS and Android at launch, with mostly standard screens, and a modest budget | React Native or Flutter |
| You already have a React web team | React Native |
| A strongly branded, custom-drawn interface that should look identical everywhere | Flutter |
| Complex shared business logic, native interfaces on each platform | Kotlin Multiplatform |
| Content, forms or a tool people use occasionally, no need for the App Store | A good mobile web app |
Don’t skip the web option
A surprising number of app ideas don’t need an app. If people will use it a few times a year, don’t need offline access, notifications or device hardware, and would find it through search, a fast mobile website may serve them better and cost much less. Apple’s App Review guidelines also discourage apps that are mainly a website in a wrapper (guideline 4.2), so a thin app may not even be accepted.
An app earns its place when people use it often, when it needs the device’s capabilities, or when being on their Home Screen matters to your business.
Two illustrative examples
These are made-up scenarios to show the reasoning, not real projects.
A small chain of fitness studios wants members to book classes, join waiting lists and get a reminder before class. Members use both iPhone and Android. The screens are standard: timetables, a booking flow, an account page. The studios already have a web booking system with an API. Here a cross-platform framework is a reasonable choice, because both platforms are needed at once and little of the app depends on Apple-only features. A Lock Screen widget showing the next booked class would be a nice extra later, and could be added with a small amount of native code.
A specialist running coach wants an app for clients who all train with an Apple Watch. The app needs workout data from HealthKit, a watch app that shows the session plan on the wrist, a Live Activity during runs and Siri shortcuts to start a session. Almost every important feature is an Apple framework, and the watch app must be Swift anyway. Native iOS is the clear choice, with Android left until there’s demand.
The same budget could produce very different apps in these two cases, and the “right” technology flips between them.
Can you change your mind later?
Yes, but it costs. Moving from one framework to another usually means rewriting the interface, and often much of the logic. A few habits keep the door open whichever route you take:
- keep business rules and server communication separate from the screens, so they can be reused or ported;
- put as much logic as is sensible on the server, behind a documented API that any future app can use;
- own your data and your accounts with third-party services, so a rebuild doesn’t mean a migration of customers;
- write tests for the rules that matter, which become the specification for any rewrite.
Many successful apps started native on one platform, proved the idea, then added the second platform once there was revenue to pay for it. Others started cross-platform and moved parts to native code as they needed more from the platform. Both paths are normal.
Questions that settle it
- What share of your customers use iPhone versus Android? If you don’t know, your website analytics will give a good indication.
- Do you need both platforms on day one, or can one go first?
- Which Apple-specific features are on the roadmap in the next two years?
- Who will maintain the app after launch, and which skills do they have?
- How important is it that the app feels exactly like an iPhone app?
If the answers point to iPhone first and Apple features, build native. If they point to both platforms at once with standard screens and a web team, a cross-platform framework is a sound choice. If they point to occasional use with no device features, consider the web.
Performance, size and the first impression
For typical business apps, a well-built cross-platform app performs perfectly well. Differences tend to show at the edges: launch time, very long or complex lists, heavy animation, large downloads and memory use on older phones. A native app also has no framework runtime to ship, which keeps the download smaller. None of this should decide the question on its own, but if your app competes on speed and feel, it’s worth building a small prototype of the most demanding screen before committing.
Key takeaways
- Native Swift and SwiftUI gives the best platform fit and first access to new Apple features.
- React Native and Flutter can save effort when you need both platforms with mostly standard screens, but the saving is rarely half.
- Apple Watch, widgets and many system integrations need Swift regardless.
- Kotlin Multiplatform shares logic while keeping native interfaces.
- Consider whether a fast mobile website would do the job before commissioning any app.
If you’re weighing up options for a specific idea, tell me about it. I’ll tell you honestly whether a native iOS app is the right call, and if it isn’t, what I’d look at instead.
Written by Lee Johnson. Published 30 October 2026.