Giving Creators and Early Users Access to Your App Before Launch: TestFlight and Google Play Testing
How to give creators, press and early users pre-launch app access with TestFlight and Google Play testing: limits, review, build expiry and embargoes.
How do you give creators early access to an app before launch?
On iOS, add them as external testers in TestFlight, by email or a public link. On Android, add them to an internal or closed testing track using an email list or Google Group. Plan around each platform's rules: Apple reviews the first external build and builds expire after 90 days, Google Play open tests are publicly visible, and new personal Play accounts need a 14-day closed test with at least 12 testers before production. Then agree an embargo date, give each person a clear brief on what's unfinished, and collect feedback in one place.
This guide covers the distribution mechanics and planning for pre-launch access. For the release itself, see the first app launch checklist.
Key takeaways
- Use TestFlight external testing on iOS and closed testing on Android for invited previews.
- Prefer email invites over public links when access should stay controlled.
- Allow time for Apple's review of the first external build.
- Watch the 90-day TestFlight build limit against your launch date.
- Don't use a Google Play open test for a private preview; it is public.
- Agree embargo dates and disclosure expectations in writing.
Why give early access at all
Pre-launch access serves three groups. Early users and beta customers find bugs and confirm the product is useful. Press and analysts need time to try the product before writing about it. Creators need a working app to make content that shows it in use, which is why their access usually has to start weeks before launch. Each group needs a different level of polish and a different set of instructions.
TestFlight and Google Play testing compared
| Apple TestFlight | Google Play testing tracks | |
|---|---|---|
| Small trusted group | Internal testers: up to 100 App Store Connect users | Internal testing: up to 100 testers added by email |
| Invited wider group | External testers: up to 10,000, by email or public link | Closed testing: email lists or Google Groups |
| Public beta | Public link (anyone with it can join, subject to criteria you set) | Open testing: visible on Google Play; anyone can join |
| Review | The first build added to an external group goes to App Review; later builds may not need a full review | Managed through Play Console; check current review behaviour for your account |
| Build lifetime | Up to 90 days per build | Not stated in the testing help page; check Play Console |
| New account requirement | None stated | Personal accounts created after 13 Nov 2023: 12+ testers opted in for 14 consecutive days before production access |
Invite links or email lists?
A TestFlight public link is convenient but anyone who receives it can join, up to your tester limit, so it can spread beyond the people you meant to invite. Apple lets you set criteria such as device type and OS version, and recommends disabling the link once you reach your limit. For a controlled creator or press preview, invite people by email instead, so you know exactly who has access.
On Android, internal testing is limited to 100 testers added by email, and testers can't find the app by searching Google Play, so share the opt-in link directly. Closed testing scales further with email lists or Google Groups. Keep creators and press in a separate list from beta customers, so you can give them different builds and instructions.
Timing around review and expiry
Work backwards from the launch date. Apple reviews the first build you add to an external TestFlight group before external testing can begin, so leave time for that review. Each TestFlight build is available for up to 90 days, so a build sent to creators three months before launch will expire before launch day. Upload a newer build in time and tell testers to update, especially if content will be filmed close to launch.
If you have a new personal Google Play developer account, the closed-test requirement of at least 12 testers opted in for 14 consecutive days must be met before you can apply for production access. Testers who opt out before 14 days don't count, so start the closed test well ahead and recruit more than 12.
Brief testers properly
- What the build is for and what is unfinished or known to be broken.
- The embargo date: when they may post or publish, and what they may show before then.
- Whether screenshots and recordings are allowed, and which screens to avoid.
- How to send feedback: one form or channel, not scattered messages.
- Test accounts, sample data or promo codes they need.
- For creators and press: what's confidential, and any disclosure expectations.
Creators: access is the start, not the campaign
Giving creators early access works like sending a physical product to them before launch. Some will make content, some won't, and the ones who genuinely like the app become candidates for paid partnerships later. If they do post about an app they were given free access to, disclosure rules in their market may still apply, so include that in the brief.
Choosing which creators to invite, handling opt-ins and tracking who posts is specialist work. Kudozz runs influencer seeding programmes, building the creator list, handling opt-ins and logistics, and tracking mentions. Disclosure: ZSpace Labs has a paid partnership with Kudozz, and this is a sponsored link.
Hypothetical example: a fitness app's six-week preview
A fitness app plans a launch in six weeks. It sets up TestFlight external testing with three groups (beta customers, press, creators) and an equivalent closed test on Google Play. Creators and press are invited by email, not public link. The first external build is submitted for review in week one; a release-candidate build follows in week four so the build creators film with won't expire. Everyone receives a one-page brief with the embargo date and a feedback form. This illustrates the plan, not a client project.
Common mistakes
- Using a public link or open test for what should be a private preview.
- Forgetting that the first external TestFlight build needs review.
- A TestFlight build that expires before launch day.
- Starting a new Play account's closed test too late for the 14-day requirement.
- No embargo date, so content goes live before the app is available.
- Feedback scattered across chats and emails.
Conclusion and next steps
Pre-launch access is easy to set up and easy to get wrong on timing. Choose the right track for each group, invite people by email when access should stay controlled, plan around Apple's review and 90-day build limit and Google's closed-test rules, and give everyone a brief with an embargo date and one place for feedback.
Building an app with a launch date to hit?
ZSpace Labs builds iOS and Android apps and handles app store preparation, submission and release management. See our mobile app development service.
Sources
Apple: TestFlight; TestFlight overview (App Store Connect Help).
Google Play Console Help: Set up an open, closed or internal test; App testing requirements for new personal developer accounts.
Accessed 17 October 2026. Store policies change; check current documentation before relying on any detail.
Common questions.
Apple allows up to 100 internal testers from your App Store Connect team and up to 10,000 external testers, who can be invited by email or a public link. The first build you share with external testers is reviewed by Apple before testing can begin.