Native or cross-platform? Choosing how to build a business app in 2027

If you are planning an app for customers or field staff, you will hit the native vs cross platform app development question early. Native means separate apps written in each platform's own language: Swift for iPhone, Kotlin for Android. Cross-platform means one codebase that produces both, most often with React Native or Flutter.

We ship both kinds. Most of our client apps use React Native with Expo, and our trip planner for Vermont buses, BTV Transit, is a fully native iPhone app. This post gives the criteria we use to choose, including the one people skip: you may not need an app at all.

First question: do you need an app?

A well-built web app works on every phone, needs no store approval and updates the moment you deploy. Before committing to an app, ask whether people will:

• Use it often enough to install it, such as daily or weekly.
• Need it without a signal, such as in a basement, on a rural road or in a warehouse.
• Rely on push notifications they can't miss.
• Need device features a browser handles poorly, such as background location, Bluetooth hardware or lock-screen widgets.

If the honest answer to all four is no, start with a responsive web app. After all, customers who visit once a month won't install anything. Field staff with good signal can often use a web app saved to their home screen.

The criteria for native vs cross platform app development

Five criteria decide most projects.

Offline use

Both approaches can work offline, but the design matters more than the tool. Data has to be stored on the device, changes queued and synced, and conflicts resolved when two people edit the same record. So plan this from the start; it is hard to add later.

Device and platform features

Cross-platform tools cover cameras, location, push notifications, biometrics and most everyday features well. However, the gaps are newer or deeper platform features: Live Activities on the iPhone lock screen, the Dynamic Island, widgets, Apple Watch apps and some kinds of background work.

The usual answer is not "go fully native." Instead, it is cross-platform for the app, with small native modules for the parts that need them. Our React Native apps drop into Swift or Kotlin where the platform asks for it. For example, a fitness app we build has a native SwiftUI watch companion that works alongside its React Native phone app.

Team size and cost

One cross-platform codebase means one team and one set of features to build and test. For most business apps, that gives you both stores for close to the cost of one. By contrast, two native apps mean two codebases that drift unless you pay to keep them in step.

Update speed

Every app update goes through store review. Apple's App Review page says that, on average, 90% of submissions are reviewed in less than 24 hours, though first releases and rejections can take longer. Expo also supports over-the-air updates for JavaScript changes within the rules both stores set, which helps with small fixes.

Performance

For forms, lists, maps and dashboards, users can't tell a modern React Native app from a native one. Fully native earns its keep for heavy on-device computation, advanced graphics or apps that live mostly on the lock screen and in the background.

Why we built each app the way we did

StackPilot is a companion app for watching and controlling Heroku apps from a phone, on iPhone and Android. It needed both platforms from one team, so it is cross-platform. Its iPhone Live Activities and Dynamic Island support come from native work where React Native doesn't reach.

BTV Transit plans trips across every Vermont public bus timetable on the phone itself, so planning works without a signal on rural routes. It follows the ride and alerts riders before their stop, using location in the background, with Live Activities on the Lock Screen. It is iPhone only, and nearly everything that matters happens in platform features, so we built it natively in Swift. We wrote about how it decides when to tell you to get off.

Split & Pay splits a bill with a link anyone can open. Most participants never install anything, so public web pages that need no sign-up do much of the work, beside a React Native app for iPhone.

A quick decision guide

• Customers visit rarely, no device features: responsive web app.
• Staff or customers use it often, on both platforms: cross-platform, with native modules as needed.
• One platform, and the product lives in platform features: native.
• Unsure: start with a web app or a cross-platform app focused on one job, and learn from real use.

Things that matter whichever way you go

1. Publish under your own developer accounts. You keep the listings, reviews and customer relationship.
2. Plan for new OS versions every year. Apps need updates when iOS and Android change.
3. Design for weak connections. Show what is cached, queue what can wait, and say clearly when something didn't send.
4. Keep data on the device where you can. It is faster, and it is better for privacy.

For the integration side of a business app, such as syncing jobs or hours into QuickBooks, see when an integration beats double entry. Our mobile apps page covers how we build and release apps.

Talk about your app

Tell us who will use it, how often, and where they will be when they do. We reply within one business day, and if a web app would serve you better, we will say so. Get in touch.

Cover photo by Balázs Kétyi on Unsplash.