App On The Go
Log in
Distribution guide

How to share an APK with testers — six methods compared

Updated May 2026 · ~7 min read

What's in this guide

Sharing an APK with a beta tester sounds trivial — it's just a file. But Android (sensibly) treats every install from outside the Play Store as a security event. Testers see warnings. Files get blocked by Gmail. Chat apps strip out APKs to prevent malware. The "just send the file" approach usually ends in a Slack thread that's mostly screenshots of error dialogs.

Here's how the six common approaches actually compare, and when each one makes sense.

The six methods at a glance

1. Email / chat attachment

When it works: You and the tester are in a chat or email thread anyway, and the build is < 25 MB.

When it doesn't:

It works for the one developer-to-developer "hey try this real quick" case. Don't try to coordinate ten testers this way.

2. Google Drive / Dropbox / WeTransfer

When it works: Your tester is comfortable with phones, build size is up to ~2 GB, you don't need install analytics.

Upload the APK, share the link, send it. The tester opens the link in Chrome on their Android device, taps download, navigates to Files or Downloads, opens the APK, and grants the "Install unknown apps" permission for Chrome (or whichever browser they used).

Friction: 3–5 taps on the tester's end. Most testers stall at "where did the file save?". Also: you have zero visibility into whether the tester actually installed.

3. Firebase App Distribution

When it works: You're already on Firebase, your testers are willing to install the Firebase App Tester app, and you want a polished invitation flow.

Firebase's main UX win: a tester gets an email invitation, taps a link, and the Firebase App Tester app handles every subsequent build automatically. No more re-sharing links for each new build.

Friction: First time, the tester installs the App Tester (which itself has the "Install unknown apps" warning). After that, builds appear automatically. Reasonable tradeoff for a long-running beta program.

4. App On The Go (or Diawi-style hosted install)

When it works: Almost always. This is the lightest-friction option for both you and the tester.

The flow:

  1. Drop your APK on apponthego.com. We host the file, extract metadata, and generate a short URL + QR code.
  2. Send the URL (or screenshot the QR) to testers.
  3. Tester opens the link in Chrome, taps Install, grants "Install unknown apps" once, and they're done.

What the tester sees: a clean install page with your app's icon, name, and version — pulled automatically from your APK's AndroidManifest.xml. One tap, one install. No app to download first.

You get: install analytics, link expiry control, optional password protection, and the same URL for both iOS and Android builds. Free up to 100 MB without an account.

Diawi works the same way. App On The Go is faster, has a more generous free tier (100 MB vs Diawi's 70 MB free / 200 MB paid), and doesn't put ads on the install page.

Try the easy path. Drop an APK, get a shareable install link in under 3 seconds.
Share an APK →

5. Self-hosted on a static URL

When it works: You have your own infrastructure and want full control over the install page (branding, gating, analytics).

Mechanics: serve the .apk file as a static download on any HTTPS-accessible URL. Chrome on Android handles the rest — recognises the file type, prompts the user to install. Nothing fancy required server-side.

If you want it pretty (custom install page with the app icon, version, etc.), parse the APK's AndroidManifest.xml server-side. Our APK analyzer shows exactly what data is available — same data you'd extract for your own install page.

6. Google Play Internal Testing

When it works: You're shipping to dozens of testers, expect builds to stabilise over weeks, and want the Play Store's update mechanism handling distribution.

You upload an AAB to the Play Console, add tester emails to an "Internal testing" track, and Google's review system gives you a Play Store link in ~24 hours. After that, testers install through the Play Store like any other app, and future builds update silently.

Why not always use this: the first-build wait is real, you need a Play Console account ($25 one-time fee), and you have to bundle as AAB instead of APK. Worth it for serious beta programs; overkill for a 2-person QA pass.

"Install unknown apps" — what testers see

This is the one Android-specific thing every tester needs to know about. When they tap "Install" on a non-Play APK, Android shows:

For your security, your phone is not allowed to install unknown apps from this source.

It's not blocking you; it's asking permission. The tester taps Settings, toggles Allow from this source for whichever browser they used (usually Chrome), backs out, and continues the install.

This permission is per-browser-or-app, not global. If they install via Chrome today and Firefox tomorrow, they grant it twice. Worth including in the install instructions you send testers.

A note on APK signing

Android requires every APK to be signed. Debug builds are signed with a generated debug key automatically; release builds with your release keystore. Either is fine for distributing to testers — Android doesn't care which key as long as the APK is signed.

What matters: if you ship a build signed with debug key today and one signed with your release key tomorrow, Android treats them as different apps. Testers will get an "App not installed" error trying to upgrade. Pick one signing key per beta program and stick with it.

Curious what's in your APK before shipping? Drop it in our APK analyzer — it shows the signing certificate, version code, permissions, and everything else.

Which method should I actually use?

Related reading