Wrapped web app or React Native? We've shipped both

For a Belgian fashion brand, we built the backend, scan pages and owner app for a t-shirt with a unique QR code. The owner app is a web application wrapped as native builds, published to the App Store and Google Play, and this kept a three-month delivery realistic. For a UK automotive software company, we built a garage-booking SaaS with a Laravel API, a Next.js web application and React Native apps for iOS and Android, over about a year.

Don’t read those durations as a comparison. The second project was a complete multi-tenant product including its API and web app, so the difference in time says more about scope than about technology. Most of our work is delivered under NDA, so many projects cannot be named. We can’t share the numbers behind either app, so what follows is reasoning that you can test against your own project.

The wearable project sits on the left of this table: owners log in occasionally, upload media, write a message, preview and publish, while the people scanning a code use a fast web page with no app at all. The garage product sits on the right: car owners pick a slot, confirm, pay, receive their invoice and get reminded, so the phone is where the product lives.

A wrapped app runs your web application inside a native shell, with plugins reaching the device. React Native renders real native interface components from JavaScript or TypeScript. Both end up in the stores, and both can share code with a web team. They differ in what they share.

“We can reuse everything” is the claim to test. Reuse is real only if your web app already handles small screens, slow networks, the keyboard and a back button well. Otherwise, you’ve got a wrapped version of those problems, and they will now appear in one-star reviews.

Generic comparisons won’t tell you much, because the answer depends on what your app needs from the device. Go through this list with your own requirements, and mark each line “don’t need it”, “nice to have” or “can’t launch without it”. Only the last group should drive the decision.

The wearable app had a fixed idea and a three-month target. Its real complexity was on the server: print-ready batches of non-guessable codes, binding each code to a customer, a media pipeline with transcoding and signed URLs, and a scan page that had to be quick on any phone. The owner’s screens were simple by comparison, so building them as a web app and wrapping them put the effort where the product needed it.

The garage product sits differently. A car owner’s whole relationship with the service happens on a phone, and garages subscribe to it as a product. Appointment scheduling, billing, invoicing and reminders had to work for many garages, and UK conventions such as MOT, registration and VAT invoicing ran through it all. With a separate Next.js application for the web, sharing screens with mobile wasn’t the priority, while native apps could be built for how people use a phone.

Neither choice is permanent, so watch for these rather than defending the original decision.

• In a wrapped app: reviews complain that it feels slow or like a website, you keep writing custom native plugins, or a reviewer keeps questioning its purpose.
• In a React Native app: nearly every screen is a form that your website already has, upgrades take more time than features, or nobody on the team wants to touch the native tooling.
• In either: usage is so low that you have to ask whether people needed an app at all. Check that before paying for a rebuild.

• Store accounts and releases. Someone must own the Apple and Google accounts, certificates, privacy declarations and release notes. Set this up in the client’s name early.
• Review time. A rejection near a launch date is expensive, so submit well ahead. Apple can also ask you to change something you can’t fix in a day.
• Operating system updates. iOS and Android change every year, and either route needs some attention afterwards.
• Payments. Apple’s guideline 3.1.1 requires in-app purchase to unlock digital features, whichever technology you use. Selling physical goods or real-world services is treated differently, so read the rules that apply to your case.
• Notifications. These need server work as well as app work, including delivery tracking and opt-outs.
• Support for old versions. Users don’t all update, so your API has to keep older app versions working for a while.

On the wearable project, the people scanning a code never install anything, and that was a stated requirement. Scanning had to work on any phone. Before you commit to either route, ask whether an app needs to exist. If people only use it once, or arrive from a link, a fast mobile web page may serve them better. An app makes sense when people come back, when it needs the device, or when being on the home screen is the point. Asking people to install something is a real barrier, so it should be worth their trouble. A mobile page is also cheaper to change, works straight from a search result, and doesn’t need anyone’s approval to update.

The launch is the short part of an app’s life. Before you decide, picture a normal year after launch, and who is doing what.

Be honest about your team. An app built on React Native by a contractor and then handed to web developers with no native experience can age badly: one failed Xcode build can block a release for days. A wrapped app in the same hands stays close to work they already know. The reverse is also true. A strong mobile team will feel limited by a web view, and will spend their time fighting it.

• Which of our screens would be reused, and which rebuilt? Ask them to go through the list one screen at a time.
• Which device features need a plugin or library, and who maintains each one?
• Whose name will be on the Apple and Google developer accounts?
• What happens to the app when a new iOS version comes out? Is that included?
• Have you shipped this route to both stores? What did the reviewers ask about?
• If we want to change route in two years, what carries over?

1. Write down the five things users must do on a phone, in the order they matter.
2. Try the top two on your current mobile site, on a mid-range phone with a poor connection. If they feel fine, wrapping is a real option.
3. List every device feature you need. Check that a maintained plugin or library exists for each one on the route you are leaning towards.
4. Prototype the hardest screen. Do it in a wrapped shell, or in React Native if that is your leaning. Your hardest screen decides this more than your average one does.
5. Check who will own it in two years. A team of web developers will keep a wrapped app healthy more easily. A native team will be frustrated by one.

On both of these projects, a Laravel backend sits behind the mobile app. That decision does more for your future options than the choice between routes does. If business rules live in the API, you can replace the wrapped screens with React Native later and leave pricing, permissions and data untouched. We wrote up how in one Laravel API for web and mobile. If you are heading for a wrapped build, read getting a wrapped app through store review first.