Crashlytics and Firebase are usually installed with CocoaPods, but what if you were using Carthage as your dependency management system? Tutorial to the rescue! I’m going to explain this as simply as possible as it was a bit of a pain hunting all the info down so hopefully this can help you out :-]

Getting Started

Firstly assuming you have Firebase installed, go ahead and add the dependencies to your Cartfile:

binary ""
binary ""

Firebase and Crashlytics aren’t technically supported without using CocoaPods but it just requires a few steps so hang in there. You’ll need Fabric as well as Crashlytics to get this to work.

Go ahead and do a Carthage Update – note, this can take a while.

Once this is complete head to your project folder and inside the Carthage directory drag in the Fabric and Crashlytics Framework. You do this in the General tab inside Frameworks, Libraries & Embedded Content.

You’ll want to select Do Not Embed as we’re not worried about signing and linking before building the project. This way our dependencies will be linked at build time just fine.

Build Errors

Once your update finishes your project might not build (as mine did). This is due to the fact Firebase has changed significantly of late and promises are now used throughout.

If you navigate back to your Carthage build directory where the other SDKs are, you’ll notice a new PromisesObjc.Framework file there. This is what we’re missing! Just drag that in alongside the other two frameworks we just imported.

Initialising the Framework

Crashlytics, like Firebase, does a little bit of configuring as your app runs and before you get control in the AppDelegate. For this you’ll need to head to your Build Phases tab for your target and at the very end of your Build Phases add a new Run Script:

# Type a script or drag a script file from your workspace to insert its path.

This will find the fabric framework and it will use the Google Info.plist that you have setup for your target: this is useful if you’re using a dev, qa, uat and prod target setup for example. Pro tip, you can do that like this:

    /// Configures the app to use the correct plist for each environment
    private static func configureFirebase(for environment: BuildConfig.EnvironmentType) {
        let filePath = Bundle.main.path(forResource: plistName, ofType: "plist")
        guard let fileopts = FirebaseOptions(contentsOfFile: filePath!)
            else {
                assertionFailure("Couldn't load config file")
        FirebaseApp.configure(options: fileopts)


Crashlytics will respect this plist that you’re swapping and it will talk to that target on your Firebase console!

Getting Detailed Reports

Whenever you build an app its either built for debug or production. Each build, lets say version 1.0.1, has a unique ID associated with it and any crash report will tie in perfectly with that ID. The thing is crash reports aren’t super-helpful if you need to know which line, or which file the crash happened. For that you’ll need to enable debug symbols (symbols being the functions, variables etc unique to your code) in the Build Settings for your project in Xcode.

Head to Build Settings and make sure All is toggled to see all options. Type Debug Information Format and make sure DWARF with dSYM File is enabled for any build you want to monitor for detailed crashes.

View those Crashes

Next head to the Firebase console and then Crashlytics. You’ll be prompted to enable Crashlytics and it will ask you to crash your app to view it.

Once that’s listening for crashes head back to your AppDelegate and import the library and crash that baby!

import Crashlytics


 func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {


Follow these steps for a headache-free crash-reporting experience, trust me:

  • Build the production version of your app to a device
  • Detach the device from your machine
  • Run the app from the device and make sure it crashes
  • Attach it again and comment out your crash
  • Run the app once more to give it a chance to upload your crash
  • Wait 10 minutes or so and you’ll see your first crash in the Firebase console


Simple as that! All you did was add the library, make sure debug symbols were generated on a crash, upload the reports for each target and console environment on Firebase and make sure you forced a crash on an actual device.

If this helped you feel free to share it and have a crash-free day!


Author code-disciple

More posts by code-disciple

Leave a Reply