Quickly: Crashlytics helps manage crashes and issues with builds in a pretty UI, and while some of this functionality exists in GA, this is considered the main crash reporting tool for Firebase.
Let’s jump in.
Things To Gather
- A good text editor. I use Sublime Text, but you can use Brackets, XCode, or even TextEdit if you like.
- A terminal/emulator. I use the native Terminal.app
- The Firebase branch of the sample app from our last post (or your own app) plus your own
This one is going to be super quick. Let’s open the podfile again.
And add the pod.
And, let’s build and install!
Remember to open up the .xcworkspace file in Xcode and let’s finish the fight.
This is a bit tricky, but with screenshots I hope I can clear it up a bit. We need to add a new Run Script to the build phase of the your app (all that jazz that happens when you build and run your current scheme).
Add a New Run Script Phase, and include these two Input Files
“What does this do?”
Basically, the signature of your app/dsym changes every time you modify the build and these scripts will compile it and send it to Firebase automagically so you won’t have to keep current…
Lastly, just import Crashlytics to your controllers using
import FirebaseCrashlytics and you should be up and running! If you want to ever debug/simulate a crash, simply add
fatalError() in your
viewWillAppear or other class to cause a crash.
That was pretty easy and straightforward, except for the Run Scripts. That took me a while to figure out.
One big call out I found is (and maybe its an edge case for just me) when I deleted my sample app, I seem to have lost the .dsym link to Crashlytics and can’t figure out how to relink so I can see crashes again. Any thoughts?
A/B Testing In-App Messaging!
Changed my mind on going straight to AB Testing since that is going to require some changes to the app (we need something to test against!) so I just skipped to In-App Messaging.