Native or React Native for a hospitality app?

"Native or React Native?" is usually the first question in a hospitality brief. It's the third one we answer. Three of the six projects on this site are hospitality or culture apps — a destination guide, a self-guided audio tour, a visitor CRM with a partner scanner — and a fourth reads rapid tests through a phone camera. All four shipped in React Native. That's a record, not a policy. Here's the order we ask in, and where the answer would have flipped.

Does it need to be an app at all?

We've written this one up, so the short version: about half the mobile briefs we see are a web flow with one notification permission. Hospitality makes the split unusually clear. A guest booking a table doesn't want to install anything. A partner scanning perks all shift, or a visitor walking a route with no signal, does. We say yes to the install when the phone is the work surface. When it's only the destination, we ship the web flow and keep the budget.

Which features force the install?

The ladder above is the order. Five features force the install, in practice: a camera that scans or captures, location that works with the screen off, content that has to be there with no signal, audio that keeps playing in a pocket, and push that arrives without a saved-to-home-screen ceremony. Our three hospitality apps needed, between them, live location with map directions, a background player with offline downloads and presence tracking, and QR scanning on the partner side with a visitor app and an operator dashboard on one stack. The test reader needed the camera. Every one of those lists sounds like a case for Swift and Kotlin. None of them was, yet.

When is React Native enough?

The test we actually use for native vs React Native: is the native part capture-and-hand-off, or a continuous loop? Take a photo and read it, scan a code, get a location fix, play a downloaded file — solved problems with maintained native modules, and React Native wraps them well. Read a video stream at thirty frames a second, drive a Bluetooth printer, draw an AR overlay — those are loops, and the bridge becomes the thing you debug. All four apps here were hand-offs. The other half of the test is people. The three hospitality apps each shipped next to a Next.js web side, built by the same three of us in the same language. For a four-person studio, one codebase for iOS and Android beats the last ten percent of scroll performance.

When does native win?

The table above is the sort for our four. Native wins when the native capability is the product. If the test reader had to read the strip live through the viewfinder instead of from a photo, we'd have written it in Swift and Kotlin — that's a loop, and the loop is the whole point. Same for an audio guide that processes sound rather than playing it, AR wayfinding in a museum, a watch app, or a scanner that talks to a receipt printer all day. It goes for teams too: if the people who'll own the app in 2028 write Swift and Kotlin, we hand them Swift and Kotlin. React Native is a decision about who maintains the code, not a belief about frameworks. Even then, our first move is a native module for the one loop that needs it. A rewrite is the last resort.

What about Flutter?

It's on our stack list and it belongs there. Flutter is strong when the interface is custom-drawn and the team is at home in Dart. None of the six projects on this site used it, for the reason above: every app here shared a language and a team with a Next.js admin, website or CMS, and the person inheriting it writes TypeScript. We like Dart fine. We just don't have anyone to leave it with.

What does hospitality change?

Three things we learned on the job. Staff have a phone in one hand and a tray in the other, so the scanner works in one tap or it doesn't get used. Sites have bad signal — a heritage site, a beach, a basement — so offline isn't a feature, it's the product; the audio tours download before the walk, not during it. And the operator matters more than the visitor: on the destination CRM, the dashboard was what won internal trust, and we'd ship it first next time. One more, from the destination app: decide what a "place" is before the first screen. A beach, a museum, a trail, a viewpoint and a seasonal kiosk do not belong in the same model. They absolutely do not.

So which do you pick?

In this order. One: make the brief argue itself into an install; if it can't, it's a web flow. Two: list every hardware feature and mark each one hand-off or loop. Three: ask who maintains it in 2028 and what they write. Four: design the web side with it, not after it — every hospitality app here shipped with one. Five: if anything is a loop, or the team is native, go native for that app, module first, rewrite last. If nothing is, React Native, and spend the saved weeks on the empty states and the offline path. That's where these apps get judged.

What changed since we started asking in this order: the framework debate got short. Nobody at the table defends a toolchain; we sort a feature list into two columns. On this site the sort came out React Native four times out of four. The next brief with a live viewfinder or a printer on the belt comes out differently — and we'll say so before the budget is spent. That part is the rule.