Developers still using the old, independent TestFlight service for beta testing iOS apps now have one month to migrate to the new iTunes Connect-based offering, as the company announced on Monday that it would shutter TestFlightApp.com on Feb. 26.
The change comes almost exactly one year after Apple acquired TestFlight's parent company Burstly, and just over three months after the launch of an all-new TestFlight service integrated into iTunes Connect. The change was announced in a Monday email to TestFlight customers which was first noted by TheNextWeb.
According to the official migration FAQ, developers will not be able to directly transfer apps or beta testers from TestFlightApp.com to the new version. They will first need to configure the apps in iTunes Connect, then export testers' contact information from TestFlightApp.com before importing it to iTunes Connect.
Apple purchased Burstly in February of last year, with financial terms still unknown. At the time, some speculated that it may simply be a so-called "acqui-hire," but that was quickly quashed when TestFlight was spotted in iOS 8 betas.
Burstly's other offering, ad monetization service SkyRocket, was shuttered last summer.
13 Comments
This is sad. Testflightapp.com was much more useful to us for our internal testing than the Apple iTunes Connect version. We're using the iTunes version for some external testing, which works mostly well since you don't need to get the device IDs from everyone, but the overhead involved to run our internal testing, with app versions we never plan on releasing (same codebase, but different app IDs based on which database is being used, for example) makes it unwieldy. And for internal testing you have to add each tester as an iTunes Connect user. We don't get crash dumps from iTunes Connect Test Flight either, which is a big downer. All around a loss for the Apple development community.
[quote name="chadbag" url="/t/184508/apple-closing-independent-testflight-service-at-the-end-of-february#post_2666615"]This is sad. Testflightapp.com was much more useful to us for our internal testing than the Apple iTunes Connect version. We're using the iTunes version for some external testing, which works mostly well since you don't need to get the device IDs from everyone, but the overhead involved to run our internal testing, with app versions we never plan on releasing (same codebase, but different app IDs based on which database is being used, for example) makes it unwieldy. And for internal testing you have to add each tester as an iTunes Connect user. We don't get crash dumps from iTunes Connect Test Flight either, which is a big downer. All around a loss for the Apple development community.[/quote] That's funny, most developers love having TestFlight integrated. Not sure your opinion holds.
There are lot of advantages to the integrated one, and I am not saying the integration is not good. I am saying that the closing of the older one is a loss for the development community because you lose good capability. For one, I have seen no place where you get crash dumps in the new integrated one (at least with external testers -- we don't currently use it for internal testers as the overhead to set it up is too high). That is a LOSS. (You do get them for released apps, in some form or another, but not for unreleased apps in external test, or at least didn't, with no mention of it at all in the iTunes Connect support pages, when I last looked a week ago).
Two, you have to create an iTunes Connect app entry for every app, which is high overhead compared to the going-away version, where it was extremely low overhead. We have versions of our app that will never be released on iTunes, for which we have different appIDs, so that we can have multiple versions of the app on our devices at once, with customized settings, like which test database the app runs against, etc. The overhead to do this in iTunes Connect is much higher. Much more friction.
The new integrated one makes the external testing easier to set up, which is good. We currently use both forms of Test Flight since both have advantages.
Again, I am not complaining about the new integrated one, and I really doubt I am the only person lamenting the loss of the old Test Flight.
Doesn't this make testing older devices and firmware versions impossible? I can see apps having issues with iOS 7 and earlier when developers can't even test with them during the beta cycle because TestFlight won't support it.
I've also heard that Apple has to approve the beta that goes out to the testers, which adds to the testing time. I can't imagine developers are happy with this at all.
There are lot of advantages to the integrated one, and I am not saying the integration is not good. I am saying that the closing of the older one is a loss for the development community because you lose good capability. For one, I have seen no place where you get crash dumps in the new integrated one (at least with external testers -- we don't currently use it for internal testers as the overhead to set it up is too high). That is a LOSS. (You do get them for released apps, in some form or another, but not for unreleased apps in external test, or at least didn't, with no mention of it at all in the iTunes Connect support pages, when I last looked a week ago).
Two, you have to create an iTunes Connect app entry for every app, which is high overhead compared to the going-away version, where it was extremely low overhead. We have versions of our app that will never be released on iTunes, for which we have different appIDs, so that we can have multiple versions of the app on our devices at once, with customized settings, like which test database the app runs against, etc. The overhead to do this in iTunes Connect is much higher. Much more friction.
The new integrated one makes the external testing easier to set up, which is good. We currently use both forms of Test Flight since both have advantages.
Again, I am not complaining about the new integrated one, and I really doubt I am the only person lamenting the loss of the old Test Flight.
Okay, that works then. Thanks for the response.