What Is TestFlight? A Complete Beginner’s Guide from Your First Invitation to a Successful Installation

Verified on September 17, 2026. This guide focuses on iPhone and iPad. Apple’s interfaces and rules can change, so refer to the official documentation linked here and the pages you actually see.

You have built an app and want friends to try it, but you are not ready to release it on the App Store. Sending them the source code will not work, and even if you send an app package, they may not be able to install it.

That is the problem TestFlight solves.

When people say “TF,” they usually mean TestFlight. It is Apple’s beta distribution service: developers upload a beta, invite people to install it, collect feedback, and then send out an improved version. Testers install a real app that runs on their devices, not a screenshot or a web demo.[1][2]

Start by remembering these 3 points:

• Internal testing is for members with the appropriate App Store Connect permissions.
• External testing is suitable for friends, customers, and community members, without giving them access to your developer administration tools.
• Each build can be tested for up to 90 days, starting on the day it is uploaded. Passing TestFlight App Review does not mean the app has been released on the App Store.[1][3]

If you have simply received someone else’s invitation link, you can skip to section 9, “How Do Testers Install, Update, Give Feedback, and Leave?” If you want to share your own app, start at the beginning.

1. What Are TestFlight, App Store Connect, and the App Store?

Think of a new app as a shop having a soft opening: TestFlight helps you invite people to try it, while the App Store is the channel for opening to the public. A soft opening still has time limits and rules; it is not a back door around review.

These 3 names sound similar, but they serve different purposes:

Scroll sideways to view wide tables. Keyboard users can focus the table and use the arrow keys.

You download the TestFlight tool itself from the App Store, then use it to install apps you have been invited to test. An app appearing in TestFlight does not mean you can already find it in the App Store.[1][3]

Apple uses TestFlight to connect the steps of “distribute a build—invite testers—collect issues—update the build.” Today’s TestFlight does not require developers to collect each tester’s device identifier or create a separate installation provisioning profile for every tester.[2]

But it will not write your app for you, prove that every feature works correctly, or automatically turn a beta into a release version. Even passing TestFlight App Review does not guarantee that an app is free of bugs or will not lose data. When testing an unfamiliar app, do not risk your only copy of important information.

2. TestFlight’s History: Apple Did Not Build It from Scratch

Knowing the history helps explain why older tutorials use different names, tester limits, and procedures.

• January 2011: The third-party service launched publicly. At the time, testing unreleased iPhone apps often involved handling device identifiers, app packages, and provisioning profiles, then syncing through iTunes on a computer. TestFlight made wireless installation much easier. This marks the move from private testing to a public service, not the date the company was legally founded.[H1]
• March 2012: Its acquisition by Burstly was announced. TestFlight was still a third-party product at this point.[H2]
• February 2014: Apple acquired Burstly. TestFlight joined Apple along with its parent company.[H3]
• October 2014: Apple announced email invitations for testing through iTunes Connect. iTunes Connect was the predecessor to today’s App Store Connect, and the limit at the time was 1,000 invited testers. Note that this is a historical figure.[H4]
• July 2017: The external tester limit increased to 10,000.[H5]
• September 2018: Apple introduced public invitation links. Developers could recruit testers by sharing a link without first collecting everyone’s email address individually.[H6]

Today, TestFlight covers multiple Apple platforms, including iPhone, iPad, Mac, Apple Watch, Apple TV, and Apple Vision Pro. Using iPhone as the example in this guide does not mean TestFlight can only test iPhone apps, nor does it mean it can distribute Android apps.[2][3]

3. Learn These 5 Terms First: Beta, Version, Build, Group, and Review

Beta: A version of an app that is still being tested and improved, and may have problems.

Version: A label such as 1.0 or 1.1 that identifies a release iteration.

Build: One specific packaged copy of an app. For example, 1.0 (12) means version 1.0, build number 12. After fixing an issue, you could upload 1.0 (13): the version number is the same, but the installed content has changed.[7]

Group: Determines who can receive which builds. You could create “Team” and “Early Access” groups and give them the same or different builds. A group can have multiple builds, and the same ordinary build can be assigned to multiple groups.[2][5][6]

TestFlight App Review: Apple’s review for external testing, which is separate from the review for an official App Store release.[1][6]

Keep this relationship in mind to avoid getting lost: the app is the whole project, a build is one specific set of installable content, and a group determines who can try it. A public link belongs to an external group; it is not permanently tied to one particular build.

4. What Do Publishers and Testers Need Before Starting?

What publishers need

1. An active Apple Developer Program membership. Apple’s current standard price is $99 per year; regional prices may differ, and some eligible organizations can apply for a fee waiver. TestFlight is included in the relevant membership services, not purchased as a separate tester subscription.[4]
2. The correct app record in App Store Connect. The app’s identifier, signing, and uploaded content must match. You cannot simply add another app’s package.[7]
3. Sufficient account permissions, without granting more than needed. Account Holder, Admin, App Manager, and Developer roles can upload builds; managing external testing requires the Account Holder, Admin, or App Manager role. Being able to upload does not mean you can manage every external testing setting.[6][7]
4. Testing information. This includes an app description, feedback email address, and what you want people to test. External review also needs contact information and a login or other means of accessing features that the reviewer can actually use.[6][8]
5. Devices and time for testing. A successful upload does not mean installation and key features have already been verified.

Do not send your Apple password to friends. To let someone test an app, send an invitation rather than sharing an administrator account.

What ordinary testers need

You only need an Apple Account, a compatible device, TestFlight, and a valid invitation. You do not need a paid developer membership or access to the developer administration tools.[1][3]

As of this guide’s verification date, Apple’s tester help page lists iOS 16 or later for iPhone and iPadOS 16 or later for iPad. However, an individual app can require a newer operating system, and public invitations can filter by device and OS version. Being able to install TestFlight does not mean you can install every app inside it.[3][6]

If you use a Managed Apple Account provided by work or school, check eligibility carefully: Apple’s external testing help explicitly states that these accounts cannot be used to test builds. Its internal testing help separately states that managed accounts created in reserved domains cannot be used for testing. If this applies to you, check the relevant help page and your organization’s policies rather than assuming the invitation link is broken.[5][6]

5. What Is the Difference Between Internal and External Testing?

The key difference is App Store Connect identity and permissions, not how well you know someone or whether the invitation was sent by email.

Scroll sideways to view wide tables. Keyboard users can focus the table and use the arrow keys.

Eligible internal tester roles include Account Holder, Admin, App Manager, Developer, and Marketing. The person must also have access to this app.[2][5]

Even if you privately invite a friend by email, external testing is usually the right choice. External does not mean public; you can invite just a few people without enabling a public link.

Do not give ordinary testers Admin permissions just to avoid a review step. That is not an installation switch—it grants real administrative access.

Another easily overlooked limit: individual developer accounts can add up to 50 App Store Connect users. TestFlight’s limit of “100 internal testers” therefore does not mean every individual account can create 100 additional App Store Connect members.[9]

6. How Do You Add a Build? First Separate “Uploading” from “Adding to a Test Group”

These are 2 different actions:

• Uploading a build: Sending an already packaged app to Apple from a development or build tool.
• Adding a build to a group: Choosing an available, already uploaded build to distribute to that group.

The Add Builds button in an App Store Connect test group does not generate an app when you drag source code into it, nor is it a button for uploading a local file.[5][6][7]

What if this is your first release and the app does not exist in App Store Connect yet?

An Account Holder, Admin, or App Manager should go to Apps → “+” → New App, choose the platform, and enter the required information, such as the app name, primary language, Bundle ID, and SKU used for administrative tracking. Then set member access and create the app. The Bundle ID must match the project. If you do not yet know which identifier to use, check with the person responsible for packaging the app rather than picking another app’s identifier at random.

If you cannot create the app, check whether the Account Holder has accepted the latest agreements. Creating an app record only creates its administrative entry; it does not upload or release the app.[15]

The basic upload path in Xcode

If you already have an iOS project, follow this sequence:

1. Check that the Bundle ID and signing team match the app record in App Store Connect.
2. Set a build number that has not been used for this new upload, for example by increasing 1.0 (12) to 1.0 (13).
3. Select a destination for distribution to real devices, then click Product → Archive to create an archive. Do not try to upload a simulator build.
4. In Window → Organizer → Archives, select the archive and click Distribute App. For regular TestFlight distribution and a later App Store release, choose TestFlight & App Store; in a custom workflow, the corresponding distribution method is App Store Connect. Follow the interface to finish signing and uploading.[16]
5. After uploading, go to App Store Connect → Apps → your app → TestFlight.
6. Wait for Apple to process the build. If export compliance questions appear, answer truthfully based on the encryption your app actually uses. Do not always select “no encryption” just to continue.
7. Once processing is complete and the build is available, add it to an internal or external test group.

Tools such as Xcode Cloud and Transporter can also be used for uploads. Using a different tool does not let you skip Apple’s processing, compliance, grouping, or external review steps.[7] Minimum requirements for upload tools and SDKs change, so check Apple’s current upload requirements when you upload. The SDK version used to build an app is not the same as the minimum OS version on which the app can be installed.[18]

Be careful with the “Internal Only” option

TestFlight Internal Only is a restriction set by the upload method: these builds can only go into internal groups, and cannot be used for external testing or released to the public. If you later need external testing or an official release, you must upload a new build using the appropriate method. Simply moving the original build to another group will not work.[5][6]

Conversely, adding an ordinary build to an internal group first does not automatically make it an Internal Only build. Do not confuse “currently being tested by internal members” with “this upload is restricted to internal use.”

If you are developing your app in AirBuild

You can ask AirBuild to help prepare a distributable build, handle signing and uploading, and configure test groups and invitations. First make it clear that you want to “distribute through TestFlight” and whether the audience is team members or external friends. Then connect or confirm an Apple developer team with the necessary permissions, and confirm the testing instructions, feedback email, review contact, and whether to enable a public link.

Apple’s processing, external review, tester limits, and validity rules still apply. At handoff, distinguish the exact version and build number, which group has access, and whether external review is still pending. AirBuild helping with the process does not mean it can bypass Apple’s review, nor does simulator testing cover every behavior on real devices.

This describes how AirBuild works, not an Apple requirement to use a particular tool. Not having local Xcode on a Mac also does not mean you must learn every packaging detail before collaborating with others to release an app.

7. How Do You Add Internal Testers? There Are 2 Invitations

This is for you and collaborators who genuinely need access to the app’s administration tools.

First: Make the person an authorized App Store Connect user

An Account Holder, Admin, or App Manager adds the user:

1. Go to Users and Access → People.
2. Click “+” and enter their name and email address.
3. Assign an appropriate role. Where the role allows app-level restrictions, grant access only to the apps they need. Do not default to Admin. Admin and Finance users, as well as users given access to additional resources such as reports or certificates, cannot have their access restricted to individual apps. Check the scope before choosing permissions.[9]
4. Send the invitation and have the person accept it to activate their App Store Connect access.

Apple currently states that this App Store Connect user invitation expires after 3 days, and can be resent if it expires. It is not the TestFlight invitation sent later, and it is not the build’s 90-day validity period.[9]

If the person already has an eligible role and access to the app, you can skip this step.

Second: Add people and a build to an internal test group

1. Go to Apps → your app → TestFlight.
2. Click “+” next to Internal Testing and create a group, such as “Team.”
3. Open the group and choose Invite Testers, or click “+” next to the tester list.
4. Select eligible App Store Connect members and add them to the group.
5. Click Add Builds and choose a processed build that is ready for testing.
6. Fill in What to Test and add the build.
7. Have the person install TestFlight on their device, accept the testing invitation, and then install the app.[5]

Having a name on the list is not enough to count as complete. There must also be an available build, and the person must actually accept the invitation and install it.

Cannot find the person you want to invite? First check whether they accepted the App Store Connect invitation, have an eligible role, and have access to this app. Do not immediately upload the app again.

Some internal groups can enable automatic distribution, but do not assume builds from every source will automatically be added to every group. Apple’s current help specifically states that builds created by Xcode Cloud must be added to groups manually in App Store Connect.[5]

8. How Do You Add External Testers?

This is for friends, customers, early users, and community testers. It is usually the more appropriate way to share an app with others for the first time.

First prepare an external group that can receive a build

An Account Holder, Admin, or App Manager performs these steps:

1. If you do not have an internal group, create one first. Apple’s current external testing tutorial lists creating an internal group as a prerequisite. This does not mean you must first release the app on the App Store, or that external testers must first become internal members.[6]
2. Go to Apps → your app → TestFlight.
3. Under Test Information, enter the beta description and feedback email, and complete the contact details required for review. If login is required, provide working review access and instructions, and make sure the relevant servers are available. Do not use real users’ private data as demo material.[6][8][14]
4. Click “+” next to External Testing and create a group, such as “Early Access.”
5. Open the group, click Add Builds, and select the platform, version, and specific build.
6. Fill in What to Test, for example, “Create a record, quit and reopen the app, and check whether the record is still there,” rather than just “Try anything.”
7. Select Automatically notify testers if appropriate.
8. Depending on the page’s status, choose to submit for review or start testing, and wait for any required review to finish.
9. Invite testers by email, public link, or both.[6]

Once the first build passes, are all later builds exempt from review?

No.

The first build submitted for external testing requires a full review. Later builds of the same version may not need a full review, but you cannot promise that they will always skip review. Apple also requires major beta updates to be submitted for TestFlight App Review before distribution.[6][14]

Review times vary. Do not promise that “everyone can definitely install it a few minutes after upload” or that “it will definitely be approved within 24 hours.”

If you did not select automatic notification when adding the build, you must also use Notify Testers after approval: under Builds in TestFlight’s left sidebar, select the platform and version, then click the notification option in that build’s status bar. Approved, distributed, and installed by the recipient are 3 different things.[6]

Method 1: Invite by email

Open the external group and click “+” next to Testers. You can enter new testers’ email addresses, select existing testers, or import a list.[6]

Recipients get a testing invitation, not administrative access to App Store Connect.

Method 2: Create and share a public link

Open the external group’s tester page and choose Create Public Link:

1. Choose Open to Anyone or Filter by Criteria.
2. Set a recruitment limit for the link if needed. This can be 1–10,000, but is still subject to the app’s overall external tester limit.
3. If using filters, set the target device and OS version criteria.
4. Confirm, then copy the actual generated link and send it to friends or share it in a community, email, or website.[6]

The link usually starts with https://testflight.apple.com/join/…. Copy the real link generated by Apple. Do not invent the code at the end or use an App Store Connect administration page address as an installation link.

A QR code can carry the same link, but it is not a different distribution method and does not bypass review.

Check these 4 things before sharing a link

• The target external group contains the build you want to share.
• Any required review has passed, and distribution has started.
• The build has not expired and is compatible with the target devices.
• The link is enabled, has spaces remaining, and its filters do not exclude the intended users.[3][6]

A link opening successfully does not mean the new version can necessarily be installed. An older build still being available does not mean the latest build has been distributed to that group.

A public link can be forwarded; it is not a confidential guest list. If you only want to invite a few specific people, prefer email invitations and set up access controls within the app’s own account system.

For people who join through a public link, names and email addresses are not shown in the TestFlight tester list by default, but information such as installation dates, sessions, and crashes remains visible. They may also provide an email address when actively submitting feedback. This does not mean they are completely anonymous to Apple or to the app’s own login system.[3][6]

When you update builds later, you can usually keep using the same external group’s link rather than recruiting everyone again each time. You can also use Manage to change filters or tester limits, or disable the link. Disabling a link stops new people from joining through it; it does not delete existing installations, close app accounts, or erase server data.[6]

9. How Do Testers Install, Update, Give Feedback, and Leave?

After receiving an invitation, follow these steps on the iPhone or iPad you will use for testing:

1. Install Apple’s official TestFlight app from the App Store.
2. Open the invitation email or public link.
3. Follow the prompts into TestFlight, choose Accept, and then tap Install.
4. Read what to test, then start using the app.
5. When a new build is available, update it in TestFlight. You can also enable automatic updates. Existing testers may see Update or Open directly.[3]

Ordinary external testing does not require the developer’s password, an App Store Connect role, or a dedicated sandbox account created in advance.

If the release version is already on my phone, will I get 2 copies?

Usually not. A TestFlight beta of the same app replaces the App Store version on the device.[3]

Back up or export important data first. A beta may change the data format, and an older version may not be able to read data written by a newer one. Do not assume switching versions is guaranteed to preserve everything without loss.

If the developer still offers other valid builds, you can choose them under Previous Builds. This is not a download archive that permanently preserves every historical version.[3]

What kind of feedback is easiest for developers to understand?

Open the app’s page in TestFlight and tap Send Beta Feedback. On supported systems, you can also take a screenshot inside the beta app and send feedback from there. After a crash, you may be prompted to share additional information.[3]

This is more helpful than “It doesn’t work”:

I am using [device model] with [OS version], and the app is [version and build number]. I opened Settings, changed the language, and returned to the home screen. I expected all the text to change, but the home screen was still in the old language. I tried twice and reproduced it both times. Screenshot attached.

Do not include passwords, payment information, or other people’s private information in screenshots. Feedback submitted through TestFlight is also shared with Apple; any feedback feature built into the app itself is a separate channel.[3]

What if I no longer want to test?

Open the app’s information page in TestFlight and choose Stop Testing. If a released version exists, you can then download or purchase it from the App Store. An app that only has a beta and has not yet been officially released may not have a release version to return to.[3]

Stopping testing does not delete an account you registered in the app. Accounts and cloud data must be handled according to the app’s own rules.

10. Will Payments in TestFlight Charge Real Money?

In apps installed through TestFlight, test transactions using Apple’s in-app purchases run in the sandbox and do not charge real money. This includes testing subscriptions through StoreKit.[3][10]

Think of the “sandbox” as a rehearsal environment for the purchase flow: the app can read product information, initiate test purchases, restore purchases, and handle transaction notifications, but these actions do not generate real sales revenue.[10]

The easiest thing to misunderstand is the sandbox’s scope.

No charge does not mean the released app is free forever

Apple explicitly states that in-app purchases made during testing do not carry over to the App Store release as purchases. Do not promise testers, “Tap once now and you will have a permanent membership after launch.”[3]

If a developer separately decides to grant benefits to app accounts, that is their own business arrangement, not an automatic TestFlight rule.

Test subscription timing is not real billing timing

For auto-renewable subscriptions, Apple’s current TestFlight tester guidance states that, regardless of the original subscription duration, test subscriptions renew daily, up to 6 times within a week. Advanced controls using a sandbox account can also adjust renewal rates. Do not apply parameters from other sandbox scenarios, such as “5 minutes” or “12 renewals,” directly to ordinary TestFlight testing.[3][10]

These accelerated rules help test renewals and expiration; they are not the billing cycles for real users.

Only Apple’s purchase channel automatically uses the sandbox—not the entire app

A TestFlight app may still:

• Connect to production servers and modify real records;
• Send real emails or messages;
• Delete real accounts or data;
• Open web pages that collect real payments;
• Use payment methods other than Apple’s in-app purchases.

Web payments, Apple Pay, and StoreKit in-app purchases are not the same thing. An app coming from TestFlight does not mean web checkout or real-world business activity cannot cost real money. Developers need to configure test data, servers, and other payment environments separately.[10]; explanation of app system boundaries

Does every tester need to create a sandbox account?

No. Ordinary TestFlight installation and purchase testing can use your everyday Apple Account.[10]

Developers only need to configure a Sandbox Apple Account according to Apple’s documentation when they need controls such as clearing purchase history or adjusting advanced test settings. Advanced steps may involve signing out of “Media & Purchases,” which affects access to purchased content on the device. This is not a prerequisite for ordinary testers to install the app, and you certainly should not casually tell people to sign out of iCloud on the entire device. Apple recommends considering a dedicated test device.[10]

If a purchase appears successful but the app does not unlock the feature, still report it to the developer. Product configuration, transaction verification, entitlement delivery, purchase restoration, and renewal handling all need to be implemented correctly. A successful sandbox purchase does not prove that production payments, revenue receipt, and all subscription logic are correct.

11. What Limits Does TestFlight Have?

Scroll sideways to view wide tables. Keyboard users can focus the table and use the arrow keys.

Does resending an invitation help after the 90 days expire?

No. The time limit belongs to the build, not to an individual tester. Someone joining later does not get a fresh 90 days. After expiration, the beta can no longer be opened, and the developer must provide a new, valid build.[3]

To avoid interrupting testing, upload and distribute a new build before the old one expires, and remind everyone to update. The new build has its own validity period; it does not extend the old build’s lifetime.

Can you use TestFlight long-term to sell apps or testing slots?

Do not treat it as a sales channel that bypasses an official release.

Apple’s App Review Guideline 2.2 requires beta apps to follow the review guidelines and be intended for public distribution. It also prohibits exchanging TestFlight beta distribution for compensation of any kind, including crowdfunding rewards. Put simply, “pay to join a group and get the beta” is not an acceptable TestFlight distribution plan.[14]

12. Common Problems: Why Can’t Someone Install the App?

Scroll sideways to view wide tables. Keyboard users can focus the table and use the arrow keys.

These are troubleshooting directions, not enough to identify a root cause from a single error message.[3][5][6][11]

Important: A green “Testing” status in App Store Connect may only mean an internal group is using the build. To determine whether external users can install it, check the target external group, the specific build, and its availability in that group.[11]

“Ready to Submit,” “Waiting for Review,” “In Beta Review,” and “Ready to Test” are also different stages. In particular, Ready to Test may still require adding testers or sending a manual notification.[11]

13. Where Do Developers See Feedback, and How Do They Send the Next Build?

Go to Apps → your app → TestFlight → Feedback to view Screenshots and Crashes, and filter by version, device, and other criteria. Whether feedback can be submitted from within the app also depends on group settings.[12]

Address reproducible issues first, then begin the next round:

1. Fix the issues, package the app with a new build number, and upload it.
2. Wait for processing and complete any required compliance steps.
3. Add the new build to the target group and complete any required external review.
4. Update What to Test and notify testers according to the settings.
5. Ask people in the target group to confirm the version and build they actually installed, then retry the original problem.

Upload records, group membership lists, and review approval all matter, but ultimately you must confirm that the intended audience actually installed the intended build.

A screenshot showing internal testing does not prove that every external user can install the app. Running in a simulator is also no substitute for an installation result on a device.

14. How Do You End Testing or Release on the App Store?

First decide what you want to stop:

• Stop recruiting new users: Disable the external group’s public link.
• Change who receives which builds: Manage testers, groups, and build assignments.
• Stop new installations of a build: Open the build’s details and choose Expire Build. Do not interpret this as remotely deleting the app from every phone or erasing cloud accounts.[6][13]
• Release officially: Prepare the information required for an App Store release, select an eligible build, and submit separately for release review.[1][2]

An eligible build already uploaded through ordinary TestFlight distribution can be selected for release review. You do not necessarily need to package it again solely because you want to release it. However, if the actual code changes, you must upload a new build, and Internal Only uploads cannot be used for an official release.[2][5]

Passing TestFlight App Review does not automatically publish the app on the App Store. Conversely, releasing on the App Store does not automatically end a still-valid beta. You need to plan the end of testing and the transition for users separately.[1]

15. A Message You Can Send to Your First Testers

I would love your help trying an early version of [app name].

First, install Apple’s official TestFlight app from the App Store. Then open [actual invitation link] on your iPhone, accept the invitation, and install the app.

This round, please focus on: [1 or 2 specific tasks]. Supported devices and operating systems: [actual requirements].

This is a beta and may have problems, so please back up important information first. If something goes wrong, use “Send Beta Feedback” in TestFlight to tell me what you did, what you expected, and what actually happened. A screenshot and version number would be especially helpful.

Replace the bracketed placeholders with real information. Send the message only after confirming that the build in the target external group can actually be installed. Do not send everyone a link that is still waiting for review while calling it available.

Before Sharing, Check These 10 Items

• □ I chose internal or external testing based on account permissions, without granting excessive access for convenience.
• □ The target build has finished processing, with no unresolved distribution blockers.
• □ The target group actually contains this build.
• □ Any required external review has passed, and any necessary notifications have been sent.
• □ I checked the invitation method: email invitations went to the right people; if using a public link, it is enabled and has space available. The target devices and operating systems meet the requirements.
• □ The beta description, feedback email, and What to Test are accurate and useful.
• □ Testers know this is a beta and that it may replace the released version.
• □ I have distinguished sandbox purchases from real servers, web payments, and real-world actions.
• □ I checked the build’s expiration date and planned follow-up updates.
• □ Someone in the intended audience confirmed they actually installed the intended build, rather than merely opening the invitation page.

When you share an app for the first time, “upload complete” is not the real finish line. It is when the right people have installed the right version, know what to test, and know how to tell you about problems.

Sources and Further Reading

The following materials were verified on September 17, 2026. Historical milestones use contemporary reporting or Apple announcements from the time; current rules rely primarily on Apple’s official help. Interfaces may vary by language and version.