Convert a PWA Into iOS and Android Apps: What Changes, What Stays
Short answer
A PWA can be published in the App Store and Google Play by packaging it in a native shell: a Trusted Web Activity or WebView wrapper on Android and a WKWebView-based wrapper on iOS. Your UI, routing and backend stay the same, but service workers, web push, install prompts and web payments behave differently inside a store app, so plan to replace them with native push, a native offline strategy and store-compliant payments.
A progressive web app already behaves a lot like an app, which is exactly why teams underestimate what changes when it moves into the App Store and Google Play. The good news: your codebase, design system and backend carry over almost entirely. The work is in the seams, where browser features are replaced by native ones and where store review looks for more than a bookmark.
Why ship a PWA through the stores at all?
If your PWA works well, a store listing is not about technology. It is about distribution and trust. Many users never discover the "Add to Home Screen" option, especially on iOS, where it is tucked into the share menu. A store listing gives you search visibility, ratings, a familiar install flow, and on iOS a far more reliable path to push notifications than web push alone. B2B customers and procurement teams also tend to ask "is it in the App Store?" as a proxy for maturity.
The trade-off is that you now live under two sets of review rules and two release processes. That is manageable, but it is a real operating cost, so decide deliberately.
What stays the same
- Your front end. React, Vue, Svelte, Angular or plain HTML keeps running unchanged inside the native shell.
- Your backend and APIs. Authentication, databases and business logic need no changes, with the exception of login flows discussed below.
- Your deployment cadence for content. Because the shell loads your hosted app, most UI fixes go live without a store update. Keep in mind that store rules expect the reviewed app to remain substantially the same app; do not use remote loading to swap in a different product after approval.
- Your web app manifest. Name, icons and theme colors are still useful as the source for app icons, splash screens and the status bar color.
What changes: a feature-by-feature table
| PWA feature | In a store app | What to do |
|---|---|---|
| Install prompt / Add to Home Screen | Irrelevant; the store handles installation | Hide install banners when running inside the app (detect via user agent or a flag the shell injects) |
| Web push | Inside an iOS WebView, web push is not the right channel; native push uses APNs (iOS) and Firebase Cloud Messaging (Android) | Register for native push in the shell and send device tokens to your backend |
| Service worker offline cache | Service worker support in iOS WKWebView is restricted (App-Bound Domains); on Android it depends on the wrapper type | Do not rely on the service worker alone; add a native offline screen or bundle critical assets |
| Web payments for digital goods | Apple and Google have their own rules for digital goods and subscriptions, and these rules differ by region (check the current guidelines) | Use in-app purchases where required; physical goods and services can usually keep your existing checkout |
| OAuth / social login | Some identity providers, notably Google, block sign-in inside embedded WebViews | Open login in the system browser (ASWebAuthenticationSession, Custom Tabs) or use native SDKs |
| File upload, camera, geolocation | Need native permission prompts and usage descriptions | Add the required permission strings and test each flow on real devices |
| Deep links | Need Universal Links (iOS) and App Links (Android) | Host the association files on your domain and map routes |
Three ways to package a PWA
- Trusted Web Activity (Android only). A TWA renders your PWA in Chrome, full-screen, verified by Digital Asset Links. Tools such as Bubblewrap or PWABuilder generate the project. It preserves your service worker and is a clean option for Android, but it gives you little native surface to work with and does not exist on iOS.
- WebView wrapper (iOS and Android). A native app hosts your PWA in WKWebView or Android WebView and adds native features around it: push, offline fallback, native navigation elements, splash screen, biometric login and so on. Template products such as WebViewGold provide this shell ready-made, so you configure rather than code it.
- Capacitor or a similar hybrid runtime. You bundle the web build into the app and access native APIs through plugins. This gives you the most control, but you now maintain a native build pipeline and ship updates through the stores. The trade-offs are covered in our comparison of Capacitor vs. WebView wrapper vs. rebuild.
A common setup is a TWA or wrapper on Android plus a wrapper on iOS. If you want one configuration for both platforms, a single wrapper product is simpler to maintain.
Passing review: the native value test
Apple's Guideline 4.2 (Minimum Functionality) is where most PWA submissions get stuck. Review rejects apps that feel like a repackaged website. A PWA has an advantage here because it is usually already app-like, but you still need to show value that a browser bookmark does not provide. Practical signals that help:
- Native push notifications that users can opt into and that deliver something useful.
- A graceful offline state instead of a browser error page.
- A native tab bar or navigation, and no visible browser chrome, URL fragments or "open in browser" dead ends.
- Device features that fit the use case: camera upload, biometric unlock, sharing, haptics.
- Account features, including in-app account deletion if users can create accounts (Guideline 5.1.1).
Google Play is generally less strict about WebView apps, but its spam policy targets apps that only display a website the developer does not own, so publish only properties you control. For a broader view of where wrapping is the right choice, read WebView app vs. native app.
A two-week conversion plan
- Days 1–2: Audit the PWA on a real iPhone and Android phone. List every place that assumes a browser: install banners, external links, login redirects, downloads.
- Days 3–5: Set up the shell, icons, splash screen, deep links and native push. Hide web-only UI when running inside the app.
- Days 6–7: Fix login in the system browser, test file uploads and permissions, add an offline screen.
- Days 8–9: Prepare store assets: screenshots, privacy policy, privacy labels and the Play data safety form.
- Days 10–14: Internal testing via TestFlight and the Play internal track, then submission. New personal Play accounts must first complete a closed test, explained in our guide to the 12-tester rule.
If you'd rather not handle the store side yourself, appsubmitter.io handles signing and submission in your own developer accounts.
When a PWA should stay a PWA
Not every PWA belongs in a store. If your users are mainly on desktop, if you rely heavily on web payments for digital content, or if you cannot commit to maintaining two store listings, a well-built PWA with a clear install hint may be the better choice. Ship to the stores when distribution, push reliability or customer expectations justify the extra process, not because it feels like the next step.
Frequently asked questions
Can I put a PWA directly into the Apple App Store?
Not as-is. Apple has no PWA packaging format like Android's Trusted Web Activity, so you need a native iOS shell, typically a WKWebView-based wrapper, that adds enough native functionality to pass review.
Do web push notifications work inside a wrapped PWA?
Do not rely on them. Inside a native app you should use the platform push services, APNs on iOS and Firebase Cloud Messaging on Android, which the native shell registers for.
Will my service worker keep working in the app?
In an Android Trusted Web Activity it does, because Chrome renders the app. In iOS WKWebView service worker support is restricted, so add a native offline fallback rather than depending on the service worker.
Do I need to resubmit the app every time I update the PWA?
Usually not, since the shell loads your hosted app. You only need a store update when you change native parts such as icons, permissions, push setup or the shell itself.
Want a second opinion on your project?
Book a free 30-minute call with our team. We look at your idea, prototype or app and tell you honestly which route makes sense – whether you work with us or not.
Book a free call or write to [email protected]