Quick answer: to convert HTML to an app you package your pages inside an Android WebView shell — a native app whose whole screen is a browser engine showing your content. You supply the HTML (or a ZIP, or a URL), a square logo, a package name and a version; a build produces a signed APK that installs on any Android phone. Nothing about your HTML, CSS or JavaScript has to be rewritten.
That is the whole idea. The rest of this guide is the order in which the details arrive, and what each one wants from you.
Before you begin: three inputs, one decision
You need three things and one choice:
- Your web content — a single HTML file, a ZIP of a site, or the address of a site that is already online.
- A square logo — ideally 1024×1024, from which every icon size is generated.
- A package name — the permanent identifier, in reverse-domain form.
The choice is whether the app bundles your content or loads it live. It affects offline behaviour, size and how you ship updates, so it comes first.
Step 1 — Bundled or live?
| Question | Bundle the files | Load the URL |
|---|---|---|
| Works in airplane mode? | Yes — pages come from the device | No |
| How fast is the first screen? | Immediate | After the network answers |
| How do I update the content? | Ship a new build | Edit the website |
| How big is the app? | Shell (~4–5 MB) plus your files | Shell only |
| Typical use | Brochures, tools, courses, HTML5 games | Shops, dashboards, WordPress/Shopify/Wix sites |
Rule of thumb: if the content must survive no signal, bundle it; if it changes weekly, load it. A hybrid — bundle the shell, fetch the data over HTTPS — is common and works well.
Step 2 — Make the files app-safe
Bundled pages are loaded from a folder on the device, not from a web server. Three things break as a result, and all three are invisible until the app is on a phone:
Use relative paths only
css/app.css and ../img/logo.png travel with the files. /css/app.css has no site root to resolve against inside an app, and file:///Users/you/site/app.css points at a computer the phone cannot see.
Bring external assets home
A font from Google Fonts or a library from a CDN is a blank space when the phone is offline. Download them into the project. It is also quicker: no DNS, no handshake.
Avoid type="module" on bundled pages
Browsers refuse ES modules from file:// origins, so a page built that way opens white with no error visible to the user. Bundle to a classic script, or confirm your converter serves bundled files over http://localhost.
Step 3 — Generate the icon set
Android wants launcher icons at five densities (48 to 192 px), a round variant, a 432×432 adaptive foreground and a 512×512 for the store. Generate all of them from one master image rather than resizing by hand, and design the master for how it will look at 48 px: one shape, high contrast, no words.
More on masks, safe zones and the store icon's no-transparency rule in the app icon guide.
Step 4 — Pick the package name (carefully)
The package name — com.yourbrand.yourapp — is how Android tells your app from every other and how Google Play identifies the listing. It cannot be changed after publishing. Lowercase, at least two dot-separated parts, letters first in each part, no hyphens, and never com.example.
Step 5 — Set the version
Two fields. versionName is text for humans ("1.0"); versionCode is an integer Android compares to decide whether an install is an upgrade, and Play insists it rises on every upload. Start at 1 and "1.0".
Step 6 — Build
With the settings entered, a cloud build assembles a real Android project around your content, compiles it with Gradle, signs it and returns an APK. It takes a few minutes and nothing is installed on your computer.
Two facts about the output: every APK is signed (Android refuses unsigned packages), and if you later publish on Google Play, the first key you publish with must sign every future update — so use your own key from the start if Play is the plan.
Step 7 — Install and test on a real phone
Open the APK on an Android device. It will ask to allow installs from that source, which is normal for anything not from the Play Store. Then check what a desktop browser never shows you:
- Back button — walks your page history, or exits on the first press?
- Rotation — does the layout survive landscape?
- Airplane mode — a bundled app should not care; a live app should show a useful message, not a browser error.
- File inputs — uploads need explicit WebView support and do nothing without it.
- Outbound links — links to other sites should open the browser, not trap the user in your app.
How big will the app be?
The WebView shell is around 4–5 MB. HTML, CSS and JavaScript compress to roughly a quarter of their size inside the package, so text-heavy sites add very little. Images and video do not compress and dominate the total.
Checklist
- Bundled or live decided, and the content prepared accordingly.
- Relative paths, local assets, no
type="module"(or localhost serving confirmed). - Icon generated from a 1024×1024 master; 512×512 store icon has no transparency.
- Package name valid and one you will still want in five years.
- Version code 1, version name "1.0" for the first release.
- Tested on a real device, including back button and airplane mode.
Sharing the app directly? The APK is the deliverable. Publishing on Google Play? You will need an App Bundle instead — see APK vs AAB and publishing on Google Play.