Every feature, and the reason it exists

1. A complete web app manifest

The manifest is the file that turns a tab into an app. The builder fills every field the install prompt depends on:

• name and short_name — the full name shows on the install banner and splash screen; the short name sits under the icon, where launchers truncate anything longer than about twelve characters.
• start_url — the page the app opens on, kept inside the manifest's scope so navigation stays in-app and out of the browser.
• display: standalone — hides the address bar and browser buttons; back navigation still works with the system gesture.
• theme_color and background_color — the status bar tint and the colour of the generated splash screen while your first page loads.
• icons — eight sizes from 72 to 512 px, with the 192 and 512 entries marked purpose: "any maskable" so Android can crop them into circles and squircles without clipping your logo.
• description and id — used by richer install dialogs and by Google Play when the app is listed as a Trusted Web Activity.

Read the manifest guide for what each field does and how to adjust it later.

2. A service worker with a caching policy you choose

A service worker is a script the browser runs in the background between your pages and the network. It is what lets a web app open instantly and survive a tunnel. The builder generates one of three variants:

• Network first — always tries the live site, falls back to cache if the request fails. Right for news, dashboards and shops where stale content is worse than a short wait.
• Balanced — serves static assets (CSS, JS, images, fonts) from cache and revalidates in the background; goes to the network for HTML. The default for a reason.
• Aggressive — cache first for everything with periodic refresh. Right for documentation, menus, brochures and games.

Every variant precaches your start page and the offline page, cleans up old caches on activation, and skips non-GET requests so forms and checkouts are never served from cache. The caching strategies guide explains the trade-offs with examples.

3. An offline page that looks like yours

When a page is not cached and the network is unavailable, browsers show a generic error. The generated offline.html carries your app name, colours and icon, and a retry button that reloads when connectivity returns. Small detail, large difference to how "app-like" the result feels.

4. Icons that survive every launcher

Upload one 512×512 PNG; the builder renders the full set. The maskable versions add a safe margin so the important part of your logo stays inside the circle that Android cuts. If your logo is a wide wordmark, the icon resizer lets you preview it in each mask before you commit.

5. Optional Android packaging for Google Play

Tick the Android option and the same build produces a signed Android test APK that opens your website full-screen using the device's Chrome engine, plus the assetlinks.json file you host to prove you own the domain. That pairing is what Google calls a Trusted Web Activity: the app is your live site and there is no separate codebase to maintain. For the AAB Google Play requires, run Bubblewrap or PWABuilder against the same manifest (free, local tooling), or — if a WebView-based listing is acceptable — use the Android app builder's APK + AAB bundle (US$5). The TWA checklist takes you through the listing.

6. Push notifications through OneSignal

Paste a OneSignal App ID and the generated service worker includes the push handler, so you can send web push to installed users on Android and — for apps added to the home screen — on iOS 16.4 and later. We chose OneSignal because its free tier is usable and its dashboard is approachable for non-developers; the web push guide covers setup and the platform limits.

7. Analytics and chat, if you want them

Optional fields for a Google Analytics property ID and a Tawk.to chat widget add the corresponding snippets to the setup guide. Leave them blank and nothing is added — the builder does not inject any tracking of its own.