If you already have a working website, putting it in the App Store and on Google Play looks like it should be a packaging problem. Most of the time it is not. The question that decides your cost, your timeline and whether you get rejected is not how you build the app — it is how much of the app is allowed to be the website.
There are four realistic routes. They are not interchangeable, and the cheapest one is not always the one that ships.
1. A Progressive Web App
A PWA is your site with a manifest and a service worker. People can add it to the home screen, it can work offline, and since iOS 16.4 it can send push notifications on iPhone too — but only once the user has added it to the home screen, which most never do.
What you get:
- No app stores, no review, no developer accounts
- One codebase, deployed the way you already deploy
- Updates land the moment you push
What you give up:
- Store presence. You cannot be found by someone browsing the App Store
- Install rates. "Add to Home Screen" converts far worse than an install button
- Some device APIs, depending on platform and version
A PWA is the right answer more often than people admit. If your goal is a better mobile experience rather than a store listing, stop here — the other three routes cost real money and solve a problem you may not have.
2. A WebView wrapper
A wrapper is a small native app whose main screen is a browser view pointed at your site. This is what most "website to app" tools produce, and it is where the interesting problem lives.
Apple's App Store Review Guideline 4.2 covers minimum functionality, and it is explicit that an app which is simply a repackaged website will be rejected. Google Play is more permissive but has its own policy against low-value and duplicated content. So a naive wrapper — your URL and nothing else — is a rejection waiting to happen.
Wrappers that pass review add native capability around the web content. In practice that means some combination of:
- Push notifications, handled natively rather than through the page
- Native navigation — tab bars, a real back gesture, a splash screen
- Offline behaviour and a sensible error state when the network drops
- Biometric unlock, camera and file access, or share sheets
- Restyling the site inside the app so it does not look like a browser window
Done properly this is a legitimate product category, not a loophole. Done lazily it burns two weeks in review and you still have nothing.
3. A cross-platform rebuild
Flutter or React Native, sharing one codebase across iOS and Android, talking to your existing backend through an API. The interface is genuinely native; the business logic you already wrote on the server stays where it is.
This is the honest answer when the mobile experience needs to differ from the web one — different navigation, offline-first data, heavy use of device hardware. It is also the point where you stop packaging and start building a second product, with a second release cycle and a second set of bugs.
4. A full native rebuild
Swift and Kotlin, two codebases, two teams or one team context-switching. You do this when the app is the product and the website is the marketing site — not when the app is a way to be present on a phone.
Choosing between them
| Route | In the stores | Typical effort | Best when |
|---|---|---|---|
| PWA | No | Days | You want a better mobile site, not a listing |
| WebView wrapper | Yes, if it adds native value | Days to weeks | The site already works well on mobile |
| Cross-platform rebuild | Yes | Months | Mobile needs its own experience |
| Native rebuild | Yes | Months, ongoing | The app is the product |
One test cuts through most of the indecision: open your site on a phone and use it for five minutes. If it is slow, if tap targets fight you, if the login flow breaks — a wrapper will ship those problems to the store with a native icon on top. Fix the site first. Wrapping does not repair a bad mobile experience; it removes the browser controls people were using to work around it.
Where app builders fit
Builders automate route two. Instead of writing the wrapper, the configuration, the push integration and the store metadata by hand for every project, you describe the app and the tooling produces the build.
That matters most if you are doing this repeatedly — an agency shipping apps for clients, or a business selling app creation as a service. For a single app it is worth comparing against a developer doing the same work once, because the interesting question is not the first build but the twentieth.
The other thing worth checking before you commit to any builder: what happens to your apps if the builder disappears. A platform that holds your signing keys, your customer list and your build pipeline is a dependency, and dependencies have failure modes. That question is worth a separate look — see self-hosted app builders.
Publishing, briefly
Whichever route you pick, publishing has its own requirements: an Apple Developer Program membership, a Google Play developer account, signing certificates, store listings and screenshots. Building an iOS app has historically also required a Mac — that part is now avoidable, and we covered how in publishing an iOS app without a Mac.