"Native" means building the iOS app and the Android app separately, each with the tools Apple and Google provide. "Cross-platform" means writing most of the app once and running it on both. Both approaches ship real apps to the stores. They differ in cost, flexibility and long-term upkeep.
Native
iOS in Swift (often with SwiftUI), Android in Kotlin (often with Jetpack Compose). Two codebases, each using the platform's own interface components.
Cross-platform
Frameworks such as Flutter (Dart) and React Native (JavaScript or TypeScript) share most code across iOS and Android. Kotlin Multiplatform shares business logic while keeping native screens.
The trade-offs
| Question | Native | Cross-platform |
|---|---|---|
| Build effort for both platforms | Higher: two codebases | Lower: most code shared, though some platform-specific work remains |
| New OS features on release day | Available directly | Sometimes need a plugin or custom native code first |
| Performance for typical business apps | Very good | Usually good enough; heavy graphics or animation may favour native |
| Deep hardware use (Bluetooth devices, background tasks, AR) | Most direct | Possible, often through native modules |
| Look and feel | Platform-standard by default | Can match each platform or use one shared design |
| Long-term upkeep | Two codebases to update | One main codebase plus framework upgrades and plugin updates |
| Hiring later | Separate iOS and Android skills | Depends on the framework's popularity where you hire |
When native is worth it
- The app depends on hardware or OS features: Bluetooth accessories, background location, widgets, watch apps, advanced camera work.
- You only need one platform, for example an internal app on company-issued iPhones.
- Smooth, complex animation or graphics are central to the product.
When cross-platform makes sense
- You need iOS and Android at launch on a limited budget.
- The app is mostly forms, lists, accounts, payments and notifications, which covers many business apps.
- You want one team and one release schedule for both platforms.
What about a web app?
A progressive web app runs in the browser and can be added to the home screen. There's no app store review and one codebase serves every device. The limits are real, though: support for some features differs between browsers and platforms, especially on iOS, and users don't find you in the stores. For internal tools and simple customer portals it's worth considering first.
Questions to ask a developer
- Why do you recommend this approach for my app specifically, not in general?
- Which features will need platform-specific code, and how much of the budget is that?
- Which third-party plugins does this depend on, and how well maintained are they?
- If we change developers later, how easy will this codebase be to hand over?
Tell us what the app needs to do and who will use it, and get a written scope and estimate back.
Send a project brief