Public links let you recruit up to 10,000 external testers without collecting emails. Here's how to create, configure, share, and manage a TestFlight public link the right way.
A public link is a single URL that anyone can tap to install your beta. Instead of collecting individual emails and sending invites, you share one link and let testers self-enroll.
This is the fastest way to scale a beta. You can post the link in a social post, a newsletter, a forum, or a chat server and start recruiting testers in minutes.
TestFlight supports up to 10,000 external testers, and the public link is the easiest way to fill that capacity. You never have to know who is coming, only that the door is open.
The tradeoff is control. With a public link you give up per-person gatekeeping, so it is best for open betas where broad coverage matters more than tightly curated tester lists.
Before you can generate a public link, you need a build that is ready for external testing. That means a signed native binary uploaded to App Store Connect and finished processing.
You also need to have completed the external test information, such as a description and contact email, because external distribution requires it.
Your first external build typically needs to pass Apple's Beta App Review. Plan for this, because the public link will not distribute a build that has not cleared review.
As always, this assumes a real native app. If your project came from a web or AI builder, you must first compile and sign it as a native iOS target in Xcode before any of this applies.
In App Store Connect, open your app and go to the TestFlight tab. Find the section for external tester groups and create a new group.
Give the group a clear, descriptive name, such as "Public Beta" or "Newsletter Testers." Naming matters because you may run several groups with different purposes and links.
A group is the container that a public link attaches to. Testers who join through that link become members of that specific group, which keeps your audiences organized.
Keeping groups well-organized pays off later, since you can assign different builds to different groups and read feedback per group rather than as one undifferentiated pile.
With the group created, assign a processed build to it. Only builds that have finished processing and, where required, passed Beta App Review can be distributed.
Write useful release notes when you assign the build. Testers who arrive through a public link have no prior context, so clear notes about what to test are especially valuable here.
If this is your first external build, submit it for Beta App Review and wait for approval. Once approved, the build is eligible to go out to the group.
The build assignment is what makes the link live. Without an approved, assigned build, the public link has nothing to hand to the testers who tap it.
Inside the external tester group, look for the public link option and enable it. App Store Connect generates a URL tied to that group.
You can optionally set a tester limit on the link that is lower than the overall 10,000 cap. This is useful if you only want, say, the first few hundred sign-ups.
Copy the generated URL. This is the link you will share, and anyone with it can request to install your beta up to the limit you set.
Treat the link as semi-public by nature. Once it is out, you cannot easily control who reshares it, so set your tester limit thoughtfully if you want to cap exposure.
Now distribute the link wherever your target testers gather. Social posts, community channels, mailing lists, and landing pages all work well.
Pair the link with a short pitch. Tell people what the app does, what you want feedback on, and that they will need the free TestFlight app from the App Store to participate.
Set expectations about device and OS requirements. If your beta needs a recent iOS version, say so up front to avoid frustrated testers who cannot install.
A little onboarding copy goes a long way. The smoother you make the first-run experience, the more of your recruited testers will actually complete installation and send feedback.
Once the link is live, watch your tester count and engagement in the TestFlight tab. You can see how many testers installed and which builds they are running.
If you hit your desired number, you can disable the public link to stop new sign-ups while keeping existing testers active. This is a clean way to run a time-boxed recruitment push.
Feedback and crash reports from public testers flow into App Store Connect just like any other external tester. Review them per group to keep signal organized.
Keep shipping fresh builds, because each build expires 90 days after upload. Public testers especially benefit from steady updates, since a stale or expired build gives a poor first impression of your app.
It is worth understanding the journey from the tester's side, because a smoother journey means more completed installs. When someone taps your public link, it opens in their browser or the TestFlight app.
If they do not yet have the free TestFlight app, they are prompted to install it from the App Store first. This is a common drop-off point, so mention the requirement up front when you share the link.
Once TestFlight is installed and they accept, your beta appears inside the TestFlight app alongside any other betas they are testing. They tap install, and your build downloads like a normal app.
From then on, they can update to new builds you push, read your release notes, and send feedback. Reducing friction at that first step is the single biggest lever on how many recruited testers actually become active.
A short, clear pitch paired with the link does more for conversion than any other tweak you can make.
Do not treat a public link as a security boundary. Anyone who gets the URL can join up to the limit, so never use public-link betas to distribute sensitive or confidential builds.
Use separate groups for separate channels when you want to measure where testers come from. A link per channel makes attribution simple.
Watch the tester limit carefully. If you leave it uncapped, a viral post could fill your beta with low-intent installs that crowd out the feedback you actually wanted.
Finally, keep your test information current. Apple reviews external builds, and incomplete or misleading test details can slow approval and stall your public-link rollout.
A public link can recruit up to the overall external tester limit of 10,000. You can also set a lower cap on an individual link if you only want a limited number of sign-ups.
No. The whole point of a public link is that testers self-enroll by tapping the URL. They do not need an individual email invite, though they do need the free TestFlight app installed.
Yes. You can disable the public link in the external tester group to stop new sign-ups. Existing testers who already joined remain active and can keep testing assigned builds.
Yes. External distribution, including via public link, typically requires the build to pass Apple's Beta App Review before it can be installed by testers.
No. Anyone with the URL can join, so a public link should not be used for sensitive or confidential builds. Use email-based external testing or internal testing for tighter control.