Native, React Native, or web app: how to actually choose

Here is the short answer. Choose by distribution and hardware needs, not by fashion. If your user arrives through a link or a QR code and should install nothing, build for the web. If you need a real presence in both app stores and want one team maintaining one codebase, build with React Native. If the product depends on deep hardware access, a watch, or health integrations, build native. Everything else in this guide is the reasoning behind those three sentences.

The question that decides it

Most technology debates about apps start in the wrong place: with the technology. The useful starting point is two questions about your product. First, how does your user arrive? By tapping a link someone shared, by scanning a code on a table, by searching an app store, or by opening something already installed on their home screen? Second, what does the app actually need from the device? A screen and an internet connection, or the camera, offline storage, push notifications, background location, a paired watch?

Answer those two honestly and the platform choice usually makes itself. The rest is budget and timeline, and both of those also follow from the same two answers.

Web and PWAs: the underrated default

If the user arrives by link or QR code, any install step is a wall between them and your product. Nobody standing at a restaurant table is going to download an app to read the menu. That is why Smart Menu, Cazullo's digital menu product, is a web app: a guest scans the code and the menu is simply there, in their language, with photos, in seconds. An app store would add friction and subtract users.

The modern web also goes further than many buyers assume. A progressive web app, a PWA, can be pinned to the home screen, work offline, and sync when the connection returns. A field sales team can run its whole day on an offline-first PWA without anyone ever touching an app store, and the company ships updates instantly, with no review queue and no waiting for users to update. For products that live inside a browser moment, the web is not the cheap option. It is the correct one.

React Native: one team, two stores

Sometimes the store presence is the product. A community commerce app that people search for by name, keep on their home screen, and open every week earns its place as an installed app. The classic problem is cost: building the same product twice, once in Swift for iOS and once in Kotlin for Android, means two teams, two codebases, and every feature paid for twice.

React Native solves exactly that. One codebase, written by one team, compiles into real apps for both stores. This is how the Cazullo Platform works: the white-label local commerce apps are built with React Native and Expo, and a single codebase publishes many branded apps, each under its own name, to both the App Store and Google Play. When a feature ships, every brand's app gets it. That economics is impossible with two native codebases and unnecessary for products that do not push the hardware to its limits.

Native: when it earns its cost

Fully native development, Swift on Apple platforms or Kotlin on Android, is the most expensive path, and sometimes it is worth every dollar. The signal is depth of integration. If the product needs an Apple Watch app, reads and writes health data through HealthKit, or leans on platform features the moment they are announced, a cross-platform layer becomes friction instead of leverage.

Cazullo builds native Swift when the product is Apple-ecosystem-first: when the watch, the health data, and the tight integration with the device are the product, not a nice-to-have. In that situation, native is not a status symbol. It is the only tool that reaches the thing you are selling.

The wrong reasons

• Choosing native for status: "a real company has a native app" is branding logic applied to an engineering decision, and it can double the budget for zero user-visible benefit
• Choosing web only because it is cheaper, when being found in the app store IS the marketing plan: if users search a store by name, saving money by not being there is not saving
• Rebuilding a perfectly good web product as an installed app with no device need behind it: an app that could have stayed a website adds install friction, review cycles, and update lag for nothing

Checklist

• How does the user arrive: by link and QR code, or by searching an app store?
• Would a mandatory install step lose the user at the exact moment they wanted you?
• Does the product need hardware the browser cannot reach: watch, health data, background sensors?
• Do you need to be present and searchable in both app stores from day one?
• How many codebases can your team and budget honestly maintain for years?
• How often will you ship updates, and can you tolerate store review delays?
• Does the app need to work offline, and how deeply?
• Could a PWA cover the offline and home-screen needs without a store at all?

Our closing recommendation is simple. Default to the web, and stay there while it serves your user. Move to React Native when the store presence and the installed relationship genuinely matter, and let one codebase carry both platforms. Reserve native for the products where the device itself is the point. The best platform is not the most impressive one. It is the one your user never has to think about.