Turning a website into an app means packaging your site inside a native shell — on Android, an app whose only screen is a WebView showing your pages — so it installs from a file or from Google Play, sits on the home screen with its own icon, launches on a splash screen and opens full-screen with no address bar. The website is not rewritten. With a website to app builder the whole process is: paste the URL, set a name and an icon, build, download a signed APK. It takes a few minutes and, on this site, costs nothing.
This guide is the long version: what actually happens, where the limits are, and the decisions worth making before you press build.
What a website app is, technically
Android ships a component called WebView — the same Chromium engine as Chrome, minus the browser's own interface. A website app is a native Android app whose main activity holds one WebView pointed at your site. Around it the app adds the things a browser tab lacks:
- a launcher icon and a name on the home screen;
- a splash screen while the first page loads;
- a theme colour for the status bar and system chrome;
- a package name that identifies the app to Android and to Google Play;
- a signature, without which Android refuses to install anything;
- optionally, native bottom tabs, push notifications, an offline screen and the permissions your pages need for the camera, microphone or location.
Because the engine is Chromium, the rule of thumb is exact: anything that works in Chrome on Android works in the app. Logins, carts, payments, video, forms, JavaScript frameworks — all of it. The things that do not work are the things Chrome does with its own interface (tabs, bookmarks, the address bar) and a short list of edge cases covered in the troubleshooting guide.
The three routes in
| Website URL | Single HTML file | ZIP of a site | |
|---|---|---|---|
| What the app loads | Your live site, from your server | One page bundled inside the app | A whole static site bundled inside the app |
| Works offline | No (a fallback page can be shown) | Yes | Yes |
| Updating content | Publish on the web — the app updates itself | Rebuild the app | Rebuild the app |
| Right for | WordPress, Shopify, Wix, Webflow, web apps, anything with a server | Calculators, HTML5 games, single-page tools | Exported static sites, documentation, catalogues |
| Size limits | None | 5 MB free, 18 MB Pro | 5 MB free, 18 MB Pro |
Most people want the first one. If the site changes, depends on a database, or has accounts, it belongs on your server and the app should load it from there. Bundling is for content that is finished and should work on a plane.
What you need before you start
- A site over HTTPS that lays out properly at phone width. Test it in Chrome on a phone; if it looks right there it will look right in the app.
- A square image for the icon, 512×512 or larger. No square logo? Monogram Icon MakerAn app icon from your initials and brand colour — no logo needed Open the tool
- A name that fits under an icon — about twelve characters before it truncates.
- A brand colour as a hex value, for the status bar and splash.
- The right to publish the site as an app. Your own site, or a client's with permission.
The
Step by step
1. Choose the input
Sign in to the builder and paste the site's address, or upload an HTML file or a ZIP. For a URL, the builder screens the address and shows the site in a phone-shaped preview so you can see it inside the frame before anything is built.
2. Name, icon, colour
App name, the square icon, the theme colour. The builder generates every launcher size from the one image and picks light or dark status-bar icons from the colour.
3. Package name and version
The package name is a reversed domain — com.bloombakery.app — and it can never change after publishing; the builder suggests one from your URL. The version starts at 1 / 1.0.
4. Permissions and extras
Switch on the camera, microphone or location only if pages use them. Choose a page loader. On Pro, design the splash screen, add onboarding slides, native bottom tabs and push notifications.
5. Build and download
A real Android project is generated and compiled in the cloud. A few minutes later a signed APK is ready — or, on Pro, an AAB for Google Play. Install the APK on a phone by opening the file.
6. Walk every screen
Open each section, log in, submit a form, tap an external link, switch the connection off. Anything that misbehaves is almost always one of the known cases in the fixes guide.
Free or paid?
The free tier builds a complete, signed, installable APK with no watermark and no expiry — enough to install on your own phones, hand to a client, or distribute from a download link. Paid (Pro) exists for Google Play and for the native extras: the AAB format Play requires, your own signing key so you can update a published app, splash screen and onboarding design, native tabs, push notifications, and no cooldown between builds. What free actually covers and what the whole thing costs each have their own guide.
Publishing on Google Play
Play accepts website apps, with two conditions. It requires an App Bundle (AAB) rather than an APK for new apps, and it applies a minimum functionality policy: an app that is nothing more than a bookmark to a website is rejected. Push notifications, native tabs, a splash screen, offline content or a login that persists all count as functionality. There is also a one-time $25 developer registration. The Play policy guide covers the review in detail.
What about iOS?
This builder produces Android apps. An iOS version of the same idea needs Apple's toolchain and a $99-a-year developer account, and Apple's review is stricter about wrapped sites. The iOS guide lays out the realistic options — a PWA, a wrapper you build yourself, or an agency.
Should it be an app at all?
Sometimes the right answer is a Progressive Web App: a manifest and a service worker on the website itself, installable from Chrome with no store and no build. It covers the home-screen icon and offline caching; it does not give you a Play listing, reliable push on every platform, or native tabs. Web to app converter vs PWA is the comparison. Many sites end up with both — a PWA for the web and a store app for discovery.
The honest limits
A WebView app is a website. It cannot run in the background, use Bluetooth, put a widget on the home screen or match a native app's animation frame rate. Heavy games, camera-first apps and anything that has to work with the screen off should be native. For the vast majority of sites — shops, services, publications, portals, tools — the WebView route gets the app on the phone today, for nothing, with the site you already have.