Frequently asked

It's the single biggest risk for wrapper apps, but it's not automatic. The pre-flight check scores 0–100 before you ever burn a build credit; the more "real functionality" on the site (auth, checkout, membership, booking) the higher the score. If you do get rejected, the submission kit ships a tested 4.2 response template (ko + en) so you can reply to the reviewer instead of guessing.

We fetch the site once and inspect 9 signals: viewport meta, web app manifest, service worker (PWA), login form, signup flow, cart / commerce keywords, push permission prompt, mobile-responsive markup, and native permission usage. The more signals you hit, the more the score reads as "this is a real app experience, not just a website." Pre-flight runs never consume build credits — rerun freely after every site change.

Make the reviewer feel they couldn't just do this in Safari. Highest-impact additions (rough order): account login, ordering / booking / membership flow, push opt-in, PWA (manifest + service worker), and native permissions (camera, location, contacts). A restaurant only needs an "order history" and a "regulars coupon"; a hagwon only needs a logged-in "my class schedule" screen. Two screens that require auth move the score meaningfully.

Both Android and iOS dispatch to Codemagic cloud workers and typically finish in 4–8 minutes including queue time. Dashboard polls every 3 seconds for status. Trade-off vs. a self-hosted Gradle runner: you don't operate macOS or Android SDK infra, but Codemagic owns the toolchain.

No. Compile errors, code-signing failures, expired Apple certs — none of those count. Credits only decrement when an APK or IPA artifact comes out clean.

Yes. A PWA bumps your pre-flight score and gets a cleaner offline fallback, but a regular responsive site still builds fine. Just be aware Apple-4.2 risk runs higher without one.

Two keys, registered once. (1) Android — create a Firebase project, download the "service account" JSON, upload it. (2) iOS — generate an APNs Auth Key (.p8) in your Apple Developer account, note the Key ID + Team ID, upload it. The dashboard walks through both with screenshots; most people finish in under 30 minutes. After that, push goes out from the dashboard.

When a user opens the app and accepts the push permission, their device token is auto-registered with elabhub. From the dashboard you target Android, iOS, or all — and you get per-device delivery results back. One user on multiple devices counts as multiple recipients.

AES-256-GCM (96-bit IV, 128-bit auth tag) encrypts them on the elabhub side before they hit the database. They're only briefly decrypted inside a per-build worktree or per-request scope, then destroyed. Plaintext keys never persist to disk — even our operators can't read them.

No. Site changes are live in the app instantly — the WebView re-fetches every session. You only rebuild when the native shell itself changes (icon, splash, push config, permissions, version code).

No. Apple Developer Program ($99/year) and Google Play Developer ($25 one-time) come from you. WEBVIEW:LAB covers the shell build, push, pre-flight, and submission guidance.

Sites where regulars come back, and where push can pull them back in. Cafe / restaurant loyalty, hagwon class alerts, neighborhood pharmacy refill notices, clinic visit reminders, online-store sale drops, content magazine new-post alerts. A one-shot informational page (a static notice) doesn't really need to be an app.

The APKs / IPAs you already downloaded keep working — the site still runs, the app keeps showing it. You just can't queue new builds, send pushes, or run pre-flights until billing resumes. Apps already in the store stay listed regardless of billing.

Pro is 20 builds/month + unlimited push + 5 app slots. Studio is 50 builds/month + unlimited app slots + a priority build queue. Pick Studio if you're running multiple brands from one account (agencies). Build caps pass through Codemagic's per-minute pricing predictably — normal cadence (1–3 updates/app/month) won't hit them.