Internal App Sharing vs. Closed Testing: Which Should You Use?

The Google Play Console offers a confusing array of testing tracks: Internal, Closed, Open, and a separate tool called Internal App Sharing.

Many developers confuse the "Internal Testing Track" with "Internal App Sharing". They sound similar, but they serve completely different purposes. This guide clarifies when to use which.

1. Internal App Sharing

Think of this as "Quick & Dirty" distribution.

• Purpose: Sharing ad-hoc builds with QA or fellow developers instantly.
• Speed: Instant. No processing time. No review.
• Versioning: Version codes don't matter. You can upload the same version code twice.
• Requirement: Useful for checking a specific bug fix (e.g., "Hey, does this APK fix the login crash?").

Two gotchas trip people up. First, each link serves at most 100 distinct users and expires 60 days after upload; a wider group or an older build needs a re-upload and a fresh link. Second, every tester has to switch on Internal app sharing inside the Play Store app on their own device, and the switch stays hidden until they unlock it. Skip that and the link stops at a notice that internal app sharing is turned off; the fix is in its own section below. If you restricted the link to email lists instead of leaving the default, “Anyone you shared the link with can download”, their Google account must also be on your list.

Because version codes are ignored here, it is easy to lose track of exactly which binary you shared. A quick pass through an APK inspector confirms the package name, version name, and version code before you send the link out.

2. Closed Testing (Alpha/Beta)

Think of this as "Formal Staging".

• Purpose: Testing a release candidate with a trusted group of users before production.
• Speed: Slower. Builds must be reviewed by Google (though usually faster than production review).
• Versioning: Strict unique version codes required.
• Requirement: Useful for end-to-end testing of the actual release artifact.

There is one more reason to take Closed Testing seriously. Google requires personal developer accounts created after November 13, 2023 to run a closed test with at least 12 testers who stay opted in for 14 continuous days before the account can apply for production access (the count was 20 until Google lowered it in December 2024). Internal App Sharing downloads do not count toward this requirement — only a genuine Closed (or Open) testing track does. If you are on a newer account, set up the track early so the 14-day clock starts running while you are still fixing bugs.

Key Differences Table

Workflow Recommendation

For Daily Development: Use Internal App Sharing. It’s fast and doesn't clutter your release tracks.

For Release Candidates: Once you think a build is "Gold", upload it to the Closed Testing track. Let your QA team verify it there. If it passes, you can click "Promote to Production" with one button, ensuring the exact same binary goes live.

If you would rather skip the Play Console entirely for the earliest throwaway builds, see our guide on sharing Android APK files for testing, or the full comparison of direct APK sharing vs Play Store internal testing.

Fix “Internal app sharing is turned off”

This notice comes from the Play Store app on the tester's phone, not from Play Console. It is not a link error: internal app sharing is switched off on that device, and the switch stays hidden until the tester unlocks it. On the tester's device:

1. Open the Google Play Store app.
2. Tap the profile icon, then Settings. (Older Play Store versions, and Google's own help page, call this Menu → Settings.)
3. Open About and tap Play Store version seven times.
4. Go back to Settings, open General and turn on Internal app sharing. Some Play Store versions put the switch inside Developer options.
5. Tap Turn on to confirm.
6. Reopen the internal app sharing link and install.

The switch is a setting in the Play Store app, so it has to be turned on on every device that will open the link. If the link still will not install after that, Google's troubleshooting list covers the remaining causes, all fixed from your side:

• The tester is not authorized. If you restricted the link to email lists instead of the default, “Anyone you shared the link with can download”, the Google account signed in to their Play Store must be on the list.
• The app is not available to them on Google Play. Google requires testers to have access to your store listing: the app has to be distributed in their country and published to production or to a testing track they can reach.
• The link is used up or expired. After 100 users, or 60 days after upload, upload the same file again to get a fresh link.

If your testers would rather not dig through Play Store settings at all, BetaDrop sends an APK install link that needs no Play Store toggle and no Google account; Android asks them, the first time, to allow installs from their browser.

When Google's Tracks Get in the Way

Both Google options are gated behind a Google account, and Internal App Sharing caps each link at 100 users — a real ceiling when you are running a wider external beta or handing a build to a client or contractor who never set up a Play tester account. Uploading the APK to BetaDrop instead gives you an over-the-air install link and QR code with no 100-user ceiling and no tester accounts to manage (a per-app device cap applies by plan: 10 free, 50 Pro, unlimited on Studio); testers install straight from their phone browser. It is the same shareable-link idea as Internal App Sharing without the account gate — much closer to a Diawi-style workflow. Free builds are short-lived (a build link defaults to 3 days and a free account can extend it to 7 days), so it suits disposable QA drops rather than permanent hosting, and the upload limit is 500 MB.

Frequently Asked Questions

Does Internal App Sharing require app review?

No. Builds uploaded to Internal App Sharing are available immediately for download via the link. There is no review process, no processing wait, and no version-code check.

How many people can download an Internal App Sharing build?

Each Internal App Sharing link can be downloaded by at most 100 distinct users, and it expires 60 days after upload. Past either limit, re-upload the build to generate a fresh link. Closed Testing tracks have no equivalent per-link user cap.

Who can download from Internal App Sharing?

Anyone with the link, provided you have added their Google account email to the authorized list on the Internal app sharing page in Play Console, OR you have enabled "Anyone you shared the link with can download" in the Play Console. Testers must also turn on the Internal app sharing setting inside the Play Store app on their device.

How do I fix “Internal app sharing is turned off”?

The notice means the Internal app sharing switch is off in the Play Store app on that phone. On the tester's device, open the Play Store, tap the profile icon, then Settings. Open About and tap Play Store version seven times. Go back to Settings, open General and turn on Internal app sharing (some Play Store versions put it inside Developer options), tap Turn on, then reopen the link.

Do testers need a Google account for Internal App Sharing or Closed Testing?

Yes, for both. Every Google Play testing track — Internal App Sharing, Internal, Closed, and Open — installs through the signed-in Play Store account. There is no account-free or anonymous install path on Google Play.

Can I promote a build from Internal App Sharing to Production?

No. Internal App Sharing artifacts are temporary. To release to production, you must upload the AAB to a formal track (Internal, Closed, Open, or Production) with a higher version code than the current live release.

Should I use Internal App Sharing or Closed Testing for beta testers?

Use Internal App Sharing for quick, ad-hoc builds you want a developer or QA engineer to check in seconds. Use a Closed Testing track when you are validating the exact release-candidate AAB, need more than 100 installs, or plan to promote the same binary to production.