A while ago, I wrote a complete review of @TestFlightApp, a web service allowing iOS developers to help them distribute adhoc builds of their apps for testing purposes (TestFlightApp - a complete review). That's kind of incomplete description of this wonderfully designed web service.
All of this will come under a new SDK on which I spent some time to test.
Who is really testing your ahdoc builds?
Sometimes you want to go out and ask for others to test your iOS apps for a specific feature or just to get general feedbacks. So you ask a bunch of people to submit their device's UDID in order to create an adhoc build for them. But, out of 20 or 30 beta testers, how many are really doing what you expect them to do? Before TestFlightApp's new SDK, you would judge this by the amount of feedback you were getting via emails. Now, with the new SDK, you'll see exactly who is really testing your apps, thanks to the new Sessions tab.
As you can see, you'll see who is the most active of your beta tester, total spent in your app, how many sessions, average time spent per session, etc. This is really useful to help manage your team of beta testers.
See application usage patterns with checkpoints
Now you can embed checkpoints within your app. After adding the TestFlightApp SDK to your project, simply add calls like this at strategic workflow points within your application:
[TestFlight passCheckpoint:@"CHECKPOINT_NAME"];This way, you'll be able to see usage patterns and eventually be able to identify user interaction problems. This is really cool. If you already use Flurry analytics library in your shipping apps, you'll see that this is really similar. What is cool here is the ability to see all your stuff in one place on the web while having complete control on the beta management process. Plus, TestFlightApp web site is way cooler than Flurry's. No doubt about this.
 |
| Checkpoints view |
As you will see in the next section, checkpoint are critical to the next SDK's feature: asking for user feedback.
Asking beta testers for direct feedback
The new SDK allows every developers to ask for direct feedback from within their application. This one is really cool. Let say you have designed a new welcome tutorial and you want the testers to give their impressions. To accomplish this, you have to have defined checkpoints in your application. Then, on the TestFlightApp management page, you assign a question to this checkpoint. The next time the user hit this specific checkpoint from within the app, the TestFlighApp SDK will bring up the question to the user.
 |
| You can ask for feedback with Yes or No answers |
 |
| Free form feedback can also be submitted |
On the backend, TestFlightApp let the developer see all the answers in a nice dashboard view.
Access to application's crash logs, easilyAs developers, we all know how tricky it is to get user's crash logs. But what if the whole process was automated from start to finish? This is exactly what the SDK does for you. If your application crashes while being tester, open the next restart, the integrated TestFlightApp SDK will try to recover the logs and send them to the web service. Completely symbolicated.
This alone is worth the small time it takes to integrate the SDK into your app (less than five minutes). This is so cool that I asked the support team if they would allow developers to include the SDK into shipping applications on the App Store. Their answer was very revealing: they are away of other developers who do just that. I think I will try that with one of my app to see how it goes.
 |
| XCode Project Settings required for crash reporting |
As a side note, the SDK is taking into account the network availability so if the network is missing, pending sessions, crash reports and the like are waiting for the next opportunity.
All in all, I really like how TestFlightApp is evolving. If you are not already registered with them, you should take the time to open an account (free!) and see for yourself.