Four ways to put a website on a phone, compared honestly
Marketing pages for app builders tend to compare themselves with a made-up "others" column. This page compares the actual approaches, including the ones we don't sell.
The four approaches
Progressive web app (PWA). Your website plus a manifest and service worker. Installed from the browser. Updates when your site updates. What the PWA Builder produces.
WebView wrapper (APK/AAB). A small Android app whose only screen is a web view pointed at your site. Distributed as an APK you share directly or an AAB you upload to Google Play. What the Android app builder produces.
Trusted Web Activity (TWA). A Play-listed Android app that opens your PWA in Chrome's engine full-screen, with domain ownership proven by assetlinks.json. Google's recommended way to list a PWA. The PWA Builder's Android option produces this pairing.
Native or cross-platform rebuild. Kotlin/Swift, or Flutter/React Native. A separate codebase that talks to your backend. Not something this site produces — but the right answer for some products.
Capability matrix
| PWA | WebView APK | TWA | Native / cross-platform | |
|---|---|---|---|---|
| Works on iPhone | Yes (add to home screen) | No — Android only | No — Android only | Yes, with a separate iOS build |
| Google Play listing | No (unless wrapped as TWA) | Yes | Yes | Yes |
| Content updates need a store release | Never | Never for content; yes for icon/splash/settings | Never | Usually yes |
| Offline behaviour | Full control via service worker | Basic (cached pages, offline screen) | Same as the PWA underneath | Full control |
| Push notifications | Android: yes. iOS 16.4+: yes when installed | Yes (FCM/OneSignal) | Yes (web push) | Yes |
| Uses Chrome's engine and cookies | Yes | No — separate WebView, separate cookies | Yes (shares Chrome login state) | n/a |
| Bluetooth, NFC, background location | Android partly; iOS mostly no | Only what the wrapper adds | Same as PWA | Yes |
| In-app purchases | Your own web checkout | Play Billing for digital goods; own checkout for physical | Play Billing via Digital Goods API for digital | Platform billing |
| Store review risk | None | "Minimum functionality" policy applies — add real app behaviour | Lower; Google endorses the pattern | Normal |
| Codebases to maintain | 1 | 1 + wrapper config | 1 + wrapper config | 2 or 3 |
| Typical cost | Free here | APK free; APK + AAB bundle US$5 | Free tooling + $25 Play account | Weeks to months of development |
Where each one is the wrong choice
Don't pick a PWA if…
- your users find apps by searching the Play Store and you have no other channel (add a TWA);
- your product needs Bluetooth or background processing on iPhone;
- you cannot host files at the root of your domain and cannot change your host.
Don't pick a WebView APK if…
- iPhone users matter to you — it does nothing for them;
- your site relies on the user being logged in to Chrome (a WebView has its own cookie jar);
- you plan to submit to Google Play with nothing but the wrapper — Google's minimum functionality policy expects an app to offer more than a browser does. Push notifications, an offline mode and native navigation are the usual additions.
Don't pick a TWA if…
- you can't serve a valid manifest and service worker (it is a PWA underneath — fix that first);
- you need behaviour that differs between the app and the website; a TWA is the website.
Don't rebuild natively if…
- the website already does everything the app needs to do. You would be paying for a second implementation of the same thing.
Our recommendation for most websites
Start with the PWA. It is the smallest change, it covers both platforms, and everything you learn about caching and icons carries over. If Play Store presence turns out to matter, add the TWA — the same files serve it. Reach for the WebView APK when you need an installable file to hand out directly, or when your host will not let you deploy root files. Rebuild natively only for capabilities the web genuinely lacks.