React Native App in New Zealand

Where the savings actually come from

The pitch is one codebase for two platforms, and it is broadly true. In practice a React Native project shares most of its screens, its logic and its tests, and keeps a small amount of platform-specific work.

What stays shared:

• Screens, navigation, forms and lists — the bulk of most business apps.
• Business logic, validation, and everything that talks to your API.
• State management and offline caching.

What remains per-platform:

• Push notification setup, which differs meaningfully.
• Permissions dialogs and their wording.
• In-app purchases, if you sell digital goods.
• Store submission, screenshots and review responses — done twice.
• Testing, which is genuinely twice the work whatever the codebase.

So expect 30 to 50 percent less than two native builds, not 50 percent of one. A quote promising half the cost of a single native app has not accounted for testing on both.

Choose on the team, not the framework

React Native and Flutter are both good, and the honest differentiator in New Zealand is who will maintain the thing in three years.

React Native uses JavaScript or TypeScript. If your web application is already React, you can share people, patterns, sometimes validation logic, and hire from the same pool. For a business with a small technical team, that is the strongest argument available and it usually settles the question.

Flutter uses Dart, draws its own widgets, and gives more consistent visuals across platforms. It is excellent, and it is a separate skill set to hire and keep.

Ask each developer which they would use and why. An answer that is only about the framework's technical merits is less useful than one about who supports it afterwards.

Start with Expo unless there is a reason not to

Expo removes most of the native build configuration, handles builds and store submission, and makes upgrades far less painful. For the majority of apps it is the right default and it saves real money.

You move off it when you need a native library it does not support, which is less common than it used to be. That move is possible and not free, so ask the question now:

• Are you proposing Expo or bare React Native?
• What in our requirements might force us off it?
• What would moving involve if we needed to?

Be honest about what touches the device

React Native is a poor choice for a narrow set of apps, and it is worth checking whether you are in it before committing.

Warning signs:

• Heavy custom graphics or continuous animation — games, complex visualisation.
• Continuous background processing, such as tracking location all day.
• Real-time audio or video processing on the device.
• Needing brand-new platform features on the day they are announced.
• Deep integration with device management software on managed handsets.

If none of those describe your app — and for forms, lists, maps, camera, payments and notifications, none of them do — React Native is a sound and well-supported choice.

Over-the-air updates are worth setting up

Changes to the JavaScript layer can be pushed straight to installed apps without a store review. When something breaks on a Friday afternoon, that is the difference between a fix tonight and a fix on Tuesday.

Native changes still need a store release, and both Apple and Google permit over-the-air updates within limits — using them to substantially change what the app does is against the rules and is not worth testing.

Ask whether it is in the quote. It is much cheaper to include from the start than to add once the app is live.

Own your own store accounts

The Apple Developer account and the Google Play developer account should be in your company's name, paid on your card, with your people as administrators. Your agency gets added to them.

Set up the Apple one early — verifying a New Zealand company can take a week or two, and it is a miserable thing to discover in launch week. These accounts own your app's identity, your ratings and your install base, and holding them yourself is what makes changing developer a decision rather than a negotiation.

The backend is often the bigger half

The most common gap between two quotes for the same app is whether the server side is included. An app is a window onto something, and that something needs building, hosting and securing.

Ask explicitly: does this quote include the API, the database, hosting, the admin screens your staff will need, and authentication? A quote covering only what runs on the phone can look 40 percent cheaper and be for half the job.

Comparing five quotes

Read for:

• Whether the backend is in the quote or assumed.
• Expo or bare, and whether they explained the trade.
• Whether testing on both platforms is costed honestly.
• Who owns the store accounts and the code at the end.
• What the year-two maintenance figure is, given both platforms change annually.

Describe who will use the app, the three things they must be able to do, whether it must work without signal, and what it connects to. Developers who ship React Native regularly will ask about the API before they ask about the screens.