When you make a website into an app, what you get is a WebView app: a native Android shell whose screen is a web rendering engine showing your pages. A native app is written for Android directly, in Kotlin or Java, with screens built from Android's own components. The first costs minutes and a website; the second costs a development project. The question is not which is "better" — native can do more, always — but whether what native adds is something your website needs.
What a WebView app gets you
- Everything your site already does. Your design, your content, your logins, your checkout, unchanged.
- One codebase. Fix a typo on the website and it is fixed in the app. No second team, no parity work.
- The parts of native that matter to users. An icon on the home screen, a splash screen, native tabs, push notifications, camera and location access, full-screen without browser chrome. These are shell features, and the builder provides them.
- A place on Google Play, with the native features switched on.
- Speed to market. Five minutes to an installable APK. A native app is weeks at best.
What you give up
- Deep hardware. Bluetooth, NFC, background location, home-screen widgets, complications. A WebView app cannot do these, full stop.
- Heavy graphics. A 3D game or a video editor is smoother natively. A 2D HTML5 game is usually fine.
- Offline, for URL apps. A URL app needs a connection like a browser does. Bundled HTML apps work offline, native apps can be built to; a URL app cannot.
- Native feel at the edges. Scroll physics, transitions and gestures are the web's, not Android's. Good responsive sites close most of the gap; users of a shop or a blog rarely notice; users of a note-taking app might.
- Automatic Play acceptance. A bare WebView is rejected under Play's minimum-functionality policy. With a splash, tabs and push it passes; without them, it does not.
Where each one wins
| WebView app | Native app | |
|---|---|---|
| A shop, blog, news site, portfolio, booking site | Wins | Overkill |
| A dashboard or SaaS tool people use in a browser today | Wins | Only if offline or hardware matters |
| Documentation, courses, catalogues (bundled, offline) | Wins | Equal, at much higher cost |
| Camera, mic or location as a feature of a web page | Works | Works |
| Bluetooth, NFC, widgets, background tracking | Cannot | Wins |
| 3D games, video editing, AR | Struggles | Wins |
| Time to first install | Minutes | Weeks to months |
| Cost | Free to a small subscription | Thousands upward |
The middle ground people forget
Frameworks like Capacitor and React Native sit between the two: web code with native plugins for hardware. They are the right answer when you want Bluetooth and your existing web code. They are also a development project — Node, the Android SDK, a build pipeline — not a five-minute conversion. If the only reason you are looking at them is that "WebView apps get rejected", the fix is native features in the shell, not a framework.
How to decide, honestly
Ask one question: is the website the product, or is the app the product? If people come for the content, the shop, the service — and the website already delivers it — the app is a better way to reach them, and a WebView app is right. If the app needs to do something the website fundamentally cannot, it needs to be native. Most businesses asking whether to make their website into an app are in the first group, which is why the answer is usually yes.
On the "cheap knock-off" objection
Plenty of well-known apps are WebViews with native shells; users do not check. What users do notice is a white flash on every page, a back button that closes the app, links that trap them, and a browser error page when the train goes into a tunnel. Those are shell problems, and a well-built shell solves them. Judge a website app by whether it behaves, not by what is rendering the pixels.