tools / configure

Framework build configurator

A framework build is a folder of HTML, CSS and JavaScript, so it converts like any site — once the build stops assuming it lives at the root of a web server. Pick the framework; get the three changes that matter, as copy-paste config.

Generate your build settings

In the app your files are served from https://appassets.androidplatform.net/web/ — a real https origin, one folder down from the root. Everything below follows from that.

Does the app have client-side routes?

The one fact every setting follows from

When a ZIP becomes an APK, your files are placed inside the app and served to its WebView from https://appassets.androidplatform.net/web/. That address has two properties that matter to a framework:

  • It is a real https origin. ES modules, fetch() of your own JSON files, localStorage and IndexedDB behave exactly as they do on a website. Modern build output — <script type="module"> and all — runs unchanged.
  • Your site is one folder down, at /web/. A URL that starts with / (the default for almost every framework) points at the root of that origin, outside your files, and returns a 404.

So the changes are about where, not what: make asset URLs relative (./) — or, for tools that cannot do relative, prefix them with /web/ — and use hash-based routes.

Why hash routing

A history-mode router shows /about in the address bar and relies on the server to answer any path with index.html. In the app there is no server doing that: the page starts at /web/index.html, the router sees a path it has no route for, and renders its not-found view — or nothing. Hash routing keeps the route after the # (index.html#/about), which never leaves the page, so it works from the first launch and after every reload. The SPA routing doc covers the alternatives, including memory routers and a basename.

What to zip

The output folder, and only its contents — never the project. The index.html in your project root is a development template that loads uncompiled source; the one in dist/ (or build/, out/, browser/) is the real app. If you already zipped the whole project, the root flattener can pull the build folder out.

Frameworks with a server side

Next.js, Nuxt, SvelteKit and Remix can all render on a server. An APK has no server, so only their static or single-page modes apply: API routes, middleware, server actions and incremental regeneration are simply absent. Calls to a real backend over https:// keep working — point them at your deployed API.

Frequently asked questions

Do I still need to avoid type="module" scripts?

No. The app serves your files from a real https origin, so module scripts load exactly as on a website. The old advice to convert to classic scripts applied to apps that loaded pages from file://.

Why does Next.js use '/web' instead of './'?

Next.js does not support relative asset prefixes, so its URLs always start with a slash. Setting basePath to '/web' makes that slash point at the folder the app actually serves from.

Can I keep BrowserRouter if I never reload?

It can work if you also set a basename and handle /web/index.html as the home route, but the first-launch path is easy to get wrong. Hash routing has no such edge cases; it is the recommendation.

My build works in the browser preview but is blank in the app — what now?

Open index.html from the build folder and look for src or href values starting with /. If there are any, the base path setting did not take effect. Then follow the debugging doc to reproduce the app's conditions on desktop and read the console on the phone.

Read in the docs

Related tools

Unzip it on a phone today

Upload the ZIP, name the app, pick an icon — and download a signed APK a few minutes later. Free builds, no watermark, no Android Studio.

Convert a ZIP — free site.zip → app-release.apk