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.
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.
- 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/