Quickstart-ios: The default FirebaseApp instance must be configured before the defaultFirebaseApp instance can be initialized

Created on 18 Mar 2020  路  25Comments  路  Source: firebase/quickstart-ios

I am trying to configure the Firebase using FirebaseApp.configure() but facing the following crash:

 *** Terminating app due to uncaught exception 'com.firebase.installations', reason: 'The default FirebaseApp instance must be configured before the defaultFirebaseApp instance can be initialized. One way to ensure that is to call `[FIRApp configure];` (`FirebaseApp.configure()` in Swift) in the App Delegate's `application:didFinishLaunchingWithOptions:` (`application(_:didFinishLaunchingWithOptions:)` in Swift).'
*** First throw call stack:
(0x195b7180c 0x195899fa4 0x195a66f84 0x1081413dc 0x107c59bc0 0x107c59aec 0x10274daa0 0x10274d5c0 0x10274c8ec 0x10274c310 0x10274c25c 0x10244b52c 0x10244b434 0x10244b5c4 0x199bda698 0x102451ad4 0x195974360)
libc++abi.dylib: terminating with uncaught exception of type NSException

I tried calling FirebaseApp.configure() from inside didFinishLaunchingWithOptions and inside the init of AppDelegate as well:

override init() {
        super.init()

        // Setting up the firebase instance
        setupFirebase()
    }

private func setupFirebase() {

        FirebaseApp.configure()

        Messaging.messaging().delegate = self    
    }

It's crashing at this point -
Screenshot 2020-03-18 at 8 10 39 PM

I am using import FirebaseCore & import FirebaseMessaging inside my AppDelegate

The Podfile.lock looks like this

Firebase/Core (6.20.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 6.3.1)
  - Firebase/CoreOnly (6.20.0):
    - FirebaseCore (= 6.6.4)
  - Firebase/Database (6.20.0):
    - Firebase/CoreOnly
    - FirebaseDatabase (~> 6.1.4)
  - Firebase/Firestore (6.20.0):
    - Firebase/CoreOnly
    - FirebaseFirestore (~> 1.11.2)
  - Firebase/Messaging (6.20.0):
    - Firebase/CoreOnly
    - FirebaseMessaging (~> 4.3.0)
  - FirebaseAnalytics (6.3.1):
    - FirebaseCore (~> 6.6)
    - FirebaseInstallations (~> 1.1)
    - GoogleAppMeasurement (= 6.3.1)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GoogleUtilities/Network (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - nanopb (= 0.3.9011)
  - FirebaseAnalyticsInterop (1.5.0)
  - FirebaseAuthInterop (1.1.0)
  - FirebaseCore (6.6.4):
    - FirebaseCoreDiagnostics (~> 1.2)
    - FirebaseCoreDiagnosticsInterop (~> 1.2)
    - GoogleUtilities/Environment (~> 6.5)
    - GoogleUtilities/Logger (~> 6.5)
  - FirebaseCoreDiagnostics (1.2.2):
    - FirebaseCoreDiagnosticsInterop (~> 1.2)
    - GoogleDataTransportCCTSupport (~> 2.0)
    - GoogleUtilities/Environment (~> 6.5)
    - GoogleUtilities/Logger (~> 6.5)
    - nanopb (~> 0.3.901)
  - FirebaseCoreDiagnosticsInterop (1.2.0)
  - FirebaseDatabase (6.1.4):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 6.0)
    - leveldb-library (~> 1.22)
  - FirebaseFirestore (1.11.2):
    - abseil/algorithm (= 0.20190808)
    - abseil/base (= 0.20190808)
    - abseil/memory (= 0.20190808)
    - abseil/meta (= 0.20190808)
    - abseil/strings/strings (= 0.20190808)
    - abseil/time (= 0.20190808)
    - abseil/types (= 0.20190808)
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 6.2)
    - "gRPC-C++ (= 0.0.9)"
    - leveldb-library (~> 1.22)
    - nanopb (~> 0.3.901)
  - FirebaseInstallations (1.1.0):
    - FirebaseCore (~> 6.6)
    - GoogleUtilities/UserDefaults (~> 6.5)
    - PromisesObjC (~> 1.2)
  - FirebaseInstanceID (4.3.2):
    - FirebaseCore (~> 6.6)
    - FirebaseInstallations (~> 1.0)
    - GoogleUtilities/Environment (~> 6.5)
    - GoogleUtilities/UserDefaults (~> 6.5)
  - FirebaseMessaging (4.3.0):
    - FirebaseAnalyticsInterop (~> 1.5)
    - FirebaseCore (~> 6.6)
    - FirebaseInstanceID (~> 4.3)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.5)
    - GoogleUtilities/Environment (~> 6.5)
    - GoogleUtilities/Reachability (~> 6.5)
    - GoogleUtilities/UserDefaults (~> 6.5)
    - Protobuf (>= 3.9.2, ~> 3.9)

Here's what the stack trace looks like:

 thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x0000000195969ec4 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000195885774 libsystem_pthread.dylib`pthread_kill$VARIANT$mp + 112
    frame #2: 0x00000001957d9844 libsystem_c.dylib`abort + 100
    frame #3: 0x00000001959327d4 libc++abi.dylib`abort_message + 128
    frame #4: 0x00000001959329c4 libc++abi.dylib`demangling_terminate_handler() + 296
    frame #5: 0x000000019589a258 libobjc.A.dylib`_objc_terminate() + 124
    frame #6: 0x000000019593f304 libc++abi.dylib`std::__terminate(void (*)()) + 16
    frame #7: 0x000000019593ec58 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 32
    frame #8: 0x000000019593ec18 libc++abi.dylib`__cxa_throw + 124
    frame #9: 0x000000019589a0d0 libobjc.A.dylib`objc_exception_throw + 356
    frame #10: 0x0000000195a66f84 CoreFoundation`+[NSException raise:format:] + 108
  * frame #11: 0x0000000107f993dc LocationTrackingFW`+[FIRInstallations installations](self=FIRInstallations, _cmd="installations") at FIRInstallations.m:159:5
    frame #12: 0x0000000107ab1bc0 LocationTrackingFW`+[FIRAnalytics updateFirebaseInstallationID] + 32
    frame #13: 0x0000000107ab1aec LocationTrackingFW`+[FIRAnalytics startWithConfiguration:options:] + 564
    frame #14: 0x00000001025cdac0 Field Service`-[FIRApp configureCore](self=0x0000000280a1b510, _cmd="configureCore") at FIRApp.m:364:9
    frame #15: 0x00000001025cd5e0 Field Service`+[FIRApp addAppToAppDictionary:](self=0x00000001035a2f20, _cmd="addAppToAppDictionary:", app=0x0000000280a1b510) at FIRApp.m:317:7
    frame #16: 0x00000001025cc90c Field Service`+[FIRApp configureWithName:options:](self=0x00000001035a2f20, _cmd="configureWithName:options:", name=@"__FIRAPP_DEFAULT", options=0x0000000280a1b750) at FIRApp.m:202:5
    frame #17: 0x00000001025cc330 Field Service`+[FIRApp configureWithOptions:](self=0x00000001035a2f20, _cmd="configureWithOptions:", options=0x0000000280a1b750) at FIRApp.m:145:3
    frame #18: 0x00000001025cc27c Field Service`+[FIRApp configure](self=0x00000001035a2f20, _cmd="configure") at FIRApp.m:131:3
    frame #19: 0x00000001022cb54c Field Service`AppDelegate.setupFirebase(self=0x0000000109f08a00) at AppDelegate.swift:272:21
    frame #20: 0x00000001022cb454 Field Service`AppDelegate.init() at AppDelegate.swift:42:9
    frame #21: 0x00000001022cb5e4 Field Service`@objc AppDelegate.init() at <compiler-generated>:0
    frame #22: 0x0000000199bda698 UIKitCore`UIApplicationMain + 1728
    frame #23: 0x00000001022d1af4 Field Service`main at AppDelegate.swift:21:7
    frame #24: 0x0000000195974360 libdyld.dylib`start + 4

Been stuck on this for hours now. Can anyone please help me out

Most helpful comment

I'm still experiencing this in 6.21.0 - also when trying in new test projects set up from the ground.

All 25 comments

Can you try moving the setupFirebase call to didFinishLaunchingWithOptions and removing all calls to Firebase before that?

@bakshioye Firebase classes are defined in different modules in your app. From the stack trace the Firebase initialization is triggered from Field Service module but a FIRAnalytics class copy defined in LocationTrackingFW is used later.

Could you please share details on how you integrate Firebase? Note that currently Firebase is compiled as static frameworks which places additional limitation on using it from dynamic frameworks.

Can you try moving the setupFirebase call to didFinishLaunchingWithOptions and removing all calls to Firebase before that?

I tried calling that from inside didFinishLaunchingWithOptions as well and it was the first line of code(thus there were no calls to Firebase before that) but still faced the crash

@bakshioye Firebase classes are defined in different modules in your app. From the stack trace the Firebase initialization is triggered from Field Service module but a FIRAnalytics class copy defined in LocationTrackingFW is used later.

Yeah I noticed that in the stack trace, the shift from FieldService to LocaionTrackingFW but I had no idea why that was occurring. To be honest, this was working fine 2 days ago

FieldService is one of the target's name in my main App(called Dista) whereas LocationTrackingFW is a framework that I use within the my main app.

The hierarchy looks like this :
Screenshot 2020-03-19 at 12 43 49 AM

I am only calling FirebaseApp.configure() from inside my main app Dista and not from LocationTrackingFW so I wonder why the control is going there

Could you please share details on how you integrate Firebase?

Are you asking if I'm using cocoapods or something ? If so, I'm using cocoapods

Can you check the console to see if there are duplicate class errors when running your app? They'll be outputted at the top of your logs, before any other logs are emitted.

Yeah there are like a looooots of them but I tried a few things to get rid of them but can't . And they didn't create any problem until 2 days ago . Are they the main problem? Should I share my Podfile? And do you know how to get rid of it? Thanks

This is what my pod file looks like :

platform :ios, '10.0'

use_frameworks!

def shared_pods

  pod 'Alamofire', '~> 4.5'
  pod 'SwiftyJSON'
  pod 'Firebase/Core'
  pod 'Firebase/Messaging'
  pod 'Firebase/Firestore'
  pod 'Firebase/Database'
  pod 'SDWebImage', '~> 4.0'
  pod 'SDWebImage/WebP'
  pod 'InteractiveSideMenu'
  pod 'ExpandableCell'
  pod 'GoogleMaps'
  pod 'GooglePlaces'
  pod 'ReachabilitySwift'
  pod 'IQKeyboardManagerSwift'
  pod 'SVProgressHUD'
  pod 'Siren', :git => 'https://github.com/ArtSabintsev/Siren.git', :branch => 'swift5.0'
  pod 'ImageScrollView'

end

target 'Field Service Inc' do
  shared_pods
end

target 'LocationTrackingFW' do
    use_frameworks!

    pod 'Alamofire', '~> 4.5'
    pod 'SwiftyJSON'
    pod 'Firebase/Core'
    pod 'Firebase/Firestore'
end

If your app is the only target that depends on LocationTrackingFW, you'll need to structure your Podfile so Firebase is linked only into LocationTrackingFW and not your main app. Something like this:

use_frameworks!

target 'Field Service Inc' do
  inherit! :search_paths
  # app pods
  # ...

  target 'LocationTrackingFW' do
    pod 'Firebase'
  end

end

And then in Xcode specify LocationTrackingFW as a dependency of Field Service Inc.

Usually you can avoid all of this difficulty by just using a single target instead of both and app and dynamic framework target.

No my app has multiple targets meaning multiple clients just like Field Service Inc.

  1. Say my main app(Dista) has 2 targets namely Field Service and Field Service Inc and one framework LocationTrackingFW
  2. I have to use common pods(Including Firebase and others) for all the targets that belong to the main app(like Field Service and Field Service Inc, that's why I used shared pods) but only Firebase inside LocationTrackingFW

How should I structure my Podfile in that case ?

In that case you must use a static dependency instead of a dynamic one. Unfortunately this isn't really documented anywhere and is mostly a trial-and-error process, since it's not particularly well-supported by either Xcode or CocoaPods.

So the way I'm using LocationTrackingFW framework inside my project, is it considered static or dynamic?

The hierarchy looks like this :
Screenshot 2020-03-19 at 12 43 49 AM

I did some digging and found out that My working code(on remote repo) had

Firebase/Core (6.15.0):

and current code(that is crashing) has

Firebase/Core (6.20.0):

Maybe the version difference did some changes that is causing the crash

Is there a way to revert back to the pervious version (6.15.0) that was working for me?

You can check if it's static or dynamic by opening the target in Xcode and under Build Settings look for Mach-O type.

After reverting back to version 6.15.0, everything seems to be working. Looks like something was broken in version 6.20.0

Sounds good. Comment here if this occurs in a later SDK and I'll re-open the issue.

@bakshioye From the information you've provided it looks like after reverting to 6.15.0 you still have the same problem - Firebase classes versions are defined in different modules, so Objective C runtime of your app has different copies of Firebase classes. It means that even if your app is not crashing, Firebase behaviour is undefined for cases when static members of classes are used (e.g. FIRApp which coordinates Firebase components, etc.).

For you specific case the framework that uses Firebase LocationTrackingFW should be defined as a static (instead of dynamic), then it will be able to use the single Firebase frameworks linked to your app targets.

We acknowledge that using Firebase from both a framework and an application for cases like yours is not covered well in the documentation and may be confusing. We will work on better documentation for it.

Some clarification on the static vs. dynamic topic may be found in the articles like this.

Feel free to ask if you still have questions.

I'm still experiencing this in 6.21.0 - also when trying in new test projects set up from the ground.

Hello @bakshioye @kenneth488 did you figure out any workarounds ?
I'm using Cocoapods with similar architecture to @bakshioye: one app and multiple modules that needs to call Firebase.

@taher-mosbah , The only possible solution that worked for me was to revert back to older version of Firebase, in my case it was 6.15.0.

To revet to previous version, you can add the following to the Podfile:

pod 'Firebase', '= 6.15.0'

@bakshioye, thanks for your reply but I have the same issue with version 6.15.0

@bakshioye , thanks. Your solution really works. I tried to solve this problem 3 hours. Only back to version 6.15.0 helped me.

I'm still experiencing this in 6.21.0 - also when trying in new test projects set up from the ground.

Your solution saved heaps of my time! This is a bug from Firebase and I recommend Firebase team look into it.

@AmirKamali on thing though, for me it seems to only happen on simulator.

@taher-mosbah Interesting, For me it happened when I configure the "GoogleService-Info.plist" via FirebaseApp.configure(options: appOptions) rather than using FirebaseApp.configure()

As mentioned here and in the comments to the identical issues #5143, #5425 the reason of the crash is using Firebase from a dynamic framework.

Solution:
You should use one of the options described in the Stack Overflow answer to fix it.

Note:
Reverting to an older Firebase version does not solve the core issue and leads to undefined behaviour (such missed or duplicated Analytics events, etc.) instead of crashing on start.

I'm locking the ticket to keep the correct answer as the last comment for visibility for other developers. Feel free to file a new ticket if you have a different issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

myflashlab picture myflashlab  路  7Comments

zsajjad picture zsajjad  路  8Comments

svachmic picture svachmic  路  5Comments

pimnijman picture pimnijman  路  7Comments

EthanDoan picture EthanDoan  路  6Comments