Firebase Crashlytics - Are They Having a Laugh?
Crash reporting is an important part of app development, you don’t want your app to crash on users, so when it does it’s important to know when and why and be able to fix the issue.
I was a beta tester for Crashlytics back in 2012, exchanging emails with Wayne Chang, one of the founders:
We exchanged feedback for a few months as they rolled out the SDK and the Mac app.
I like to think I was, in part, responsible for getting rid of the awful zipper thing they had on early versions of the crash report Web page:
I think Twitter bought them, then in January 2017, Crashlytics and Fabric were acquired by Google.
In September 2018 Google announced that Fabric will be deprecated and developers should use Crashlytics via Firebase.
They’re a little late on their roadmap (by a year or so), but finally, this week:
Developers have until November 15th 2020 for migrate to Firebase Crashlytics, or, another crash reporter.
The current Fabric/Crashlytics SDK still works, you just have to go to the Firebase console to see the crash report. I currently have one outstanding crash in an old version, due to heap corruption. Here’s an example of some of the data you can get:
Anyway, to the point of this post. The migration guide says to simply switch your Pods, add the plist and change the way you initiate the shared Crashlytics object:
# Add the pod for Firebase Crashlytics
pod 'Firebase/Crashlytics'
But check out what else it installs:
james@Jamess-iMac: ~/Projects/iPhone Apps/HKWarnings on fb[!$]
$ pod install --no-repo-update
Analyzing dependencies
Downloading dependencies
Installing Firebase (6.24.0)
Installing FirebaseAnalyticsInterop (1.5.0)
Installing FirebaseCore (6.7.0)
Installing FirebaseCoreDiagnostics (1.3.0)
Installing FirebaseCoreDiagnosticsInterop (1.2.0)
Installing FirebaseCrashlytics (4.1.0)
Installing FirebaseInstallations (1.2.0)
Installing GoogleDataTransport (6.1.0)
Installing GoogleDataTransportCCTSupport (3.1.0)
Installing GoogleUtilities 6.6.0
Removing Crashlytics
Removing Fabric
Generating Pods project
Integrating client project
Pod installation complete! There are 23 dependencies from the Podfile and 38 total pods installed.
Extra pods installed:
- Firebase/CoreOnly (6.24.0):
- FirebaseCore (= 6.7.0)
- Firebase/Crashlytics (6.24.0):
- Firebase/CoreOnly
- FirebaseCrashlytics (~> 4.1.0)
- FirebaseAnalyticsInterop (1.5.0)
- FirebaseCore (6.7.0):
- FirebaseCoreDiagnostics (~> 1.3)
- FirebaseCoreDiagnosticsInterop (~> 1.2)
- GoogleUtilities/Environment (~> 6.5)
- GoogleUtilities/Logger (~> 6.5)
- FirebaseCoreDiagnostics (1.3.0):
- FirebaseCoreDiagnosticsInterop (~> 1.2)
- GoogleDataTransportCCTSupport (~> 3.1)
- GoogleUtilities/Environment (~> 6.5)
- GoogleUtilities/Logger (~> 6.5)
- nanopb (~> 1.30905.0)
- FirebaseCoreDiagnosticsInterop (1.2.0)
- FirebaseCrashlytics (4.1.0):
- FirebaseAnalyticsInterop (~> 1.2)
- FirebaseCore (~> 6.6)
- FirebaseInstallations (~> 1.1)
- GoogleDataTransport (~> 6.1)
- GoogleDataTransportCCTSupport (~> 3.1)
- nanopb (~> 1.30905.0)
- PromisesObjC (~> 1.2)
- FirebaseInstallations (1.2.0):
- FirebaseCore (~> 6.6)
- GoogleUtilities/Environment (~> 6.6)
- GoogleUtilities/UserDefaults (~> 6.6)
- PromisesObjC (~> 1.2)
- GoogleDataTransport (6.1.0)
- GoogleDataTransportCCTSupport (3.1.0):
- GoogleDataTransport (~> 6.1)
- nanopb (~> 1.30905.0)
- GoogleUtilities/UserDefaults (6.6.0):
- GoogleUtilities/Logger
665 extra files, 3MB, Xcode build tasks go from 740 to 1600.
Build time goes from 43 to 70 seconds, 60% longer.
What are all those files doing?!
You can check out the full Firebase platform on GitHub.
Anyway, I’m not very keen, but I’ll give it a go. You can see how many iterations of the SDKs I’ve been through by the commented code:
@try {
//[Crashlytics startWithAPIKey:kCrashlyticsKey];
//[[Fabric sharedSDK] setDebug: FABRIC_DEBUG];
//[Fabric with:@[CrashlyticsKit]];
//[[Fabric with:@[[Crashlytics class]]] setDebug:FABRIC_DEBUG];
[FIRApp configure];
}
@catch (NSException *exception) {
NSLog(@"[FIRApp configure]; Caught %@: %@", [exception name], [exception reason]);
startedCrashlytics = NO;
}
Verbose logging from the SDK. It’s doing a lot, including downloading settings and logging each screen (even though it does nothing with it as I didn’t install Firebase Analytics).
Build artifacts and app sizes:
1MB or so larger binary and dSYM.
There’s just too much going on that isn’t clear or documented. I’m going to have to look for alternatives.
- Bugsnag - free for up to 7500 events.
- Countly - looks good, open source, free and self-hosted.
- Sentry - Uses Pod frameworks or Carthage, and a 16MB framework…🧐
I think I’ll check out Countly first.