URL to APK: Paste a Link, Get a Signed Android App (2026 Guide)

You have a URL. You want an APK file you can install on an Android phone. The direct answer: paste the URL into a wrapper build service, set a name and icon, and download a signed APK a few minutes later. With Code2Native the first build is free — one credit, watermark on the splash screen, no card required.

That is the whole happy path. The rest of this guide covers the five things the one-line answer skips — the things that determine whether your APK installs cleanly, updates without bricking, and survives Google Play review. They are cheap to get right on build one and expensive to fix on build ten.

The 60-second version

• 1. Have a deployed site. The URL must be live and served over HTTPS — a production domain, a Vercel/Netlify deployment, a hosted no-code app. Localhost and password-walled staging URLs won't work.
• 2. Configure the app. Name, package name (more on why this is permanent below), and an icon — minimum 512×512 PNG, which is also exactly what Google Play's listing requires.
• 3. Build. The cloud pipeline compiles a native Android shell around your URL and signs it. Typical turnaround is minutes; the mechanics are in the docs if you want them.
• 4. Install or publish. Download the APK for direct installs, or the AAB if you're going to Google Play. Which brings us to the first decision that actually matters.

This works for any live URL, not just marketing sites: a Glide app's published URL, a Ghost publication, a Notion site, a web dashboard behind a login screen — if a phone browser can load it, the shell can render it.

APK or AAB? Decide before you build

People search “URL to APK” but about half of them actually need an AAB, so let's sort this out first.

An APK is the installable file. You can email it, host it on your own site, hand it to your team on a USB stick, or drop it onto a device with adb install app-release.apk. If your goal is “get this on phones I control” — internal tools, kiosk devices, a client demo, distribution outside any store — the APK is what you want.

An AAB(Android App Bundle) is the publishing format. Since August 2021, Google Play has required new apps to be submitted as AABs — it will not accept a plain APK for a new listing. Play takes your bundle and generates optimized APKs per device itself. If Google Play is the destination, the AAB is non-negotiable, and as of mid-2026 Play also expects new submissions to target recent Android API levels (the deadline for targeting Android 16 / API 36 lands August 31, 2026), which is the build pipeline's problem to keep up with, not yours.

The practical takeaway: get both from the same build (Code2Native outputs both), sideload the APK today to test on a real device, and keep the AAB for the Play submission.

Signing: the one decision you cannot redo

Every Android app is cryptographically signed, and Android identifies an app by its package name plus that signature. This has a consequence that surprises almost everyone the first time: every future update must be signed with the same key as the version already installed. Sign version 2 with a different keystore and the device refuses it:

The user's only way out of that error is uninstalling — losing local data — and reinstalling. On Google Play it's stricter still: an upload signed with the wrong key is rejected outright, and if you lose the key entirely and are not enrolled in Play App Signing, the app is permanently orphaned. Your only move is republishing under a new package name, with zero installs, zero reviews, and no way to migrate existing users automatically.

Three rules follow from this. First, keep the same keystore for the life of the app — a “URL to APK” service that generates a throwaway key per build has quietly made your app un-updatable. Code2Native persists your signing identity across builds precisely so update N+1 installs over update N. Second, back the keystore up somewhere that isn't the laptop it was created on. Third, when you publish to Play, enroll in Play App Signing (required for new apps anyway): Google holds the app signing key and you sign uploads with an upload key — and a lost upload key can be reset with a support request instead of ending the app.

One more permanent choice hides in the config screen: the package name (com.yourbrand.app). It is the app's identity on the device and on Play, and it can never be changed after publishing — renaming means a brand-new app. Thirty seconds of thought here beats a migration later; use a domain you actually control, reversed.

Sideloading in 2026: what your users will actually see

If you skip the Play Store and hand people the APK directly, be honest with yourself about the install experience, because it is not one tap.

On any modern Android version, the user downloads the file, opens it, and is told their browser “is not allowed to install unknown apps.” They tap through to settings and enable Install unknown appsfor that one app (Chrome, or their file manager) — Android 8 replaced the old global “Unknown sources” toggle with this per-app permission. Then Google Play Protectscans the file and, for an app it has never seen from a developer it doesn't know, often shows a warning with the install option tucked behind “More details.” None of this blocks a motivated user, but if your audience is non-technical, write an install page with screenshots or expect a support thread.

What a WebView shell can and cannot do

Be clear about what you are getting, because vendors in this space love to blur it. A URL-to-APK build is a native Android shell rendering your live website— a real APK with a real icon, a splash screen, and device hooks. It is not a native rewrite, and anyone who tells you a paste-a-link tool produces “fully native code” is selling something.

What the shell genuinely adds over a browser tab: home-screen presence, fullscreen rendering without browser chrome, push notifications(Code2Native wires OneSignal into the shell — the single biggest re-engagement feature a mobile site cannot have on its own), and an app users can find by icon instead of by memory. What it inherits from your site: everything else. Performance is your site's performance. Offline is whatever your site does offline — for most sites, an error page, so a shell with a friendly offline screen is worth checking for.

And one gotcha that catches real apps, not hypothetical ones: Google blocks its own OAuth sign-in inside embedded WebViews.If your site's login is “Sign in with Google,” a naive wrapper will throw a 403 disallowed_useragenterror at the worst possible moment — your user's first login. The fix is routing OAuth through an external or custom tab rather than the embedded view. This is exactly the kind of thing the free first build exists for: install the watermarked APK on a real phone and walk through your actual login flow before you pay anyone anything.

The Google Play quality bar: don't ship a URL-loader

Sideloading has no reviewer. Google Play does, and its spam and minimum functionalitypolicies exist specifically to keep out apps that are nothing but a website in a box. Reviewers reject apps that “simply load a website URL” with no app-like behavior — and in 2024 Google explicitly widened its quality sweep to remove low-value apps that offer “limited functionality.” A bare wrapper with a default icon is the textbook case.

The line between rejected and approved is not mysterious. Apps that pass tend to have:

• Push notifications actually enabled — the clearest “this is an app, not a bookmark” signal;
• A real icon and splash screen, not the tool's defaults;
• Graceful offline and error states instead of a raw connection error;
• An owner match — you are wrapping your own site, and your developer account, site domain, and privacy policy all line up. Wrapping someone else's site is a fast suspension;
• A store listing written for the app, not three keywords and a screenshot of your homepage.

Two Play logistics to plan around: registration costs a one-time $25, and if you create a personal developer account (any created after November 13, 2023), Play requires a closed test with 12 testers opted in for 14 consecutive daysbefore you can apply for production access. It's a real calendar cost — recruit the testers the same week you build, not after.

Costs, in one honest paragraph

The first build is free— one credit, watermarked splash screen, real signed APK you can put on a device today. After that: Starter is $29/month for 10 build credits, Pro is $99/month for 30, Agency is $199/month for 100 (annual: $290 / $990 / $1,690). One Android build costs one credit, failed builds auto-refund automatically, and a $49 urgent option exists when you need a build jumped to the front of the queue. Payment is card via Stripe or USDT. Google Play's $25 registration is the only other cost for the Android path. If you would rather assemble a wrapper yourself with open-source tooling and your own Android Studio install, that is a legitimate route too — we wrote up every free way to convert a website to an Android app and when each makes sense.

FAQ

Do I get an APK or an AAB, and which one do I need?

Both come from the same build. Use the APK to install directly on devices — sideloading, internal team distribution, or hosting the file yourself. Use the AAB for Google Play: since August 2021, Play only accepts new apps as Android App Bundles, not plain APKs. Code2Native delivers both formats, signed and ready.

Is converting a URL to an APK really free?

Your first build is free — one build credit, with a watermark on the splash screen. Paid plans start at $29/month (Starter, 10 credits), and failed builds auto-refund the credit. Separately, Google Play charges a one-time $25 developer registration fee if you want to publish there; installing the APK directly on your own devices costs nothing.

Will Google Play accept an app that just loads my website?

Not if that is literally all it does. Play's spam and minimum functionality policies reject bare URL-loaders. Apps that pass add app-like value — push notifications, a proper icon and splash screen, offline error handling — and are submitted by the site's actual owner. New personal developer accounts (created after November 13, 2023) also need a closed test with 12 testers for 14 days before they can apply for production access.

Why does the signing keystore matter so much?

Android identifies an app by its package name plus its signature. Every future update must be signed with the same key as the version already installed, or Android refuses the update and Google Play rejects the upload. Back up your keystore, and enroll in Play App Signing so a lost upload key can be reset instead of permanently orphaning your app.

Can people install my APK without the Play Store?

Yes — sideloading is legal and normal on Android. The user enables “Install unknown apps” for their browser or file manager, and Google Play Protect scans the file at install time. As of mid-2026, be aware Google is rolling out developer verification for app installs on certified Android devices: it starts September 2026 in Brazil, Indonesia, Singapore, and Thailand, and is slated to expand globally in 2027.

Is the result a real native app or just my website in a shell?

It is a native Android shell rendering your live site in a WebView — a real, signed APK/AAB with a real icon and push notifications via OneSignal, installable and publishable. It is not a native rewrite: your site must stay deployed and reachable over HTTPS, and the upside is that content changes ship instantly because the app always renders the live site.