shiaho777/web-to-app: an on-device APK workshop for Android
The most full featured web-to-app toolkit on Android, a complete APK workshop that runs entirely on your phone
At a glance
- What is it?
- WebToApp builds signed Android APKs and Google Play AABs from web projects without a PC, and it goes further than URL wrapping by running Node.js, PHP, Python, Go and WordPress as native binaries on the phone. Here is how the mechanism works, how to build your first app, and where the design runs out.
- Who is it for?
- Adopt WebToApp if you need an Android APK or AAB from a web project and have no PC, or if you want a Node.js, PHP or Python server running on a phone. Do not adopt it if you need an iOS build or a managed cloud service: the README describes an Android-only, on-device toolchain.
- Can I use it commercially?
- Yes. Unlicense is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What WebToApp is for, and who ends up using it
The README frames the project against the usual category of website-to-app tools, which it says "stop at wrapping a URL in a WebView." WebToApp instead describes itself as an on-device APK workshop that can fork and exec full server runtimes, ship an anti-censorship network stack, sign bundles for Google Play, and run MV3 browser extensions, all without a PC or a remote build server. The practical audience is narrow and specific: someone with a web project and an Android phone, no desktop build machine, and a need for an installable artifact rather than a hosted wrapper. The Create panel offers 12 app types, and the repository ships examples such as examples/remote-activation-worker, which suggests the intended user is comfortable reading a project tree, not just filling in a URL field. If all you want is a home-screen shortcut to a site, the project is heavier than the job requires.
The mechanism: fork+exec runtimes and an in-app build pipeline
Two mechanisms carry the project. First, server runtimes. The README states that Node.js, PHP, Python, Go and WordPress are fork+exec'd as native binaries straight from app storage, and compares the result to Termux packaged into an installable APK. That is the clearest architectural claim in the document: the runtimes are not emulated in JavaScript, they are native processes launched from storage. Second, the build itself. The README says binary AXML/ARSC patching, permission pruning, V1/V2/V3 signing and Google Play-ready AAB export all happen inside the app. In other words, the app edits the compiled Android resource and manifest binaries directly rather than recompiling a Gradle project. The network layer is a third strand: DNS-over-HTTPS, TLS fingerprint spoofing with Chrome, Firefox and Safari JA3 templates behind a local MITM bridge, Encrypted Client Hello on both engines to encrypt the SNI, per-app proxies, and CORS bypass for locked-down SPAs. The repository layout reflects this split, with app/, clone-host/, modules/, shell/ and scripts/ at the top level. The MITM bridge is the part I would flag: a local interception proxy is powerful and also the piece most likely to break when a target site pins certificates.
Installing WebToApp and building a first APK
The README points at the releases page for the build, and the badge states Android 6.0+. There is no desktop installer and no remote build server, so the phone is the whole toolchain. The README's own quick-start anchor is #quick-start; the steps below follow the flow the screenshots and the README describe, from the Create panel through the Build dialog to a signed result.
# On the phone: download the latest release APK
# from https://github.com/shiaho777/web-to-app/releases
# and install it (Android 6.0 or newer)The first screen is My Apps, which the README describes as "your projects at a glance." Open Create and pick one of the 12 app types. For a website, choose the Web app type, then enter a name and a URL; the editor offers an "analyze site" action. For local files, the HTML app type accepts files, a ZIP, or code written directly in the editor. The screenshots then show the Editor with an icon, name and core toggles, a second group with splash, BGM and translate options, and an advanced and export settings card. Preview runs what the README calls "the real export runtime," which is worth using before you build, because it exercises the same path the output app will take.
# Build flow, as shown in the screenshots:
# My Apps -> Create -> Web app (name + URL)
# Editor -> icon, name, toggles, advanced/export settings
# Preview -> runs the real export runtime
# Build -> choose engine and protection options
# Result -> signed APK, with size analysisThe Build dialog asks for engine and protection options, and the result screen reports a signed APK with a size analysis. The README also lists Google Play-ready AAB export and V1/V2/V3 signing as in-app steps. What you should see at the end is a signed artifact you can install on the device or export; the README does not document a rollback path if a build fails partway.
Where the on-device model runs out
Android-only is the first hard boundary. The README's badge says Android 6.0+, the language is Kotlin, and the runtime packaging is Android-specific. Several related searches ask about iPhone and iOS builds; nothing in the README describes an iOS output, so that question has no answer here. The second boundary is the device itself. Fork+exec'ing Node.js, PHP, Python, Go and WordPress from app storage, plus a local MITM bridge, plus an AXML/ARSC patcher and a signer, means the phone is doing work a desktop build server normally does. The README does not publish memory, storage or thermal requirements, and it does not document what happens when a runtime is killed in the background mid-build. The third boundary is the anti-censorship stack. TLS fingerprint spoofing through a local interception bridge is a deliberate trade: it buys reach into sites that block unusual clients, and it costs you a component that must keep pace with TLS changes and certificate pinning. If your target sites pin certificates, expect that path to fail, and the README does not describe a fallback. Finally, if you want a managed pipeline with hosted builds and store submission handled for you, this is the wrong shape of tool: everything here happens on one phone.
How this differs from AppsGeyser and other converters
The related searches include "Web to app AppsGeyser," and the comparison is the clearest way to see the design choice. A hosted converter of that kind takes a URL, wraps it in a WebView, and hands back an APK built on someone else's server. The artifact is thin, the process needs a browser and an account, and the phone never runs a compiler. WebToApp inverts that: the build happens locally, and the output can contain native server runtimes rather than only a WebView shell. That is why the feature list includes AXML/ARSC patching, permission pruning, V1/V2/V3 signing and AAB export, and why the repository has a modules/ directory and a module market. The trade is straightforward. You get no remote build farm, no account, and no dependency on a service staying up; you take on the device's limits and the need to keep the app updated yourself. For a plain URL wrapper, the hosted converter is less work. For an app that must run PHP or Node.js code on the device, the hosted converter cannot do it at all.
Maintenance, releases and the Unlicense
The last push to the repository was on 2026-09-21, and releases v2.6.6, v2.6.5 and v2.6.4 landed on 2026-09-18, 2026-09-18 and 2026-09-14. The repository is not archived. That release cadence is visible in the repository, and it also sets the upgrade cost: because the runtimes, the signing logic and the network stack all live inside the app, a new release can change the behavior of builds you already shipped. The README does not document a migration or rollback procedure between versions. Building from source is a separate path, since the repository ships build.gradle.kts, gradlew, gradle/ and settings.gradle.kts, and the README has a "Build from source" section, but the commands are not spelled out there, so treat that as the place to look rather than a documented recipe. On licensing: the repository carries the Unlicense, which is a public-domain dedication rather than a copyleft licence. That removes most redistribution constraints on the project's own code, but it says nothing about the licences of the bundled Node.js, PHP, Python, Go or WordPress runtimes, and the README does not address them. Check those separately before shipping a commercial app; this is a factual gap in the documentation, not legal advice.
Editorial conclusion
Adopt WebToApp if you need an Android APK or AAB from a web project and have no PC, or if you want a Node.js, PHP or Python server running on a phone. Do not adopt it if you need an iOS build or a managed cloud service: the README describes an Android-only, on-device toolchain. Before you rely on it, verify the exact Android version and device you will build on, and check whether the build output passes your own signing and store requirements.
Frequently asked questions
How can I convert a PWA to an APK file with WebToApp?
The README describes the Web app type in the Create panel, where you enter a name and a URL, and a Build dialog that produces a signed APK on the device. The Preview screen runs what the README calls the real export runtime, so you can check the result before building.
How do I use WebToApp to turn a website into an app?
Open Create, pick the Web app type, and enter the site name and URL, then use the editor's analyze site action. From there the Editor holds icon, name and toggles, and Build produces the signed APK.
What is WebToApp?
It is an Android app that builds APKs from web projects on the phone itself. The README describes it as an on-device APK workshop that can fork and exec server runtimes and sign bundles for Google Play.
How do I add a web app in WebToApp?
The Create panel offers 12 app types, and the Web app type takes a name and a URL. The README also describes an HTML app type that accepts files, a ZIP, or code written in the editor.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/shiaho777-web-to-app)
Community notes