How to Add a TestFlight Beta Waitlist to Your iOS App (2026)
A TestFlight beta waitlist is the cheapest way to filter who gets in before you hit Apple's 10,000-tester cap. How to set one up, what two questions to ask on the form, and how to invite people from the list.
Posted by
RouzbehRelated reading
Best Product Feedback Tools for Indie Founders (2026)
Best product feedback tools for indie founders in 2026: Canny, Featurebase, Nolt, Frill, Sleekplan and Lighthouse compared on price and fit for a small product.
Waitlist with a Survey: Why Answers Beat Emails (2026)
A waitlist with a survey tells you who signed up, what they want, and what they would pay, before you write a line of code. Why an email-only list is a vanity metric, what questions to ask, and how to read the answers.
How to Validate a Startup Idea Before Writing Code (2026)
The cheapest insurance against shipping into silence is validating the idea before you build it. Five small experiments, what each one tells you, and how to read the result honestly.
A TestFlight beta waitlist gives you a controlled way to let interested users into your iOS beta before you hit Apple's 10,000-tester ceiling. The form does most of the work: two questions filter for the right devices and the right use case, and the email gives you a list to send TestFlight invites to in whatever order makes sense for the test.
I have shipped 7 iOS apps over 8 years and ended up building two tools for myself along the way: Spaceport, a SwiftUI starter that gets a paid iOS app live in days, and Lighthouse, the launch toolkit this post is about. A beta waitlist is one of those pieces I kept rebuilding from scratch every project until I made the plumbing once.
Table of contents
Why bother with a waitlist for a TestFlight beta?
TestFlight is generous, up to a point. You can invite up to 10,000 external testers per build, but that cap fills faster than you expect once a single mid-sized newsletter or a viral tweet sends people your way. A waitlist between you and the TestFlight signup link gives you three things: control over how many testers go in at once, a chance to filter out incompatible devices, and an audience to email when the beta ends and the app ships.
The other reason is more boring but it matters. A raw TestFlight link gives you almost no visibility into who is installing your build. A waitlist captures the email and a couple of survey answers in the same form, so when something crashes you have someone to talk to.
The three jobs a beta waitlist does
Name the jobs before you pick the tooling. A TestFlight waitlist does three things at once:
- Filter testers. An iPad-only beta does not want iPhone-only testers, and an iOS 18 beta does not want someone still on iOS 16. Two questions on the form sort this out before you waste an invite slot.
- Set expectations. "You are on the waitlist, we will invite the first 100 in two weeks" is a better signal than silence. Saves you support emails and keeps people warm.
- Build a launch list. The waitlist becomes your first email list when the app hits the App Store. People on it raised their hand twice, once for beta and once implicitly for launch.
Practical rule: every TestFlight build wants a waitlist behind it, even if the waitlist is just to slow the first 48 hours down enough to read the answers.
How to set up the waitlist
The whole setup takes under an hour. Three steps:
- Decide what you need to know about each tester. For most iOS betas that is the device (iPhone, iPad, both), the iOS version, and the one thing they want to do with the app. Three questions max on the signup form so people actually finish it.
- Spin up a public waitlist page. You can build one yourself, but for an indie iOS launch it is cheaper to use a hosted waitlist tool that supports survey questions on the form, like Lighthouse. You get a public URL in a few minutes, no DNS gymnastics. For the wider setup walkthrough, see the guide to building a waitlist for your app.
- Point the App Store link or the TestFlight public link at the waitlist, not at the build. The order matters: people land on the waitlist, give you a filtered signup, and only then do you send the TestFlight invite manually or in batches.
What to ask on the signup form
Two short questions and the email is the sweet spot. The return-per-question drops fast after that. Here is the shortlist I use for an iOS beta:
| Question | Why you ask it | How you use the answer |
|---|---|---|
| Which devices will you test on? | iPad-only or iPhone-only betas need compatible testers. | Segment your invite batches by device type. |
| Which iOS version are you on? | You may target a specific minimum and need testers above it. | Skip incompatible devices before sending the invite. |
| What do you want to do with the app first? | The one open-text question. Answers become your launch copy. | Group testers by use case and write to them in their own words. |
Skip pricing questions during a beta. You are not selling yet, and asking about money on a beta form reads as off-tone. Save it for the launch survey. The longer logic of which questions move which decisions is covered in why answers beat emails on a waitlist.
Inviting people from the waitlist into TestFlight
You have two options inside App Store Connect: the public TestFlight link or per-email invitations. For a waitlist flow, per-email is the better default because it gives you attribution. Steps:
- In App Store Connect, open your app and TestFlight. Create an external tester group (call it "Waitlist - Wave 1" or similar).
- Export the first batch from your waitlist dashboard as a CSV. Filter by the device and iOS version answers so the wave is compatible with the build.
- Paste the emails into the External Testers group. Apple sends the TestFlight invitation; you do not need to email the link yourself.
- Wait for crash reports and feedback to roll in before opening the next wave. Smaller waves are easier to talk to.
If you want the manual step to go away entirely, the REST API on Lighthouse Pro can post the new signups straight into your own script, which can then call App Store Connect. That is the indie automation route once the volume justifies it.
Communicating with the beta list during the test
Silence is the worst feedback channel. A short update every week or two during the beta keeps the audience warm and the crash rates honest. Things worth saying:
- What is in the new build. Two or three bullets, no marketing.
- What is known to be broken. Saves you 30 identical bug reports.
- What you would like them to specifically try. Direct testing gets you better data than open-ended "use it normally".
The same tool that runs your waitlist usually also handles this newsletter side, which means you do not need to export the list into a second tool for the weekly update. After the beta the same list becomes the launch list.
Common mistakes
- Inviting everyone at once. A wave of 500 testers in one afternoon will drown you in identical bug reports and you will miss the real ones. Stagger.
- Not filtering by iOS version. The first wave of complaints will be from people on iOS 16 if your minimum is iOS 17. They are right to complain and wrong to be testing.
- Treating the beta list as a one-shot. Those testers self-selected for your specific app idea. They are your warmest launch list. Do not lose them after the beta ends.
- Promising a launch date you cannot keep. Apple reviews can take days, and external factors slip the timeline. Say "within X weeks" instead of a specific date.
Frequently asked questions
How do I add a TestFlight beta waitlist to my iOS app?
Set up a hosted waitlist page that asks for an email plus two or three short questions about device and iOS version. Point your existing TestFlight or App Store link at the waitlist instead of straight at the build. Invite people in batches from the waitlist dashboard into TestFlight via App Store Connect.
Can I use the public TestFlight link as a waitlist?
Technically yes, but you lose the filter, the survey data, and the email capture. The public link is a faucet, the waitlist is a valve. You usually want the valve.
What is the TestFlight tester cap and does it really matter?
Up to 10,000 external testers per build. It usually does not matter for indie betas, but if a launch goes well the cap can fill in a day. A waitlist keeps you from hitting it accidentally.
How many questions should I ask on the signup form?
Two short ones plus one optional open text. Three is the ceiling for a beta waitlist. More than that and the signup rate drops faster than the data quality rises.
Do I need a custom domain for the waitlist?
Not for a beta. A shared subdomain is fine. The custom domain becomes worth it at launch when the waitlist URL goes on the App Store listing and in launch posts.
A TestFlight beta is one of the few moments in indie iOS development where you are forced to talk to your users directly. A waitlist in front of it is just structure: it decides who gets in, what they tell you on the way, and what you do with them when the beta ends.
Lighthouse handles the waitlist, the device/version filtering on the signup form, the launch newsletter, and the post-launch feedback page, in one place. Free trial, indie pricing. From the same indie dev behind Spaceport, a SwiftUI starter kit for shipping paid iOS apps fast.