Keeping Apps in the Air With TestFlight

Long a development tool, TestFlightApp wants to move into analytics

For most iOS developers, TestFlightApp has become the go-to tool when they want to distribute a development build to testers. For those not familiar with the site, you can register applications, and then upload IPA files signed with either a development or AdHoc profile, either manually or using a desktop app that integrates directly into XCode.

Once uploaded, your testers can be automatically notified via email that there is a new version of the app available, and download it directly onto their device without having to use iTunes. It can even capture device IDs for new users (or new devices for existing users), and export them for use in the Apple developer portal.

You can also add code to have the running app check in with TestFlight. You can add “checkpoint” flags, ask survey questions (“why did you come to this page”), and have console logs and crash reports automatically uploaded to the site.

The problem is, once you’re ready to ship a production version, you have traditionally had to turn everything off and make sure that the Test Flight library was not linked in to the app. This has meant that there was no way to capture crash data from customers running the app. But now that’s changing.

Recently, TestFlightApp announced that it was now OK to leave the library in copies of your app uploaded to the App Store, and to have the app check in with TestFlight. Why the change? Probably because it is needed to support FlightPath, their new analytics tool. FlightPath seems to want to be the Google Analytics of mobile, allowing developers to see how customers use their app and offering demographic data.

FlightPath is likely to be the path that TestFlightApp takes to start monetizing their service. TestFlightApp has always been free, but there has been no pronouncement about whether FlightPath will follow that same model. It is currently in an open beta, so we may have to wait and see what the pricing model for the final product is. Of course, by then, all those beta users will have become hooked.

One major caution for people intending to keep TestFlight in their production code, watch out for leakage of private data! Many test builds spit out tons of information to the console. At times, I’ve had everything going back and forth to a server dumping itself onto the log. If you don’t disable that in the shipping code, you could be accidentally capturing all sorts of sensitive data, including credit cards, HIPPA restricted information, etc. So make sure that you have compiled out (or disabled) anything like that in the production build (which you can test with an AdHoc profile.)

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Programming
  • alexandra.kwc

    Everybody wants mobile apps for their businesses, but hiring experienced developers is too expensive and a hard task . There’s an online tool anyone can use to build apps really quickly and without programming skills, snappii.com.

  • Walt

    Hi,
    Last week we had our last tests with testflight. Everything went right so we decided to upload our last (tested) build to itunesconnect. yesterday it got approved so I put it on sale for today.
    This morning I’ve downloaden our App from the appstore and saw directly that there are o lot of wrong things in the App. Lists are not displaying correctly, content is not displaying correctly and more things.
    How can it be that one ipa, tested through testflight was allright but when we put it in itunes, it has errors??
    This is the second time already. How can I test if I have no idea what the App will look like if we put it in the itunes store?
    Anybody, my client goes crazy right now :(