What the choice actually is
A native app is written in each platform's own language and toolkit: Swift for iOS, Kotlin for Android. Two platforms means two codebases, usually built by two sets of specialists. React Native lets a team write one app in JavaScript or TypeScript with React; its own description is "written in JavaScript, rendered with native code", with components that map to each platform's native building blocks [1]. The screens are real native screens, not a web page in a wrapper.
It is not a niche choice. The React Native site lists apps from Meta, Microsoft (including Office, Outlook and Teams), Shopify and Discord among those built with it [1]. Flutter is the other common cross-platform option, with similar trade-offs and its own rendering approach; most of what follows applies to it too.
Where React Native is the better call
- Business apps built from forms, lists, dashboards, bookings, payments, messages and notifications. This is most apps.
- Products that also have a web app. React skills, and some code such as data models and validation, are shared with the web.
- Teams that want one codebase to maintain, one set of tests, and features that arrive on both platforms at the same time.
- Projects where getting to both stores within one budget matters more than squeezing out the last bit of platform polish.
When a React Native app needs something the framework does not provide, such as a particular Bluetooth device or a platform-specific widget, a native module is written for that piece in Swift or Kotlin. The rest of the app stays shared.
We usually start React Native projects with Expo, an open-source toolkit around React Native that handles builds, store submissions and updates, and add native modules only where a feature needs them. It keeps the project close to the standard path, which makes upgrades easier and the code easier for another team to take over.
Where native earns its extra work
- Heavy graphics, real-time camera or audio processing, augmented reality and games, where every frame counts.
- Deep platform integration: widgets, watch apps, car displays, background processing with strict limits, or new platform features on the day they ship.
- Apps that only ever need one platform, such as an internal iPad app for a team that only uses iPads.
- Organisations that already have strong iOS and Android teams and the budget to keep both busy.
Side by side
| React Native | Native (Swift and Kotlin) | |
|---|---|---|
| Codebases | One, with small native modules where needed | Two, one per platform |
| Look and feel | Native components; very close to native for business apps | Exactly native, with every platform detail available |
| Performance | Fine for typical apps; heavy graphics need care or native modules | Best possible, with direct access to every platform API |
| New platform features | Usually available after a delay, or through a native module | Available on release day |
| Shared with a web app | Skills, and some code such as validation and data types | Little or nothing |
| Team | React and TypeScript engineers, plus some native knowledge | iOS and Android specialists |
| Maintenance | One set of features and tests; framework upgrades to plan for | Two sets of features and tests to keep in step |
What the app stores require either way
The stores do not care how an app is built, but they do set rules that shape every mobile project and its calendar.
- Review takes time. Apple states that on average 90% of submissions are reviewed in less than 24 hours [2], but a rejection means a fix and another review, so plan launches with margin.
- Apple's guidelines say an app should offer features, content and interface that elevate it beyond a repackaged website [3]. A web page in an app shell is likely to be rejected.
- Apple's guideline 2.5.2 says apps may not download or execute code that introduces or changes features or functionality [3]. React Native apps can push some updates over the air, but new features belong in a reviewed release.
- Google Play requires new apps and updates to target a recent Android version: from August 31, 2026, Android 16, API level 36, for most apps [4]. The requirement moves up as Android does, so every app needs regular upgrades to keep shipping updates.
That last point is a running cost of any mobile app, native or not. Platform upgrades, new device sizes and store policy changes arrive every year, so budget for maintenance from the start.
When you need neither
Some apps do not need to be in a store at all. A responsive web app works on every phone, can be added to the home screen, and updates the moment you deploy, with no review. If your users visit occasionally, find you through search or links, and do not need offline use, background location or rich notifications, start on the web.
- Good fits for the web: customer portals, booking and ordering, dashboards, internal tools used at a desk as well as on the move.
- Good fits for a store app: daily-use products, offline work in the field, camera and sensor features, reliable push notifications, and anything users expect to find in a store.
- A common path: launch the web app, learn what people use on their phones, then build the mobile app for those journeys.
Starting on the web is not wasted work. The backend, the admin side, the data model and much of the design carry straight over to the mobile app, so the second step costs less than starting there would have.
The half of a mobile app nobody sees
Whichever way the screens are built, much of a mobile project is the same work underneath, and it is often the larger part.
- The backend: the server, database and APIs the app talks to, with sign-in, permissions and an admin side for staff. Native or React Native, this is shared.
- Offline and sync: if people use the app where the signal is poor, it has to store work on the phone and reconcile it later without losing or duplicating anything. This is design work as much as code.
- Push notifications: certificates and keys for Apple and Google, a service to send them, and settings so users control what they receive.
- Testing on real devices: different screen sizes, older operating system versions, slow networks and interrupted sessions. Automated tests cover the logic; people with real phones cover the rest.
- Release management: store listings, screenshots, privacy disclosures, staged rollouts, crash reporting and a way to roll back.
A quote that prices the screens but not this half will move. Ask for it to be listed.
Two mobile projects, priced from our rate card
The worked examples below show the range from our rate card today, with the hours by role and the payment schedule. The first is an iPhone app on its own. The second covers iOS and Android with a web app and an admin side. If you choose two separate native apps instead of one shared codebase, most of the mobile work is done twice; open either example in the estimator and we can price that variant with you.
Worked example, priced now
An iPhone app
Sixteen screens on iOS with sign-in, in-app payments, push notifications and analytics, on a custom design, holding personal information.
- Build
- ≈ US$57,200 to US$87,400, delivered within 26 weeksCAD 81,400 to 124,400
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Estimated effort by role
- Development
- 318 to 486 h
- Product designer
- 57 to 87 h
- QA engineer
- 39 to 59 h
- Senior backend developer
- 38 to 59 h
- Senior product designer
- 38 to 58 h
- Project manager
- 37 to 57 h
- Backend developer
- 35 to 54 h
- Frontend developer
- 32 to 49 h
- Mobile developer
- 25 to 39 h
- Senior engineer
- 24 to 36 h
- Software architect
- 21 to 32 h
- Senior mobile developer
- 20 to 30 h
- Senior frontend developer
- 19 to 29 h
- Junior backend developer
- 18 to 27 h
- Junior frontend developer
- 13 to 19 h
- Junior mobile developer
- 11 to 17 h
- Technical writer
- 7 to 10 h
- DevOps engineer
- 6 to 10 h
How it is paid
- Deposit 20%
- CAD 16,280 to 24,880
- Discovery 10%
- CAD 8,140 to 12,440
- Design approved 10%
- CAD 8,140 to 12,440
- First build on devices 30%
- CAD 24,420 to 37,320
- Store submission 10%
- CAD 8,140 to 12,440
- Launch 10%
- CAD 8,140 to 12,440
- Holdback, 30 days after launch (10%)
- CAD 8,140 to 12,440
Worked example, priced now
iOS and Android apps with a web app
Twenty-two screens across iOS, Android and the web, with sign-in, payments, a staff admin side, notifications and analytics, and a support plan after launch.
- Build
- ≈ US$97,600 to US$149,000, delivered within 25 weeksCAD 139,000 to 212,600
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Estimated effort by role
- Development
- 528 to 807 h
- Product designer
- 107 to 164 h
- Senior product designer
- 71 to 109 h
- Project manager
- 68 to 104 h
- Frontend developer
- 64 to 98 h
- Senior backend developer
- 63 to 96 h
- QA engineer
- 61 to 93 h
- Backend developer
- 57 to 88 h
- Senior engineer
- 40 to 61 h
- Senior frontend developer
- 38 to 59 h
- Mobile developer
- 34 to 52 h
- Software architect
- 34 to 52 h
- Junior backend developer
- 29 to 44 h
- Senior mobile developer
- 27 to 41 h
- Junior frontend developer
- 26 to 39 h
- Junior mobile developer
- 15 to 23 h
- DevOps engineer
- 13 to 20 h
- Technical writer
- 11 to 16 h
How it is paid
- Deposit 20%
- CAD 27,800 to 42,520
- Discovery 9.2%
- CAD 12,788.00 to 19,559.20
- Design approved 9.2%
- CAD 12,788.00 to 19,559.20
- Core features 7.6%
- CAD 10,564.00 to 16,157.60
- Full build 5%
- CAD 6,950 to 10,630
- First build on devices 20.1%
- CAD 27,939.00 to 42,732.60
- Testing and fixes 2.5%
- CAD 3,475 to 5,315
- Store submission 6.7%
- CAD 9,313.00 to 14,244.20
- Launch 9.7%
- CAD 13,483.00 to 20,622.20
- Holdback, 30 days after launch (10%)
- CAD 13,900 to 21,260
After launch, either way
A mobile app is never finished in the way a website can be. Each year brings new operating system versions, new devices and new store rules, and users expect the app to keep up. Plan for a release rhythm, monthly or quarterly, that bundles small improvements with the upgrades the platforms require, and keep crash reporting and analytics running so you know which problems matter. With React Native, add framework upgrades to that list; with native apps, do everything twice.
How to decide
- 01
List the features that touch the device
Camera, location, Bluetooth, background work, widgets, health data. Each one is a question about native support.
- 02
Ask whether any must be best-in-class
If one feature is the product, such as a real-time camera effect, it may justify native code for that feature or the whole app.
- 03
Check your platforms
If your users are on both iOS and Android, a shared codebase is the default. If they are all on one, native for that one is reasonable.
- 04
Think about the web
If you also need a web app, React Native shares skills and some code with it.
- 05
Plan the years after launch
Who will maintain it, and can you hire for it? React and TypeScript engineers are easier to find than two native specialists.