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.
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:
Your accounts tab should now look something like this:
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:
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:
You’ll see a few different status messages in the toolbar and once complete, the Organizer window will appear.
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:
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.
Take a break, refill your drink and do half a dance, you’re about half way through the process.
While App Store Connect is processing your upload, let’s setup your testing team. Perform the following steps:
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.
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.
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:
You’ll now have a section of the page titled Testers (0).
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.
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.
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!
The easiest way for a tester to get access to the app is to:
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.
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.
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!
To learn more about our React Native process at Echobind, visit our React Native capabilities page.