We’re excited to announce the release of App Tokens and our much improved SDK v1.2. Thanks to all of you who took the time to check out Apps in Area51 and test drive the updated SDK and App Tokens. Your feedback is much appreciated.
Reorganizing TestFlight around Apps allows us to bring you improved SDK reporting and performance. There are a few small changes in how you’ll be interacting with your builds.
App View
You’ll notice that all your builds will be grouped into apps by their bundle identifier. Click a row in the new Apps view to view all your builds associated with the app. This gives you a dedicated URL for all the builds associated with that app. Your latest build will still be accessible from your app list by clicking the build number in the ‘Latest Build’ column.
Old Builds View
New Apps View
Dedicated Build List View
You’ll also notice that Team Tokens have been deprecated and replaced with App Tokens.
Why the switch to App Token? We began to notice that over time, many of you were building up quite a large list of build version and sub-versions of your apps. TestFlight Live brought about new challenges that forced us to make decisions on which build data belonged with which application. App Tokens would give our developers more control over which data goes into which application, more accurate reporting, and overall improved performance. Learn more.
Finding your App Token
You can find the App Token by clicking on an app and then selecting App Token from the left navigation. If you haven’t uploaded a build yet you can create an app by clicking the + in the top-right of the global header and choose ‘Create Application’.
The App Token page will give you details on how to implement the new App Token in the SDK. Click ‘SDK Debugger’ in the left navigation to ensure that your token is properly implemented. You will not lose any data by switching to App Tokens.
SDK v1.2
App Tokens must be used with the SDK v1.2.
- Added application token support
- Removed Team Token support. As of version 1.2 -takeOff: must be called with the App Token. Go to https://testflightapp.com/dashboard/applications/, choose your application, and select App Token in the left navigation to get the App Token for the application
- Removed support for armv6
- Exception handler now returns instead of raising a SIGTRAP
- Resolved an instance of close_file being called on a bad file descriptor
Read SDK v1.2 Documentation
SDK v1.2.4 beta
SDK v1.2.4 beta is available with several bug fixes and updated documentation. In addition, the SDK v1.2.4 beta is now using NSString constants for setOptions: method to make sure typos are no longer a problem.
Bug Fixes
- Fixed bug that caused crash reports to sometimes not send immediately (they would be resent later)
- Fixed bug where logs were not sent on crash
- Fixed bug where empty crash files were created (but not sent)
- Remove potentially conflicting function name UIColorFromRGB
- Fixed crash on bad in app update data
- Max number of concurrent network connections has been reduced from 4 to 2
Read SDK v1.2.4 Documentation
Some of you may not be aware of our SDK Debugger. The Testflight SDK debugger allows you to see your SDK events before they hit our processing queues. Use the SDK Debugger to diagnose whether or not you’ve correctly implemented the SDK and monitor events that are being sent with your SDK Team Token across all of your applications.
You can find it by selecting a team in your team dropdown then clicking “SDK Debugger”.
Implement the SDK and watch the events populate the debugger.
The SDK debugger has been updated to improve performance and now quickly loads all events up to present time.
Additional Fixes:
- ‘Clear’ button removes all events up to the present and refreshing the page will no longer bring them back into view
- New events now appear even if the stored maximum (currently 200) is reached
Find this valuable? Have any suggestions? Contact us
The TestFlight SDK was responsible for symbolicating system libraries on the device prior to crashes hitting our system. As of iOS 5.1.1 this was no longer possible, resulting in <redacted> symbols appearing in our normally top notch crash reports. After some work we have been able to bring the iOS system libraries to our symbolization cluster and the number of <redacted> symbols has been drastically decreased.
Getting flooded with notifications?
We’re here to help! As the developer community scrambles to adjust to iOS 6, we’ve had to make some changes here at TestFlight as well. Here’s a few tips to help your testers get over pesky hurdles and get your SDK up to date.
Device re-registration fixes for iOS5 and iOS6
We’ve seen some errors surface with device re-registration due to our SSL certificate update changing from www.testflightapp.com to a wildcard cert *.testflightapp.com. These steps will help get problematic devices back to testing in no time:
- Remove the TestFlight webclip profile (settings>general>profiles)
- Clear the cookies and cache
- Restart Device
- Login to https://testflightapp.com/dashboard/ on Mobile Safari.
- Touch register and complete the registration process.
For more information, read our related support article
Get iOS 6 compliant! SDK 1.1
Now armed with armv7s and iOS 6 support! Download TestFlight SDK 1.1 and get better control of your tester feedback, log customization, and more. Don’t have our SDK implemented yet? Check out our documentation here.
Download TestFlight SDK 1.1 Now
Desktop App Updates
We’ve just released Desktop App Version 1.01 (294) to accommodate iOS 6. This fixes variable exports related to Apple’s new codesign_allocate tool and SDK not found errors. Update to the latest version now!
We are introducing production SDK rate limiting in an effort to address stability across TestFlight. Our goal is to give ourselves a little air cover while we work to improve overall scalability.
This will not have any impact on your application or your users. If your app starts to skyrocket on the charts, you can simply request a rate limit increase from the notification area.
When SDK traffic hits the TestFlight servers we detect if the traffic was from a production application or a beta application. In the event that your production traffic crosses a particular threshold TestFlight will stop processing the inbound data. The initial SDK always included this functionality, but up until now it was only used to remotely disable the SDK upon developer request.
The limits themselves are dynamic based on how you currently use the service. An example, TestFlight Live users have higher limits than non TestFlight Live users. We tried our best to implement limits that would have the least impact on the current level of use.
This is one step we are taking to ensure TestFlight can continue to grow without having a negative effect on our users and your users. Again, our goal is to provide a little air cover since we are hard at work improving stability throughout the entire site. We appreciate your understanding and we look forward to lifting the rate limit soon. If you have any questions or concerns please let us know.
Thanks,
TestFlight Crew
By now you’re probably aware that Apple has started to reject applications that access the UDID. The only reason that the TestFlight SDK accesses the UDID is to provide the best possible information about your testers. When we made the decision to provide a single SDK for beta testing and production applications we did so because we want your beta and release builds to have as close to the same code base as possible. Now that the UDID is no longer allowed in production applications we will still continue to use a single SDK for both Beta testing and Live releases.
In order to accomplish the goal of a single SDK for all release types we have introduced a new method into the SDK, +setDeviceIdentifier:(NSString)deviceIdentifier. This method is always optional and never needs to be set. However, we feel that during beta testing most of you would like to see which members of your team have seen and tested which parts of your applications. To enable that we allow you to use the +setDeviceIdentifier:(NSString)deviceIdentifier method to set the device unique identifier. We recommend that when you choose to set +setDeviceIdentifier:(NSString)deviceIdentifier to the current device’s unique identifier that you wrap the method in a preprocessor directive that only enables the call when you are building for ad-hoc release.
For further information and code samples please see our online documentation. If you decide that you do not wish to set +setDeviceIdentifier:(NSString)deviceIdentifier, we will still collect all of the usage statistics that you are used to seeing but the data may be anonymized.
Following our SDK release schedule we have released TestFlight SDK 1.0 BETA 1. As mentioned this new version of the SDK no longer accesses the device unique identifier and as such is App Store safe. Following our SDK release schedule we forsee that this version will be bumped up to full release status no later than March 30, 2012. When SDK 1.0 BETA becomes the official release we will begin deprecating all previous SDK releases.
As of May 31, 2012 we will no longer accept uploaded builds that contain an SDK version lower than 1.0. We will continue to accept data from previous versions of the SDK indefinitely.
TestFlight SDK 0.8 is live!
The TestFlight team has been hard at work trying to bring you an updated SDK. We’re happy to say it’s arrived! Here are a few of the highlights.
Signal Safe Crash Reporting
The main focus of the 0.8 update to the SDK was our crash reporting mechanisms. Our uncaught exception and signal handling has gone through extensive improvements since the 0.7 release. Part of this effort was removing any Objective-C and non-signal safe code from the crash reporting functionality of our SDK. Our users have also helped us identify that we were missing the SIGTRAP signal in our signal handler which has been added. The other changes involve using a signal safe implementation of MessagePack that allows us to save all of your data safely to files as we gather the crash report. This means that if, for any reason during the signal or exception, there is an interruption the data that we have gathered thus far is safe and will be transmitted on the next launch of the application.
Realtime Crash Reports
We feel that having crash reports being reported as they occur is extremely important. In order to maintain this it requires that we run some potentially less signal safe code in our crash reporting mechanisms. Initially we were using the same asynchronous networking code that we use in the main part of the library. This is Objective-C based and we feel that it is an extremely effective networking solution and we will continue to use it in the main portion of our SDK. However, it has the potential to allow the rest of the application to continue running during a signal which could lead to corruption of data. We now use an entirely C-based approach to networking while sending crash reports. If, for any reason, we are unable to send the report we will send it the next time that the application is launched with an active connection to the network.
Stack Trace Improvements
In some circumstances we noticed that the stack trace for exceptions was incorrect. This was caused by obtaining the stack trace from inside the NSUncaughtExceptionHandler. This method, which used to work correctly, no longer works as of iOS 5. We now use the call stack provided by NSException which, during our testing, accurately reports the call stack from iOS 3 to iOS 5.
iOS 3 Support
One issue a few people have pointed out was that we did not handle iOS 3 very well. We are happy to say that we have resolved any issues with and now support our full feature set with iOS 3. While this does not affect all of our users, it is important to us to provide you with the tools to fully test your products across all devices and OS versions.
Remote NSLogs
We have tried hard to maintain our current feature set while implementing our improved crash reporting, but there were a couple of features that did not make the cut for version 0.8. The first of which is capturing NSLogs during a crash. We currently get your NSLogs from the Apple System Log, which is very slow and not signal safe. We are aware that capturing NSLogs are especially important during a crash and we will be bringing back a way to obtain the log during a crash. The other feature we have removed during this process is crash logs from the iOS Simulator. We feel that, while the Simulator is a useful tool, it is used with Xcode most of the time and it is less useful to record the exceptions from the Simulator inside of TestFlight.
Future Improvements:
- A new logging system. We no longer feel that NSLogs are the best way to record logging information going forward. They have been useful in showing us that our users really like the ability to have their logging statements sent to them remotely. We are working to provide a way to do this without any negative impact to your application.
- Low memory exit recording. We currently do not report anything when a low memory exit occurs. This type of exit is just as important to our users as crash reporting and we will be addressing this in upcoming versions.
You can grab the updated TestFlight SDK at https://testflightapp.com/sdk/
