Understanding what happens under the hood helps you make better configuration decisions and debug unexpected behavior. This article explains the full lifecycle of a WebToAppConvert build.
The Core Architecture
Every app produced by WebToAppConvert is a native Android application with a WebView component as its primary UI. The WebView loads your website URL when the app starts, giving users full access to your website's content and functionality inside a native Android container.
The native layer handles:
- App lifecycle (launch, background, resume)
- System permissions (camera, storage, location)
- Push notification receipt and display (via Firebase Cloud Messaging)
- Ad display (via Google AdMob)
- File picker dialogs for uploads and file saves for downloads
- Deep link handling
- Splash screen and intro screen display
Your website handles everything else: navigation, forms, authentication, content, checkout, and any business logic.
The Build Pipeline
Step 1: Configuration
You configure your app through the dashboard. This includes your website URL, app name, package name, icon, splash screen, permissions, Firebase settings, signing key preferences, and build tier (Debug, Starter, or Professional). This configuration is saved and can be reused for future builds.
Step 2: Build Trigger
When you initiate a build, your configuration is submitted to the build queue. The build server picks up your job and begins processing.
Step 3: Android Project Generation
The build server generates a complete Android project from your configuration. This includes:
AndroidManifest.xmlwith your app name, package name, permissions, and deep link intent filters- Gradle build files configured for your target SDK (currently Android 13/API 33, minimum SDK 21)
- Activity code for the WebView, splash screen, and intro screens
- Firebase integration code if push notifications are enabled
- AdMob integration code if ads are enabled
- Your
google-services.jsonif uploaded - Your icon assets scaled to all Android density buckets (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi)
Step 4: Compilation and Signing
The project is compiled with Gradle. For Starter and Professional builds, the output is signed using your signing configuration:
- Automatic: We generate and manage a signing key for you
- Generate new: A new key is generated and stored in your account: you can download it
- Upload own: Your
.jksfile is used to sign the build
Debug builds are signed with a generic debug key and are not suitable for Play Store submission.
Step 5: Output Delivery
The build output is made available for download from your dashboard:
- Debug:
.apkfile: install directly on your device via USB or ADB - Starter / Professional:
.aabfile: upload this to Google Play Console
Build artifacts are retained for 7 days (free plan), 30 days (paid plan), or indefinitely (subscribed accounts).
What Happens When Your Website Updates
Because the app loads your website URL at runtime, content changes on your website are reflected immediately in the app: no rebuild required. When a customer opens your app after you publish a new blog post, update your menu, or change your prices, they see the updated content. The app itself doesn't need to be resubmitted to Google Play.
You only need to rebuild when you change the app's configuration: package name, icon, permissions, Firebase settings, signing key, or feature set (e.g., adding push notifications to an existing app).
Build Times
Build times vary based on queue depth and build tier:
- Debug builds: typically 2–5 minutes
- Starter builds: typically 3–7 minutes
- Professional builds: typically 5–10 minutes (additional integration code)
You'll receive an email notification when your build completes, and the download link will appear in your dashboard.