TestFlight is a great service for managing and distributing beta versions of iOS apps. It also has an (optional) SDK which collects crash reports, and anonymous information about how your apps are being used.
TestFlight’s crash reporting is nowhere near as powerful or easy-to-use as Crashlytics, which is superb. While the two SDK’s can coexist peacefully, I prefer to have only one crash handler running in my apps to avoid any possibility of either stepping on the other’s toes.
Unfortunately TestFlight don’t provide a public API for disabling their crash reporting. Fortunately, a little reverse-engineering with the awesome Hopper disassembler led to the discovery of UninstallCrashHandlers, TestFlight’s private API for uninstalling crash handlers.
Disabling TestFlight’s crash reporting is quite simple. Add the following code near where you include the TestFlight header:
1 2 | |
When calling UninstallCrashHandlers, set the restore argument to YES to restore the POSIX signal handlers that TestFlight saved before installing its own; setting it to NO causes all signal handlers to be reset to NULL.
Update: Closer inspection reveals that the uncaught exception handler is only reset if restore is set to NO. So to fully restore all exception handlers (POSIX signal handlers and uncaught NSException’s), UninstallCrashHandlers must be called with the NO argument — this sets all signal handlers to NULL and restores the uncaught exception handler — and then called again with the YES argument, which restores the POSIX signal handlers.
I call UninstallCrashHandlers immediately after configuring TestFlight, and just before configuring Crashlytics. In my app delegate’s application:didFinishLaunchingWithOptions: method I have the following code:
1 2 3 4 5 6 7 8 9 10 11 12 | |
I have tested this with both the 1.1 and 1.2 versions of TestFlight’s SDK.
Updated 2013-01-01: Corrected to mention that UninstallCrashHandlers must be called twice to restore the uncaught exception handler as well.