Native, React Native, or just a good website?

"We need an app" is one of the most expensive sentences in small business. Sometimes it's true. More often, what the business actually needs is a website that works properly on a phone, at a tenth of the cost and none of the app-store hassle. Before anyone quotes you for iOS and Android development, it's worth understanding the three real options and the honest test for choosing between them.

Option 1: A good responsive website

A responsive site is one site that adapts to any screen. On a phone it looks and behaves like it was made for the phone, because it was. Done well, with fast load times and thumb-friendly buttons, it covers what most businesses mean when they say "app": customers can find you, browse, book, order, pay, and check on things from their phone.

What you skip by going this route is substantial. No Apple review process. No $99-a-year developer account. No maintaining two codebases. No begging customers to download anything, which matters more than people think: getting someone to install an app is genuinely hard, and most installed apps are abandoned within days. A website is one tap on a link from a text, an email, or a Google search. And Google indexes it, which an app's contents are not.

You can also make a website installable. A progressive web app (PWA) lets users add your site to their home screen where it opens full-screen like a native app, and it can even send push notifications on modern phones. For a lot of "we want an icon on their phone" requests, this is the whole answer.

Option 2: React Native (one codebase, both stores)

When you truly need a store-installed app, the next question is how to avoid building it twice. Native development means separate iOS and Android codebases, separate specialists, and roughly double the cost of everything forever.

React Native (and its main competitor, Flutter) is the middle path: one codebase written once, producing real installable apps for both platforms. The vast majority of business apps, meaning screens, lists, forms, photos, notifications, fit this model fine, and plenty of major companies ship this way. For a typical business app, cross-platform is what we'd reach for. Expect it to cost several times a website, but roughly half of going fully native.

Option 3: Fully native (Swift and Kotlin)

Native apps are written in each platform's own language: Swift for iOS, Kotlin for Android. You get maximum performance and first-day access to every device feature. You pay for it with two codebases and the biggest budget on this list.

For a business app, native is rarely justified. It earns its cost when the app is the product and pushes hardware hard: games, camera-heavy or AR apps, audio tools, anything where frame-level performance is the experience. If your app is fundamentally forms, lists, and statuses, native buys you nothing your users will notice.

The honest test: what does an app buy you?

A real app makes sense when you need capabilities a browser can't fully deliver. The big three:

• Push notifications as a core feature. If timely pings drive your model (order updates, dispatch alerts, appointment reminders that must land), native push is still the most reliable path, though web push has closed much of this gap.
• Offline use. Field crews in basements, drivers out of coverage, inspection forms filled out where there's no signal and synced later. Browsers offline are limited; apps handle this well.
• Deep hardware access. Continuous background GPS, Bluetooth connections to equipment, heavy camera processing. If your idea leans on the device itself, you need an app.

There's a fourth honest reason: frequency. If your customers will genuinely use this daily, an icon on the home screen and a saved login beat typing a URL. Be truthful with yourself about that "daily," though. Most businesses overestimate how often customers want to open their app by a wide margin.

And weigh the ongoing tax. An app is never done: both platforms ship OS updates every year, store policies change, and an unmaintained app eventually gets flagged or breaks. Budget for continuous upkeep, not a one-time build.

How we'd walk you through it

Our sequence with clients is consistent. First: does a responsive site (maybe as a PWA) do the job? For most, yes, and that's the recommendation even though it's the smallest invoice. Second: if the offline, push, or hardware test genuinely passes, we scope a React Native app, one codebase for both stores. Third: fully native only if there's a hardware-heavy reason, which for business software there almost never is.

The tell that you're getting good advice is the same as always: the builder starts with what your customers need to do, not with what they want to build. "You need an app" from someone who sells apps deserves the same scrutiny as "you need a new transmission" from someone who sells transmissions. Start with the website. Graduate to an app when the website provably can't do the job. That order protects your money.