TestFlight & the App Store

This last section is a tour of App Store Connect and TestFlight, so you know what to expect when the time comes.

Making a New App

Relatively early in the process, you want to stake out some territory.

Just as your bundle ID must be unique worldwide, so must your app’s name. This is why you sometimes see such odd names in the App Store. Search for flashlight in the App Store on your phone. Look at all of the names of the search results.

If you’ve found the perfect name for your app, you should complete the New App form before another team takes it. After entering your great name, you choose the language. This is the human language the app uses, not the language the app is written in. Choose the default language if it’s set up to use multiple languages.

Then, you enter the bundle ID that matches the one you’ve used for your code. This is a drop-down of the bundle IDs your team has created. The SKU is an internal identifier for your team and shows up in reports. Your customers will never see it.

The final choice is User Access. This determines who on your team can actually see that this app exists and look at data about it.

The distribution page is where your team has to enter a lot of metadata about the app. This form needs screenshots, promotional text, links to your privacy policy, and more. You can also leave notes for the App Store review team.

For instance, if your app requires accounts, you must create an account for the App Store team and provide the credentials for them to use during review. A table of required and optional data is in the App Store Connect documentation. This is when you really want some teammates to help! Some properties are editable at any time, but others can only be changed when you submit a new version for approval.

The screenshots are perhaps the most time-consuming. You need at least three for each device size, and they must be a particular size. Thankfully, you don’t need to make three or more screenshots for every device size because Apple will scale up or down some of the sizes. But it’s still a lot.

Additionally, you must upload screenshots separately if you’re supporting Apple Watch and iPad. These are the images that accompany your app in the App Store. You can also provide the movie previews here.

In addition, if you’ve translated your app into different languages, you must enter much of the text for each language. You also have to make screenshots for every language.

However, once that’s done and you’ve chosen app categories and everything else, you don’t have to update most of the data frequently. Further down the form, you can specify which build you want to put in the store. These can either be builds you’ve promoted from TestFlight or builds you load directly for distribution.

Since this app is in the store, attempting to upload a new archive with a build number of 26 or a bundle version of 3.1.2 will cause an error.

New Version of an Existing App

For an app released to the store, the first step to uploading a new version is to create a new bundle version number. Then, new uploads require that bundle version number, and, of course, the build number always has to increase.

Once you’ve created a new version, the form for this new version will clear some of the fields and pull the data for some other fields forward. You’ll have the opportunity to add new screenshots. The What’s New in This Version field will clear. Also, any other fields that weren’t required when the app was last approved but are now required must be filled.

When the app is finally submitted and approved, you can choose when it goes live on the App Store. Some teams may want to coordinate the release with a marketing event, while others want the app available as soon as it’s approved.

TestFlight

You’ll also find the TestFlight distribution platform in App Store Connect. Using TestFlight, a team can distribute builds to members of the team and external users. Test devices using the app through TestFlight don’t count against the 100 device limit for Debugging and Ad Hoc builds. Also, the team isn’t required to collect UDID numbers in advance.

In the image above, build 16 is ready for testing by the internal testers. The group of testers for this app is called the Core Team. The team might have several different groups of testers for different apps.

Teams can have any names that are meaningful to them. For Internal Test groups, everyone must also be part of the development team. When a build gets uploaded, it’s given some light validation by Apple but is then ready for download by all testers.

As this app gets closer to release, the team will add external testers. Those people don’t have to be part of the development team. Builds uploaded for external testers are given more rigorous review, but not as much as builds for release in the App Store.

Though screenshots aren’t required for TestFlight builds, an app description, privacy policy, and license agreement are required. Additionally, a contact on the team for Apple App Review and any external testers is required. If an app is localized, this information needs to be filled in for each language.

In TestFlight, builds for internal testing usually finish the automated validation within a few minutes after upload. Builds for external testing can take up to a day before they become available.