How To Get Your iOS App Into TestFlight and Test It

You’ve been working hard on your iOS app and you have the next App Store Editor’s Pick ready or at least some major features built and you’d like to get a second or another ten pairs of eyes on it for feedback, testing, and to make sure you’re not the only person who finds it useful. If you’re going to make Editor’s Pick, after all, broad usefulness is key! You’re new to Xcode though and you’ve heard horror stories about certificates, keys, provisioning profiles, and just how Xcode can be so daunting on its own. In the old days, before Apple added the Automatically Manage Signing option to Xcode, it was definitely more work and I followed my fair share of tutorials to understand the process.

With TestFlight, Apple offers testing for two types of groups, internal and external. This article focuses on your internal group, which would likely be the first group to test your app. Internal testers should be people you know since you are actually adding them to your App Store account. External testers will be people from the public you solicit to test, but may not necessarily know. They’ll be added to a different group and will not have access to your App Store account, just the app through TestFlight. Also external testing requires a limited review by Apple before you can publish to that group, internal testing requires no review. Finally, internal is limited to 100 testers, while external can be up to 10,000 testers.

Even though the process is much easier, it still requires many steps and you may still hit a few speed bumps along the way. With this article, I’ll lay out step by step how to get your new app out of Xcode and into AppStoreConnect for internal testing. I’ve included screenshots and descriptions for pretty much every step so you’re not left wondering what comes next, at any point.

Finally, this article is focused on iOS native development with Xcode. At Echobind, we also build mobile apps using React Native. With React Native, you’re able to build an app once, in JavaScript or TypeScript and then publish to both Apple’s App Store and Google’s Play Store. React Native also gives you the ability to bridge over to Swift for complex functions needing to get closer to the device’s hardware.

1. Developer Account

The most foundational step to getting into TestFlight is your Apple developer account. If you don’t already have an account, go to https://developer.apple.com and sign up. Go ahead, I’ll wait here.

A quick note about Apple Developer accounts. It will cost you $100 US per year. In my mind, this is completely worth it. First, Apple provides for free an outstanding IDE in Xcode, most developers barely even scratch the surface of its capabilities. Second, they provide a platform to distribute and sell your apps, marketing within the store for the best apps, read good quality and useful apps and not those who paid to be upfront. Finally, they provide plenty of reports and data to help you manage your app development business. Oh yeah, also a robust testing platform in TestFlight!

Ok, developer account in hand, now where to put it. Follow these steps:

• Open Xcode preferences by clicking on the Xcode menu in the top left and click Preferences or simply press ⌘, (command + comma).
• Click on the second tab, Accounts
• Click the + (plus) button in the bottom left

• Select Apple ID
• Click Continue
• Enter the Apple ID and Password for your Apple Developer account
• Click Next

Your accounts tab should now look something like this:

2. Set your version and build number

Every archive uploaded to the App Store needs a unique version and build number combination. My practice is to only change the version when I’m doing an actual, production release to the public. Between each production release though, I might upload many updates to TestFlight and those are tracked with build numbers.

Xcode starts you with version 1.0 and build 1. These are perfectly acceptable, although I add a bit more information to my build number. I set the build number to the date I uploaded it, in this format: YYYYMMDD plus an increment in case I upload more than one build per day. If I uploaded one today, my first upload would have a build number of 2022011801, I’d then increment the ending 01 portion if I uploaded any more builds today, then tomorrow, reset back to 01.

For version, there are many schemes used to version software, the most popular being Semantic Versioning or SemVer. SemVer uses three components in the version number, Major.Minor.Patch. Your first release could be 1.0.0 and then your next version after fixing a bug could be 1.0.1. If you add a new, useful feature, you might set your version to 1.1.0 and so on. Here at EchoBind, we also follow the SemVer standard. For your first release, I recommend setting it to 1.0.0.

You can set the version and build numbers within the Targets settings, General tab:

3. Create an Archive

Now that your developer account is setup and your build number and version are in place, you can upload to the App Store. The next major step is to create an Archive of your app to be uploaded, do this by following these steps:

• In the toolbar, where you normally select your real device or a simulator, either select a real device or select: Any iOS Device (arm64). If you have a simulator selected, you can’t archive.

• Click Product at the top, to open the Product menu


• Click Archive (if Archive is grayed out, make sure you don’t have a simulator selected in the toolbar)

You’ll see a few different status messages in the toolbar and once complete, the Organizer window will appear.

4. Distribute App

In the Organizer main list of Archives, you’ll see the archive you just created. The date should be today’s date and the Version column should show the version number and build number in parentheses. Select that archive and click the Distribute App button.

For the next set of screens, I almost always go with the defaults. As you build more advanced apps or integrate different CI/CD methods, these might change. For your first upload though, the defaults should work fine. We’ll show each screen below with the default selected:

• For Select a method of distribution, select App Store Connect and click Next

• For Select a destination, select Upload and click Next

• For Preparing app record, you will only see this screen the very first time you’re uploading your build. Everything on this screen should be what you selected when you first created your app in Xcode. If everything looks correct, click Next.

• For App Store Connect distribution options, leave the three options checked and click Next

• For Re-sign “your_app_name_here”, select Automatically manage signing and click Next

• For Review your_app_name_here.ipa content, have a brief look and make sure something doesn’t stand out as weird or look completely wrong. If you took the defaults, everything here should be fine, it’s ok if you don’t yet know what some of this is. If nothing looks terribly out of place, click Upload.

Several messages will be displayed and this process will run for several seconds. If everything went well, you’ll be presented with a nice, big, green check mark.

• Click Done to close this window and you can also close the Organizer window.

Take a break, refill your drink and do half a dance, you’re about half way through the process.

5. App Store Connect, Users

While App Store Connect is processing your upload, let’s setup your testing team. Perform the following steps:

• Open your browser and go to http://appstoreconnect.apple.com
• Login with the account you created earlier
• Click Users and Access

• Click the blue + (plus) button at the top of the list

• Enter your tester’s First Name, Last Name and Email
• Check Developer to give them enough access to download and test your app
• Under Apps, either select the specific app you want this user to test or select All Apps so they can test any apps you upload.
• For the Additional Resources section, I usually leave those blank.
• Click Invite

Your tester will receive an email invite they’ll need to respond to before you can assign them in TestFlight.

Repeat the above steps for any other testers you need to setup.

6. TestFlight Test Team

If you’re still on the Users and Access screen, click App Store Connect in the top left, then click My Apps.

Your new app should be listed on the next screen with the weird, wireframe logo, we’ll fix that too.

• Click on your app and then click TestFlight tab

If your build is not displayed, it is processing in the background and may take some time to show up. You will receive an email once your build is processed and at that point your build should appear.

In the meantime, let’s setup your test team. Perform the following steps:

• Still in the TestFlight tab, click the blue + (plus) next to Internal Testing
• In the Create New Internal Group window, give your test team a name. I recommend leaving Enable automatic distribution checked, that way your test team will be automatically emailed as soon as you release a new build for testing.

You’ll now have a section of the page titled Testers (0).

• Click the blue + (plus) next to that title and select from your list of testers.

• Click Add and you’ll be returned to the TestFlight screen with your selected testers displayed.

NOTE: Testers must accept the initial invite before they can be added here. Once you add them here, they’ll receive another email inviting them to test the app. Testers must then install the TestFlight app on the device that is assigned to the email they gave you for their testing account.

7. TestFlight, finally!

If you’ve made it this far, give yourself a pat on the back, I promise this gets easier after you’ve done it a few times.

Once you’re logged into App Store Connect, click on your app and then click on TestFlight.

Your processed build will appear under the Version you set before creating the archive, Version 1.0 in my case. In the Status column, it should say ⚠️ Missing Compliance Manage.

• Click Manage

This next section you’ll have to answer for yourself, because it’s dependent on how you coded your app. My app doesn’t use any encryption or make calls to an https domain, so I’m selecting No.

If you select No here, the button Start Internal Testing will turn blue. Click that button and voilà, you’ve made it! The testers you setup previously should now be receiving emails, inviting them to accept and start testing your app.

If you selected Yes above, you’ll have a few more screens to review. Read through them carefully, they’re mostly self-explanatory. Apple provides some good guidance here for export compliance. Also, if you’re based in the US, you can review the US Department of Commerce information here, concerning software exports outside of the US. Once you get to the last screen, you’ll have the blue Start Internal Testing button. Click that and your testers will be notified!

8. Testing

The easiest way for a tester to get access to the app is to:

• Install TestFlight from the App Store
• Open their email on the device and look for the app invite email
• Tap on the highlighted TestFlight word in their email and TestFlight should open, giving the tester the option to install your app.

9. Bonus, fix the wireframe icon

Until you submit your app for review, you won’t have a reason to choose a build for submission, but this is actually the step that also adds your icon throughout App Store Connect. You’ll choose a newer build once you’re ready to submit to the App Store, but in the meantime, this will just make things look nicer.

• Click on the App Store tab at the top and scroll down to Build
• Click the Select a build before you submit your app button and choose any recent build that already has your icon.

The Build section should then look like this. It might take a few minutes to show up everywhere, logging out and back in should do the trick if your icon is still not showing up.

Summary

Good testing makes for a good app and a good experience for your users. Take the time in your app development process to test thoroughly and solicit testing help from others. If you’re looking for internal testers, hit up your friends, family and coworkers. Once you’re ready for external testing, post across social media or look for established online groups that your app would target and ask for help within their forums. Most people are excited to be an early tester of a new app and are happy to report bugs and give feedback.

The process outlined above will get a long way down your development path. At some point, once your app grows or you’re producing multiple apps, you may want to implement a full Continuous Integration / Continuous Deployment scheme to automate the above process. Here at Echobind, we’ve established an automated build process to save time, reduce errors and deploy changes faster (more about that on our React Native capabilities page).

If this tutorial helped you or if you get stuck anywhere in this process, post in the comments below and I’ll try to help out. If you get an error along the way, search for the error online, in all the usual places, and you’ll likely find the answer, that’s how I’ve gotten this far myself!

Thank you for taking the time to read through this, I hope it helps you as much as the earlier tutorials helped me!

Learn more about our React Native capabilities.