ReactWebApptoMobile:Wrap,Rewrite,orNeither?

Introduction

Your React app works. Real users, real revenue, three years of decisions baked into it. Then a customer asks why there's no app, or sales loses a deal to someone with a store listing, and suddenly mobile is on the roadmap with no budget attached and no plan behind it.

So you search. And the internet gives you two kinds of answer, neither of which is about your codebase.

The first kind is a tutorial. Install Capacitor, run two commands, your app is on a phone in five minutes. That's true. I've done it. It's also the least useful true thing anyone will tell you this month, because shipping was never blocked on those two commands.

The second kind is a comparison post arguing about rendering architecture. WebView versus native bridge, benchmarks, a table with ticks in it. Also true, also written as though you were starting from nothing. You're not starting from nothing. You're starting from an app that already has auth, routing, a state layer, a payment integration and a support team who knows how it behaves.

This guide is about that. What actually moves, what quietly does not, and the App Store rule that decides whether the five-minute version was ever going to work. For the effort drivers behind the mobile build itself, see our React Native app development cost breakdown.

> Any agency that quotes you a React Native rebuild before asking what your app needs to do on a phone has told you something useful about how they scope work.

Do You Actually Need an App, or a Better Mobile Site?

Start here, because a meaningful share of the teams who ask us this question don't need a mobile app and are about to fund a second product to maintain forever.

An app is not a distribution channel you switch on. It is a separate build, a separate release process gated by two review queues, separate crash reporting, separate analytics, and a support burden that scales with the number of OS versions your users are running. All of that is worth paying when the app does something. It's pure cost when the app is your website in a box.

Two questions settle this faster than a workshop. First, what does the app do that the mobile site cannot? Second, who specifically asked for it?

If the honest answer to the first is nothing, and the answer to the second is a board member rather than a user, you've got a mobile web problem wearing a mobile app costume. Fix the responsive layout, get the Core Web Vitals under control, add a home screen install prompt, and spend the rest on the product.

We tell people this regularly and it costs us work. It's still the right answer, and the teams we say it to tend to come back later with something real.

There is one exception worth naming, because it is legitimate and people feel guilty about it. Sometimes the requirement genuinely is the store listing itself. Enterprise buyers ask for it, procurement checklists have a line for it, and some categories of customer do not believe a product exists until they can find it in the App Store. That's a real business requirement even though it isn't a technical one. Just be honest that it's the reason, because it changes what you build. If the listing is the point, you want the cheapest credible app that survives review, not an eighteen month native rewrite.

What Does Your App Need to Do on a Phone That a Browser Cannot?

This is the question that decides the whole thing, and almost nobody writes the answer down before choosing a framework.

Modern mobile browsers do far more than most people assume. Camera capture, geolocation while the app is open, push notifications on both Android and iOS, offline caching, payments through the browser payment sheet, biometric login through passkeys. If your requirements sit inside that list, the WebView route isn't a compromise. It's the correct engineering decision and it keeps you on one codebase.

The gap opens on a specific and fairly short list of things. Background execution when your app is closed. Continuous location tracking for fleet or delivery work. Bluetooth Low Energy for hardware. Sustained sixty frames per second on gesture-driven interaction. Large lists with cell recycling under real data volumes. Offline-first behaviour where a user works disconnected for hours and you resolve conflicts on reconnect. Deep integration with platform surfaces like widgets, share sheets, Siri or health data.

Every one of those is a genuine reason to render natively. None of them are reasons to rebuild your API client, your validation, your pricing rules or your permission logic, which is what a rebuild quote usually includes.

Take that table to your product owner before you take it to an engineer. If nothing in the right-hand column is a requirement, you have your answer and it's the cheap one.

Can You Just Wrap Your React App and Ship It?

Mechanically, yes, and it is worth understanding what is actually happening rather than treating it as magic.

Capacitor builds a small native application for iOS and Android whose main view is a full-screen WebView. Your compiled React bundle is copied into that app and loaded from local storage rather than over the network, so it starts without a round trip. Alongside it sits a bridge, and plugins registered on that bridge expose native capabilities to JavaScript. You call the camera plugin, the bridge calls the platform API, the result comes back as a promise. Your React code stays React code.

That's the whole model, and its strength is that it doesn't ask you to rebuild anything. Your components, your styles, your router, your state management and your tests all continue to exist. One codebase serves web and mobile. Your existing team ships it, because it is the stack they already know.

The weaknesses are equally concrete and worth hearing before you commit. Everything renders in a WebView, so anything that feels sluggish on mobile Safari will feel sluggish in the app, and users will blame the app. Scroll momentum, keyboard handling and safe-area insets need real attention or the result reads as a website in a frame, which is the specific thing reviewers are looking for. Any web SDK that renders an iframe may misbehave inside the shell. And you inherit a native project you now have to maintain, sign, and update when the platforms change.

None of this makes it a bad choice. We've shipped this pattern and it holds up. It's a bad choice only when the requirements in the previous section said native and somebody picked the cheap path anyway.

Will Apple Reject a Wrapped Web App?

It rejects apps that are only a wrapper, and this is the surprise that costs teams the most because it arrives after the work is finished.

App Store Review Guideline 4.2 is titled Minimum Functionality. The text asks that an app offer features, content and UI that carry it past being a repackaged website, and that if an app is not particularly useful, unique or app-like, it does not belong on the App Store. Read that against a Capacitor build whose entire content is your existing responsive site, and the problem isn't subtle.

Be clear about what the rule does not say. It doesn't ban WebViews and it doesn't ban Capacitor. Capacitor applications ship on the App Store in large numbers, including from companies you have heard of. The reviewer is not detecting a framework. They're opening your app, deciding whether it does anything a Safari tab wouldn't, and applying judgement.

So the work is to make that judgement easy. Push notifications the web version does not have. Biometric sign-in. Offline access to something the user actually needs offline. Native share. A home screen or tab bar that belongs on a phone rather than a desktop navigation squeezed narrow. Camera capture wired to a real workflow. Any of those, done properly, moves you out of the category the rule describes.

Plan for it up front. Adding native capability before the first submission is a scoped piece of work. Adding it after a rejection means a second review cycle, a release date you have already told customers about, and an engineer explaining to a founder why the five-minute conversion took six weeks.

Google Play is more permissive here and accepts a PWA through a Trusted Web Activity. That asymmetry catches people out. If the actual requirement is an App Store listing, the iOS path is the one that has to be planned around, and a PWA doesn't reach it.

Can You Share Code Between React and React Native?

Yes, and the useful version of that answer is that you share logic, not screens.

The split runs along a clean line. Anything that does not render moves across with little or no change. Your API client and its error handling. Validation schemas. Business rules, pricing logic, permission checks, feature flags. State stores, whether Redux, Zustand or something you wrote. Date, number and currency formatting. TypeScript types. Test fixtures and most of the tests that exercise logic rather than DOM.

Anything that renders doesn't move. React Native has no div, no CSS cascade, no stylesheet files and no DOM. Components are rebuilt against View, Text, Pressable and FlatList, with styles as objects and layout through Flexbox that behaves similarly but not identically to the web.

Now the part worth being careful about, because it's repeated everywhere including by pages ranking above this one. You'll read that Instagram shares 99 percent of its code and Shopify hit 86 percent. Both numbers are real and both describe sharing between iOS and Android inside React Native. Neither is a web-to-native number. Quoting them to a founder with a React web app sets an expectation the project cannot meet, and when reality lands at a much lower figure it looks like the team underdelivered rather than like the number was wrong.

The number that matters is yours, and you can measure it in an afternoon. Count the lines in your components directory against the lines everywhere else. That ratio is roughly the share of your front end that gets rebuilt, and it is the single most useful input to this decision. Teams with a disciplined separation of logic and presentation are frequently pleasantly surprised. Teams whose data fetching lives inside their components aren't, and they learn something important either way.

What Does Not Survive the Move to Native?

The obvious answer is styling, and everybody plans for that. The expensive answers are the ones nobody puts in the estimate.

Routing is the first. React Router models URLs. React Navigation models stacks, tabs, modals and a hardware back button on Android that has opinions. These aren't the same idea with different names, and a deep link that worked as a URL now needs a native linking configuration on both platforms.

Storage is the second. Every localStorage and sessionStorage call has to become an async storage call, which means synchronous code paths become asynchronous, which means the components that read them change shape. This one is mechanical, tedious, and consistently underestimated because it's scattered.

Authentication is the third and it's the one that hurts. Web auth leans on cookies, redirects and a browser that manages sessions for you. On native there are no cookies in the same sense, OAuth runs through a system browser component with its own callback handling, and token refresh becomes something you own rather than something the browser does. Teams routinely treat auth as done because it works on web, then lose two weeks to it.

Then the long tail. Third-party web SDKs that inject scripts or iframes, which often means analytics, chat widgets, payment elements and map libraries, all of which need native replacements with different APIs. File inputs and drag and drop. Anything reading window or document. Web workers. Service workers. Print. Right-click. Hover states, because there's no hover on a touch screen, and any UI whose affordance depends on hover has a usability bug the moment it moves.

None of this is a reason to avoid React Native. It's a reason to insist that anyone quoting the work has read your code first, because these items are invisible from the outside and they're most of the difference between the estimate and the invoice.

Is a React Native Rewrite Ever the Right Call?

Yes. Saying otherwise would be its own kind of selling, just pointed in the friendlier direction.

A native front end earns its cost in four situations. When the mobile product is genuinely a different product rather than the same screens on a smaller screen, which is common in field service, logistics and anything where the phone is the working tool. When performance in a WebView is what customers complain about, and you have evidence rather than a hunch. When offline-first is a requirement with real conflict resolution behind it. And when the app is your primary surface, with the web version as the secondary one, because that reverses which experience deserves the investment.

Notice what those have in common. Each one names a capability or a constraint. None of them is a preference about frameworks.

The signal that a rewrite is wrong is simple and you can test it in a meeting. Ask what the app will do that the current product cannot. If the room can't answer without talking about technology, the rewrite is a rebuild of something you already own, priced as new work.

One more thing worth saying plainly, because it is the fear behind this entire search. Choosing React Native doesn't mean throwing your app away. Your backend is untouched. Your API contract is untouched. Your business logic moves across. What gets rebuilt is the presentation layer, and on a well-structured codebase that is a smaller fraction of the whole than the word rewrite suggests. Anyone using the scale of the word to justify the scale of the quote is worth a second opinion.

Who Should Not Call Us About This?

Four situations where we're the wrong call, and we'd rather say it here than in a first meeting.

If you have not launched yet. Build one thing properly for one platform, find out whether anyone wants it, and revisit this when you have users asking for the app rather than a roadmap that assumes them.

If your app is an internal dashboard people open at a desk. You don't need a store listing. You need a responsive layout that works on a tablet and possibly a home screen shortcut. That is a week of front end work, not a project.

If what you want is an app store presence and nothing more, and your existing site is already a decent mobile experience. There are commodity wrapper services that do exactly that job for a fraction of what a development partner charges, and using one is a reasonable decision. Bring us in when the wrapper stops being enough.

If you have already decided, before any audit, that the answer is a full native rewrite. Not because you're wrong, you might be right. But we'd want to read the code before agreeing, and if that conversation isn't welcome then we're not the right shape of partner for you.

Everyone else, meaning teams with a live React product, real users, and a mobile requirement they can actually articulate, is exactly who this work suits.

How We Approach a Web to Mobile Move

In the same order every time, because the expensive mistakes all come from skipping the first step.

1. Write down what the phone has to do. Not features, capabilities. Background work, offline, hardware, gestures, platform surfaces. This is a conversation with product, not engineering, and it usually takes an hour.

2. Measure the logic to presentation ratio in your codebase. How much of your front end is components, and how much is logic that ports untouched. This turns the whole decision from an argument into arithmetic.

3. Pick the approach from those two answers. Shallow native needs and a heavy component layer point at Capacitor. Deep native needs, or a clean logic layer that ports easily, point at React Native. Neither one, and the answer is a better mobile site.

4. Fix what the audit found first. Data fetching tangled into components, auth that assumes cookies, storage calls scattered everywhere. These get cleaned up in the web app, where they are cheaper to fix and where the fix also improves the product you already have.

5. Ship a thin vertical slice. One real flow, end to end, on a real device, through a real signing pipeline, into TestFlight. The estimate for everything else is worth having only after this exists.

6. Plan the store submission as work, not paperwork. Native capability for Guideline 4.2, privacy declarations, screenshots, certificates, review timing. Put it in the plan at the start rather than discovering it in week nine.

We have shipped React and React Native products at scale, including an EdTech platform serving 250,000+ daily users and an exam system handling 10M+ requests a minute, and fleet software tracking 30,000+ vehicles for Pixytan. We are a product development partner rather than a staffing marketplace, so an engagement means a team owning delivery of a defined outcome, and you own the code from the first commit.

Where This Leaves You

The five-minute conversion is real. It's just not the project.

The project is deciding what the mobile version of your product actually is, and that decision is made from your requirements and your codebase rather than from a comparison table. Wrap it when the phone is doing the same job on a smaller screen. Render natively when the phone is doing something the browser genuinely cannot. Build neither when nobody can say which of those is true, because that answer arrives eventually and it's cheaper to wait for it than to fund the wrong one.

If you want the arithmetic rather than an opinion, send us the repository. A senior engineer reads it and comes back with the ratio, the list of things that will not port, and which of the three answers your product points at. Free, and no obligation follows it.

If the budget question is the one in front of you right now, our React app development cost breakdown and the React Native cost drivers cover what moves the effort on each side. For teams whose current app came out of an AI builder rather than a hand-written React project, taking a Lovable app to production is the closer starting point.