The three paths, and what each really gets you
| Method | Effort | App stores? | Native feel | Best for |
|---|---|---|---|---|
| PWA (installable web app) | Lowest | ❌ Not really (limited) | ⚠️ Partial | Reach + speed, no store needed |
| Webview wrapper | Low | ⚠️ Risky (4.2 rejection) | ❌ Website in a shell | A quick store presence, if it passes |
| Native rebuild (reuse API) | Higher — or minutes with AI | ✅ Yes | ✅ Full | A real product that performs and monetizes |
Path 1: Make it a PWA
The cheapest, fastest option. Add a web app manifest and a service worker, and your site becomes installable — a home-screen icon, offline caching, a splash screen. No app store, no review, no $99 fee.
The catch:iOS treats PWAs as second-class — no real push on older versions, no store discoverability, and limits on background behavior. A PWA is excellent for a tool your existing users adopt. It’s weak if discovery is your growth channel, because nobody finds a PWA by browsing the App Store.
Path 2: Wrap it in a webview
A wrapper puts your website inside a native shell (a full-screen WebView) and ships it as an app. It sounds ideal — reuse everything, get a store listing. In practice it’s the path with the most rejections.
App Store guideline 4.2rejects apps that are “simply a repackaged website.” If your wrapper adds no offline support, no push notifications, and no native features, expect a rejection. Google Play is more permissive but ranks wrappers poorly. Wrappers can work — but only once you’ve added enough genuine native capability that you’re halfway to a real app anyway.
Path 3: Rebuild it natively — and reuse your backend
The best outcome, and historically the most expensive. The key insight most people miss: you don’t rewrite the whole thing. Your backend, database, auth, and API endpoints stay exactly as they are. Only the front end changes — from HTML/CSS to native screens that call the same API your website already hits.
That means a native app gets you real performance, full device access (camera, notifications, biometrics), store discoverability, and in-app-purchase monetization — while your web app keeps running unchanged for desktop users.
The reason this used to be path-of-last-resort is cost: rebuilding a UI natively by hand takes weeks. That math is what changed.
The shortcut: describe the app, reuse the API
An AI app builder collapses the native-rebuild timeline. Instead of hand-coding every screen, you describe your product’s core flows — or upload a screenshot of your existing site — and get a working React Native app with navigation and data. You then point it at the API your website already uses, so there’s no second backend to maintain.
ShipNative does this: turn a description (or a screenshot of your website) into a native app previewable on your phone, with your own backend wired in — not a webview of your site, an actual native rebuild you fully own.
Which path should you pick?
- Your users already visit and just want convenience → PWA.
- You need a store listing tomorrow and have native features to add → wrapper, cautiously.
- You want a real product that ranks, performs, and monetizes → native rebuild that reuses your API.
Try the native path free at shipnative.dev — describe your site’s core screens and see a native version running on your phone in minutes.