WebToApp

Build Android APKs from web projects, directly on your phone.

An on-device APK workshop that goes far beyond URL wrapping — it can fork and exec full server runtimes, ship a hardened anti-censorship network stack, sign bundles for Google Play, and run MV3 browser extensions, all without a PC or a remote build server.

English · 简体中文

Sponsored by Swiftproxy — Swiftproxy · Reliable Residential Proxies for Web Automation

What's different · What you can build · Capability overview · Feature map · Module market · Documentation · Architecture · Build

What makes WebToApp different

Most "website to app" tools stop at wrapping a URL in a WebView. WebToApp is closer to a pocket-sized APK workshop, and the hard parts are exactly where it diverges:

• It runs real server runtimes on-device. Node.js, PHP, Python, Go, and WordPress are fork+exec'd as native binaries straight from app storage — like Termux, packaged into an installable APK. URL-wrapper tools cannot do this at all.
• It ships a hardened, anti-censorship network stack. DNS-over-HTTPS, TLS fingerprint spoofing (Chrome / Firefox / Safari JA3 templates) with a local MITM bridge, Encrypted Client Hello (ECH) on both engines to encrypt the SNI, per-app proxies, and CORS bypass for locked-down SPAs.
• The whole build is self-contained. Binary AXML/ARSC patching, permission pruning, V1/V2/V3 signing, and Google Play-ready AAB export all happen inside the app via apksig — no remote build queue, no PC.
• It stays extensible after shipping. Add JS/CSS modules, Tampermonkey-style userscripts, or MV3 Chrome extensions (live-searched and installed from the Chrome Web Store) without rebuilding the host.
• The host UI speaks 10 languages out of the box. Chinese, English, Arabic (RTL), Portuguese, Spanish, French, German, Russian, Japanese, and Korean — switch anytime in Settings; new in-app copy is maintained for all ten.

Capability overview

A quick scan of what's in the box. Each links to the detailed feature map below.

What you can build

Full feature map

WebToApp has a large number of switches. The sections below group them by use case, kept collapsible so the top of the page stays scannable.

Agent

WebToApp ships a built-in AI agent (open from ⋮ → Agent) that can operate the entire app through natural-language conversation. Instead of tapping through menus, you describe what you want and the Agent executes it via a tool-calling loop backed by any LLM you configure in AI Settings — Chat Completions, Anthropic Messages, or OpenAI Responses endpoints, plus Google Gemini and Ollama / LM Studio / VLLM locals.

How it works:

1. You send a message (or attach an image for visual context).
2. The LLM reasons and emits tool_calls.
3. The Agent executes each tool on-device — read-only tools run immediately; write tools pop a permission dialog first.
4. Results flow back to the LLM, which continues until the task is done or it asks you a clarifying question.

Up to 57 built-in tools, grouped by domain (the 3 imagery tools load only with an image-capable model):

Module market

WebToApp has a GitHub-backed module market for community JS/CSS extension modules. The catalog is just files in this repository, so contributions use a normal pull-request flow.

modules/
├── registry.json        # app-facing catalog
├── submissions.json     # CI-generated PR / contributor metadata
├── README.md            # contributor guide
└── <module-folder>/     # each module

The app fetches both registry.json and submissions.json and only shows modules present in both, keeping the in-app catalog aligned with actually-merged PRs. The submissions file also records every contributor per module, so the catalog shows stacked avatars and a contributors leaderboard. Catalog files and module icons route through a global mirror first, with raw.githubusercontent.com and jsDelivr as automatic fallbacks, so the store loads fast everywhere (including mainland China).

• Users open Extension Modules and tap the storefront icon.
• Contributors add a folder under modules/, update registry.json, and open a PR.
• The default client cache is one hour, so merged modules propagate without an app update.

The high-level architecture lives here; the canonical submission rules, field schemas, reviewer checklist, and CI validation details live in modules/README.md.

The community market carries only JS/CSS extension modules. Browser extensions (MV3) are no longer a community catalog — instead the Browser Extensions tab searches the Chrome Web Store live: type a keyword, browse results, and install on demand through the existing CRX pipeline. Live search requires a network that can reach Google.

Documentation

The official documentation site is published at shiaho777.github.io/web-to-app, in English and 简体中文:

Architecture

• The repository has three Gradle modules: app (the full builder and host), shell (the runtime host embedded into generated APKs), and clone-host (host code for app cloning — compiled to a classes.jar, converted to DEX via d8, and bundled as an asset for AppCloner).
• Runtime code is authored in app and synchronized into shell, so shared WebView/runtime behavior has one source of truth (core/shell, core/webview, core/engine, core/extension, ui/shell, etc.).
• The APK builder patches template APKs at the binary AXML/ARSC level, injects config/resources, prunes permissions, and signs with apksig. A separate encrypted build path (EncryptedApkBuilder) offers resource encryption, shelling, and integrity checks.
• Generated APKs pin targetSdk = 28 deliberately (via the shell template) — it is what lets them fork+exec native runtimes (Node.js, PHP, Python, Go, WordPress) from app storage, a capability URL-wrapper tools lack. The host app itself targets 36 (antivirus engines flag low-targetSdk builds as legacy malware); SELinux W^X at that level blocks host-side preview of the exec-based runtimes, which degrade with an explicit message — Node.js preview (JNI) and every exported app are unaffected. This does not limit Play distribution. For Play the AAB exporter separately rewrites targetSdk to the Play-required level (currently 36), so every app type publishes normally except the five server-runtime ones and any build with resource encryption enabled — only the server-runtime types are tied to APK distribution, because the required target level would break their fork+exec runtimes. WebView-only app types (Web/HTML/Frontend/Gallery/Media/MultiWeb) can also opt to raise the standalone APK's targetSdk (34/35/36) from the APK export section.
• Server runtimes and the optional GeckoView native libraries (.so + omni.ja) are downloaded on first use rather than bundled into the base APK; the GeckoView API classes come from a gradle dependency, while the heavy native artifacts are fetched on demand.
• The configuration center is WebApp (data/model/WebApp.kt) and its *Config classes — the single source of truth for all feature settings, carried through a full packaging passthrough chain into the generated APK.

Tech stack

• Kotlin, Jetpack Compose, Material 3
• Koin for dependency injection
• Room 2.7.2 + KSP for persistence
• OkHttp 4.12.0 + okhttp-dnsoverhttps
• com.android.tools.build:apksig 8.3.0 for APK signing
• BouncyCastle 1.78.1 for crypto and signing
• protobuf-javalite 3.25.5 for AAB metadata
• Firebase Cloud Messaging (BYO Firebase config) for push notifications
• GeckoView as an optional browser engine (native libs downloaded on first use)
• Coil for image/video/GIF loading
• Haze for blur/glassmorphism UI
• Gson for JSON serialization (shell config pipeline)
• AndroidX Security Crypto + DataStore for stored secrets
• Vico Compose-M3 for charts
• ZXing for QR sharing
• Apache Commons Compress + xz for project import and website scraping
• Native C++ via JNI for node_launcher and go_exec_loader
• Robolectric for unit tests

See app/build.gradle.kts for the complete dependency list.

Build from source

Requirements: Android Studio Hedgehog or newer, JDK 17. The Gradle wrapper pins Gradle 9.4.1.

git clone https://github.com/shiaho777/web-to-app.git
cd web-to-app
./gradlew assembleDebug

For release builds, configure signing through local.properties and app/build.gradle.kts.

Contributing

Contact

Developed by shiaho.

License

The Unlicense.

Advanced features such as device disguise are intended for technical demonstration and must only be used with informed user consent.

Acknowledgements

daoxe.com — AI API relay for personal use.

Sponsored by Swiftproxy — Swiftproxy provides 90M+ clean residential IPs across 220+ locations, supporting HTTP(S) and SOCKS5 proxies, flexible targeting, rotating and sticky sessions, and non-expiring traffic. It helps WebToApp users with reliable global access, location-based testing, web automation, and data collection. Free testing is available, with 10% off using code PROXY90.