TestFlight and the iOS Testing Workflow

Apple may be trying to teach us something about testing with the new TestFlight integration that quietly rolled out in September. For the greater part of iOS's life, testing has been a problem that was up to the developer to solve. Only recently, with Apple's acquisition of TestFlight and Twitter's acquisition of Crashlytics, has an more concrete workflow emerged.

Internal and external testers

You can now add up to 25 internal testers to your application. These testers can immediately receive a build once it's been uploaded to iTunes Connect. 25 is nothing though, you say. We could add 100 devices to the iOS Dev Center, you say. Enter external (beta) testers. You can now add up to ONE THOUSAND external testers. That's 1000 people to help you refine your app before you launch, or critique your design update before you tick off your existing user base.

There's a catch, though. All builds distributed to external testers must pass through an Apple review. While these reviews do not fall into the same queue as those submitted for App Store release, they can take time. For Scrimp, the first review took about 12 hours, with two reviews since then taking just a few minutes, each. What this means, though, is that you can't power through a three new features on Friday afternoon and expect to send it out to beta testers before peacing out for the weekend. And maybe that's a good thing.

Note: internal testers require iTunes Connect accounts, external testers just require an email and downloading the new TestFlight app.

 The new Prelease dashboard tab in iTunes Connect

The new Prelease dashboard tab in iTunes Connect

What Are You Suggesting, Apple?

The new workflow seems to suggest a pattern of sending frequent (daily?) development builds to an internal team -- perhaps developers, designers, QA engineers, product managers, etc. -- and more polished testing builds (i.e. those passing Apple's prerelease review) to the external team -- company executives, beta testers, grandma, etc. It also could mean the elimination of the putting the latest (aka buggiest) builds directly onto others' phones at random points throughout the day. Rather, quickly submit from Xcode and hit a button in iTunes Connect to distribute. Let Xcode and iTunes Connect manage the distribution and versioning for you.

It's clear that Apple has heard our concerns and is opening the doors WIDE OPEN in terms of beta testing apps. No more setting up people in the iOS member center for the sole purpose of installing a test version of the app. No more worrying about managing and deleting devices (actually, you still need to worry about it, but chances are tons of your 100 allotted devices are being used exclusively for test devices). No more need for an enterprise account in a lot of cases too. Everything is simplified. What you now get is the ability to easily test your app with as many people as most could want. We went from 100 testers PER DEV ACCOUNT to 1000 testers PER APP. Now that is awesome.

Now WHAT

That's up to you. If you've already got a system working with Crashlytics, HockeyApp, or even the old TestFlight web app you may not need to worry about it. On your next project though, I'd recommend trying the new Testflight integration. Apple puts extreme amounts of energy into product design, as we all know, and this is no exception. If nothing else, I find it interesting that Apple has structured the workflow this way. It's similar to environments I've been a part of and setup in the past, but now has the potential to establish itself as a community best practice.