A quick(ish) guide to Apple's Test Flight
Apple recently rolled out its new implementation of Test Flight. For users who are used to the previous version of Test Flight, the process may be a bit confusing. The new version of Test Flight, however, is meant to go more hand in hand with the existing app store submission process. Here is a quick guide:
1- In order to submit an app to test flight, you have to build it and submit it to the app store, as you would normally do for an app submission. This means that we need a distribution profile. If you aren’t familiar with the provisioning profile process, this can be rather conveluted and confusing. If you have an existing distribution profile you should be good to go. If you are using an existing one that someone else made, you probably need to create a new certificate and change the profile to use your certificate… you’ll know if this is the case because you’ll get an error saying that there is no signing identify found for your provisioning profile. I DO NOT recommend trying to use the xCode Auto provisioning stuff. In my experience, it never works and just messes up the existing profiles.
The basic steps for provisioning are: (from the “member center” provision portal at developer.apple.com/ios)
– create an app ID for your app
– create certificate or signing identiy for your specific computer.
– create a new distribution profile with the cert you created for the app id you selected.
– download the cert and the profile and ensure you app is set to release with the combination of them both and your app ID matches the app ID you selected. This is done the app target’s build settings in Xcode.
2- Now that you have your app configured with the correct app id and a valid signing identity and distribution profile, you can submit it to the app store.
The basic steps for submission are:
– create a new app version in itunesconnect (iTunesconnect.apple.com). To do this, go to your apps, if the app is not existing already, you need to create a new app and select the app bundle you created earlier. If the app is existing, just selected and select to “add a new app version”.
– Version your app. From xCode, ensure that your current version matches the version you entered in the step above. Your build version should generally match the version you set above, but each time you submit this will need to be unique, so if you are resubmitting a new build for the same app version, you will need to add a new subversion to the build version… so the second build of v1.0 may become v1.0.1
– Build your app. In xCode, go to Build -> Archive. It is generally a good idea to run a Build->Clean before you do this, but it may not really matter. If you hit a provisioning issue here, it is usually because your Release signing identity and the Release Provisioning profile to not match. See the provisioning steps above if you have issues.
– Once you have a valid archive, in XCode’s organizer, the archive will now show up. You can now submit this build to the app store. Find the Archive in Xcode’s Organizer -> Archives and press the big “Submit to the app store” button and submit it to the App Store. Again if you hit provisioning issues here, see above.
3- If you haven’t used test flight before, you probably need to add some new Test Flight test users. To do this, you just need to invite them to your iTunes connect team. You will need the users Apple ID email (the email for the account that they use to download apps from the app store.) Note, they don’t need an apple developer account. By adding them as an iTunes connect user, they will gain some access to your app sales statistics and can edit app meta data. If you don’t wish them to have this access, then you can add them as an external user, but your app must go through a short app store review process each time you want to send those users a build. No review is required for internal users and this provides the easiest method of distributing your app to testers.
To Invite Internal Users
– Go the iTunes connect Users and Roles Portal.
– Add a new iTunes connect user with the users’ apple id email. I recommend adding them as a marketing role, as this will give them the minimal access level necessary.
– Once the user accepts admission to your team, you can them go to the TestFlight beta testers tab.
4- Send your build to test flight users.
Now we need to tell iTunes connect that a specific version is ready for test.
– Go to your app in iTunes connect.
– Under your new app version, go to builds and find the new build you created. Select this build version. Note that if it shows as “processing” you need to wait a few minutes and check back. This can take up to a few hours, but usually takes about 10 minutes.
– Once the build is selected, go to the Test Flight tab and select the current app version to make it eligible to test.
– Add the iTunes Connect Internal users you’d like to add. You may also add external testers if you’d like, but if you do this, you’ll need to submit it for an external test review first to get Apple to approve it.
– Once you’ve added the test version and the test users, your app should be ready to go!
– Your users will receive an email with instructions on how to install the app. These instructions will have them download the Test Flight app from the app store and log in with their apple id. Once they do this, they’ll get push notifications when new builds are ready for test and they can install the new builds right from the app.
Aaaaand we’re done! So, in retrospect, test flight isn’t as easy as it used to be to quickly deliver builds to our clients… but once you get the feel for it and get everything set up, it is actually rather easy and quick and flows right along with our normal app submission flow. It also ensures a bit of safety since you know that the build you are releasing is the exact same build that has been tested by your users and coinsides closely with your iTunes connect team.