WebToApp turns a phone into an APK workshop, runtimes included

Twelve build targets decide what has to live inside the package

The create screen offers twelve app types, and they are not variations on one idea. They split by what the package must carry at runtime:

Web · HTML · Frontend · WordPress · Node.js · PHP · Python · Go · Image · Video · Gallery · Multi-Web

A web target wraps a URL in a WebView. An HTML or Frontend target serves a static bundle as local files or from localhost. WordPress, Node.js, PHP, Python and Go targets all mean the package includes a server that starts on the device. Image, Video and Gallery targets are media shells. Multi-Web bundles several sites into tab, card, feed or drawer layouts. That single choice propagates into package size, start-up time and the permissions the app will need, so picking the wrong target is the mistake that costs you later. The README's own input-to-output table makes the same split: a URL becomes a WebView-based APK, a static front end becomes a local-file or localhost one, a runtime becomes an APK with an on-device local server.

Node.js, PHP, Python and Go are forked and exec'd from app storage

This is the part a URL wrapper cannot do at all, and it is why the project compares itself to Termux packaged as an installable app. The runtimes are native binaries extracted from app storage and started with fork and exec, at pinned versions:

Node.js 18.20
PHP 8.4 + Composer 2.10
Python 3.14
Go 1.26
WordPress 7.x over SQLite

Composer is bundled with the PHP runtime, which means a PHP target can resolve dependencies on the phone. WordPress runs against SQLite instead of MySQL, so a WordPress package is portable rather than a client for an existing database. The trade-off follows directly from the design: every one of these versions is a maintenance decision the project carries, and a package carrying a language runtime is never a small download.

The system WebView is the default engine, GeckoView is opt-in

Browser engine choice is separate from the build target. By default an app renders through the platform WebView, so the app inherits whatever Chromium revision the phone ships, which means rendering differences across Android versions are inherited rather than controlled. A GeckoView runtime based on Firefox is available as an alternative when you need engine behaviour that does not shift with the OS. The hardening options are listed alongside the engines: a browser fingerprint disguise covering more than fifty vectors, resource encryption with AES-256-GCM, anti-debug, and activation gating.

DoH, JA3 spoofing and ECH are configured per app

The network layer is the widest surface in the project, and it is built around the idea that one app needs different network conditions from another. Seven DNS-over-HTTPS providers are available. TLS fingerprint spoofing offers Chrome, Firefox and Safari JA3 templates, with a local man-in-the-middle bridge that lets traffic be inspected inside the app rather than only blocked or passed. Encrypted Client Hello is available on both engines, which hides the server name in the TLS handshake. Proxies can be set per app as static entries, PAC scripts or SOCKS5, and there is a CORS bypass for single-page apps locked down by their own server policy.

Signing runs through apksig on the phone, not on a build server

Packaging is self-contained end to end. Binary AXML and ARSC patching and permission pruning happen inside the app, then V1, V2 and V3 signing is applied on device through apksig, with keystores managed in the same place. Google Play AAB export is supported, including rewriting the target SDK, which is the step that decides whether a package built here passes current store requirements. Because there is no remote build queue and no PC in the path, a build can start from a phone and finish on a phone, and the output is a file you can share directly. For Play submissions, the AAB path and its target SDK rewrite are the two settings worth reading twice.

Two extension channels, and one of them reaches the Chrome Web Store

The package stays modifiable after it ships. Built-in modules are the first channel, and userscripts using the familiar GM_ interface are the second. The third is the widest: MV3 Chrome extensions, searched live in the Chrome Web Store and installed into the app, which means an app can gain a capability that no rebuild of the host project ever contained. That is the feature with the widest blast radius, since the extension runs inside your app's web surface with the app's own network configuration. Sample bundles and an examples directory in the repository give you starting points rather than a blank page. What an MV3 extension does to your packaged app is decided by that extension, not by the APK you signed.

The agent drives the build through up to sixty tools

There is an agent inside the app that automates the workflow itself, described in the screenshots as describe it and the AI builds it. Its tool surface covers generation, build, export, port and engine and runtime management, cloning existing apps, ad-block rules and configuration templates, with automatic retry on 429 and 5xx responses so a rate-limited model call does not abort a long run. Sixty tools is a wide surface for something that can also trigger builds. Treat it as a power-user path rather than a default: the manual editor screens cover icon, name, splash, background music, translation and the core toggles, and the agent is a faster route through the same states.

No iOS target, no server-side pipeline, and a source tree that expects a PC

Three things this toolkit does not do. It produces Android packages only: every output in the build target list is an APK or an AAB, the project describes itself as an Android toolkit, and none of the twelve build targets is iOS. It has no remote build service, which is the flip side of its main advantage, so there is no shared builder to fall back on when a phone is unavailable or a build takes an hour. And the repository itself is an ordinary Gradle project, with a wrapper and both shell scripts at the root:

app/  modules/  shell/  clone-host/  feature-stacks/  sample-bundles/  docs/  scripts/  examples/
gradlew  gradlew.bat  build.gradle.kts  settings.gradle.kts  gradle.properties

so building from source is a desktop activity even though shipping the finished app is not. The licence is Unlicense, which places no obligation on what you build with it, and releases move fast: v2.8.2 on 2026-10-24, v2.8.3 on 2026-10-28 and v2.8.4 on 2026-11-02, with the last push dated the same day as the newest tag. Rapid tags mean a pinned version ages quickly, and the interface ships in ten languages including a right-to-left Arabic build.

Editorial conclusion

WebToApp fits Android work where you need a signed package without a laptop in the loop: internal tools, offline viewers, a WordPress site that has to travel, or a client demo you can hand over as a file. It does not fit anything that needs an iOS binary, a reproducible server-side build pipeline, or an APK small enough that runtimes do not dominate its size. Before committing, check whether the build target you need is one of the twelve the create screen offers, then read the signing and AAB path for your target SDK, and try one package on the lowest-spec Android device your users actually carry.

Frequently asked questions

Official sources

1. License: Unlicense
2. Project website
3. README
4. Releases
5. shiaho777/web-to-app on GitHub