Mobile
Native vs cross-platform app development
Native apps are two products that can share a design and an API. Cross-platform is one product until the platforms disagree. The right choice is the one that matches the device behaviour you need and the people who will maintain it.
Native is the clear choice when
The app depends on new platform APIs, heavy camera or audio work, or a level of platform polish that a shared toolkit will fight. It is also the clear choice when you already employ a Swift team and a Kotlin team and the app is the core product. You pay for two release trains and you get fewer compromises.
Cross-platform is the clear choice when
The experience is forms, lists, accounts, and tasks that look the same on both phones, and you need both stores. Flutter and React Native are the candidates we use. The next article compares those two. Cross-platform still needs store release skill, and it still needs a small amount of native work more often than the sales page admits.
What does not decide it
A slogan about performance, unless you have measured a specific screen. A desire to “write once” as if design, QA, and API work were free the second time. A vendor’s single favourite. If the only person who can maintain the choice is the vendor, you have not bought an app. You have rented one.
Native or shared, as a product choice
Shared code fits
- Both stores, one team
- Ordinary product UI
- A short list of device features
Native earns it
- The device feature is the product
- One platform only
- A team already deep in that platform
Decide this before the repository
The feature list
Camera, offline, and background location change the answer. A login screen does not.
The team
The people who will ship version two have to be able to read version one.
The web
A website is not a free extra of a mobile codebase.
Decide this before a repository exists
- 01
Platforms
One store, or two.
- 02
Device features
The list that might force native work.
- 03
The team
Who ships version two.
- 04
The web
A site is a separate product unless you have scoped it.
Marks the comparison stays a decision
- 01
The task decides
The field job, the devices, and the team come before the label native or cross-platform.
- 02
Accounts are part of it
Store ownership is mentioned, because a build without it cannot ship.
- 03
Offline is a factor
Weak signal changes the choice when the work happens away from a desk.
- 04
No single winner
The article does not crown one approach for every company.
Related reading
Flutter vs React Native
Both can ship the app. The maintaining team is the decider.
App cost in Dubai
What actually moves the price of an app for a Dubai business.
Mobile app development
Customer and field apps, native or cross-platform, on a real API.
Flutter
Cross-platform mobile when the interaction can truly be shared.Questions we hear
Is a progressive web app a third option?
Yes, when install and push are nice to have and the work is mostly online. It is a weak fit for a field tool that must behave well offline. The web development page covers PWAs.
Can we start cross-platform and rewrite later?
You can, and you should assume the rewrite is a new project. Do it only if version one needs to be in market and the native constraints are still hypothetical.
Does this change the Dubai cost bands?
Yes. Two native codebases are not priced as one Flutter app. The app cost guide says the same thing from the budget side.