Native or Cross-Platform App?
By CodexierPublished 5 min read
Native means writing the iPhone app in Apple's tools and the Android app in Google's, separately. Cross-platform means one codebase that produces both. The trade is not quality against convenience, as it was a decade ago; modern cross-platform frameworks produce apps most users cannot tell from native. The trade today is about a short list of technical needs, and this guide gives you that list.
What native really gives you
- Immediate access to every new platform API, without waiting for a framework to support it.
- The last few percent of rendering performance for demanding 3D, games or video effects.
- Deep integration with platform-specific features such as widgets, watch apps, CarPlay or Android Auto.
- A team already fluent in Swift or Kotlin who will maintain it for years.
Notice what is not on the list: looking native, feeling fast, passing store review, push notifications, offline support, biometrics or secure storage. Cross-platform frameworks handle all of those through the native layer.
What cross-platform gives you
Frameworks such as React Native, Flutter and Capacitor share one codebase across iOS and Android, and in Capacitor's case also the web. The mechanism differs: React Native and Flutter draw the interface themselves or through native components, Capacitor wraps a web app in a native shell with bridges to device features. All three ship native binaries through the same app stores.
One team, one release
A feature is built once and ships to both stores the same week. Bugs are fixed in one place. The team can be smaller and does not need two specialists.
Native where it matters
Camera, BankID, push, maps and payments are reached through native modules. When something is missing, a small native plugin fills the gap without rewriting the app.
Web reuse
With Capacitor especially, an existing web product can become an app with its logic intact. That is often the fastest route for a company that already has a customer portal.
The honest downside is dependence on the framework's release cycle and on third-party plugins. A framework or plugin that falls behind an OS update can block your release until it is fixed, which is one reason maintenance is a line item and not an afterthought; see app maintenance and scaling.
Cost and timeline compared
| Factor | Fully native, two apps | Cross-platform, one codebase |
|---|---|---|
| Build effort for the same features | Close to double | One build plus platform testing |
| Time to both stores | Longer, or one platform first | Both at once |
| Ongoing maintenance | Two codebases, two sets of OS updates | One codebase, framework updates on top |
| Team | iOS and Android specialists | One team, often with web skills |
| Peak performance | Best possible | Indistinguishable for business apps, behind for heavy graphics |
| Risk | Feature drift between the two apps | Framework or plugin lag after OS releases |
Our fixed prices for the cross-platform route are on the pricing page. What drives the cost inside either route is the same: screens, integrations, offline needs and login.
The cost gap narrows for very small apps, where store setup, design and backend dominate, and widens with every feature you add, because each feature is built twice on the native path.
Features that need native code
Even on a cross-platform app, some features are written natively as small modules. That is normal and does not push you to a fully native app. The distinction that matters is whether native code is the exception or the whole product:
- Fine as a native module inside a cross-platform app: BankID, custom camera flows, Bluetooth devices, background location, specialised payments hardware.
- Pushes towards fully native: real-time video or audio effects, 3D rendering, AR, games, anything where frame timing is the product.
- Check before deciding: does a maintained plugin exist for each hardware feature you need? If yes for all, cross-platform. If a core feature has none and writing it would be most of the app, native.
A decision checklist
- List the features. Mark any that are graphics, video, audio processing or AR. None marked: cross-platform.
- List the device features. Confirm a maintained plugin exists for each. All exist: cross-platform.
- Ask who maintains it in three years. No native specialists on staff: cross-platform.
- Ask whether a web version is wanted. Yes: cross-platform, probably Capacitor or a shared codebase.
- Ask whether the app must ship day one with every new OS feature. Yes, and it is central to the product: native.
When you do not need an app at all: if the job is reading information and filling in forms, a fast mobile website or a progressive web app often does it without store review or maintenance, and we would rather tell you that than build something you will not update. If your checklist points to native, we will say so and are not the right supplier for that build. If it points to cross-platform, the framework choice comes next, covered in React Native versus Flutter, and a short call with your feature list will settle both.
Frequently asked questions
Do cross-platform apps feel slower or less polished?
Not for business apps. Lists, forms, maps, payments and notifications run through native components or optimised rendering, and users cannot tell the difference. The gap appears only in demanding graphics or real-time media, where native still has the edge.
Can a cross-platform app use BankID?
Yes. BankID integration is done through the standard app-switch flow and native modules that all major frameworks support. It is a common requirement in Swedish apps and does not push you towards a fully native build.
Is it cheaper to build for one platform only?
It is cheaper than two native apps, but not cheaper than one cross-platform app that covers both. Launching on one platform first only makes sense if your users are almost entirely on it; in Sweden both iOS and Android have large shares, so most business apps need both from the start.
Not sure whether your app needs native code?
Send us your feature list before a fifteen-minute call. We will tell you whether cross-platform covers it, which framework fits and what the fixed price would be, or whether you should look for a native team instead.
Book a free 15-minute call