Firebase-ios-sdk: Crash In Did Finish Launch Application

[Aishwaryalaxmi]

After the pod update app is crashing in did finish application. This crash is not happening in the previous pod version . Please find the attached logs and the pod versions

Firebase 6.20.0
Firebase core 6.6.4
Firebase performance 3.1.10
Firebase analyticas 6.3.1

Xcode Version: 11.3.1
iOS Version: 13.3

====================================

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).
(null)

libc++abi.dylib: terminating with uncaught exception of type NSException

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[morganchen12]

Can you share the full stack trace?

[bakshioye]

I faced the same issue here. Can anyone suggest something ?

[Aishwaryalaxmi]

@morganchen12 We are not getting any other stack trace.

[bakshioye]

@Aishwaryalaxmi Can you try moving the call from didFinishLaunchingWithOptions to init() of AppDelegate like this

override init() {
        super.init()

        // Setting up the firebase instance
        FirebaseApp.configure()
    }

And then when the app crashes, then enter bt in the debugger console and then stack trace will be displayed. Can you paste that here ?

[bakshioye]

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?

[Aishwaryalaxmi]

If I call configure in the didFinishLaunch everything works fine. But we are calling the configure only when we are accessing the Firebase. This was perfectly working when we are using the old pod.

Note: We recently updated the script to upload the dYSM file as per the Firebase direction.

[ryanwilson]

if you're seeing an exception the stack trace should be printed in Xcode's console above the terminating with uncaught exception of type NSException text. As an example I just tried to call [FIRApp configureWithOptions:] with an invalid FIROptions instance (with EMPTY_FILE_PATH as an example) and this was printed:

2020-03-19 09:40:39.489402-0400 AnalyticsExample[27427:15040898] 6.19.0 - [Firebase/Core][I-COR000014] The configuration file at EMPTY_FILE_PATH does not exist or is not a well-formed plist file.
2020-03-19 09:40:39.493689-0400 AnalyticsExample[27427:15038554] *** Terminating app due to uncaught exception 'com.firebase.core', reason: 'Options is nil. Please pass a valid options.'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007fff23c7127e __exceptionPreprocess + 350
    1   libobjc.A.dylib                     0x00007fff513fbb20 objc_exception_throw + 48
    2   CoreFoundation                      0x00007fff23c710bc +[NSException raise:format:] + 188
    3   AnalyticsExample                    0x00000001020ca2e2 +[FIRApp configureWithOptions:] + 98
    4   AnalyticsExample                    0x00000001020c4ee5 -[AppDelegate application:didFinishLaunchingWithOptions:] + 149
    5   UIKitCore                           0x00007fff48089ad8 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 232
    6   UIKitCore                           0x00007fff4808b460 -[UIApplication _callInitializationDelegatesWithActions:forCanvas:payload:fromOriginatingProcess:] + 3980
    7   UIKitCore                           0x00007fff48090f05 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1226
    8   UIKitCore                           0x00007fff477c576d -[_UISceneLifecycleMultiplexer completeApplicationLaunchWithFBSScene:transitionContext:] + 122
    9   UIKitCore                           0x00007fff47cb44c1 _UIScenePerformActionsWithLifecycleActionMask + 83
    10  UIKitCore                           0x00007fff477c627f __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke + 198
    11  UIKitCore                           0x00007fff477c5c8e -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 296
    12  UIKitCore                           0x00007fff477c60ac -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 818
    13  UIKitCore                           0x00007fff477c5941 -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 345
    14  UIKitCore                           0x00007fff477c9f3f __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke_2 + 178
    15  UIKitCore                           0x00007fff47bd8c83 +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:actions:completion:] + 865
    16  UIKitCore                           0x00007fff47cd2dff _UISceneSettingsDiffActionPerformChangesWithTransitionContext + 240
    17  UIKitCore                           0x00007fff477c9c5a __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 153
    18  UIKitCore                           0x00007fff47cd2d02 _UISceneSettingsDiffActionPerformActionsWithDelayForTransitionContext + 84
    19  UIKitCore                           0x00007fff477c9ac8 -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 381
    20  UIKitCore                           0x00007fff476206e7 __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke + 657
    21  UIKitCore                           0x00007fff4761f26c -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 248
    22  UIKitCore                           0x00007fff47620411 -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 210
    23  UIKitCore                           0x00007fff4808f599 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 535
    24  UIKitCore                           0x00007fff47bfa7f5 -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 361
    25  FrontBoardServices                  0x00007fff365d6165 -[FBSSceneImpl _callOutQueue_agent_didCreateWithTransitionContext:completion:] + 442
    26  FrontBoardServices                  0x00007fff365fc4d8 __86-[FBSWorkspaceScenesClient sceneID:createWithParameters:transitionContext:completion:]_block_invoke.154 + 102
    27  FrontBoardServices                  0x00007fff365e0c45 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 220
    28  FrontBoardServices                  0x00007fff365fc169 __86-[FBSWorkspaceScenesClient sceneID:createWithParameters:transitionContext:completion:]_block_invoke + 355
    29  libdispatch.dylib                   0x0000000102644d48 _dispatch_client_callout + 8
    30  libdispatch.dylib                   0x0000000102647cb9 _dispatch_block_invoke_direct + 300
    31  FrontBoardServices                  0x00007fff3662237e __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 30
    32  FrontBoardServices                  0x00007fff3662206c -[FBSSerialQueue _queue_performNextIfPossible] + 441
    33  FrontBoardServices                  0x00007fff3662257b -[FBSSerialQueue _performNextFromRunLoopSource] + 22
    34  CoreFoundation                      0x00007fff23bd4471 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
    35  CoreFoundation                      0x00007fff23bd439c __CFRunLoopDoSource0 + 76
    36  CoreFoundation                      0x00007fff23bd3b74 __CFRunLoopDoSources0 + 180
    37  CoreFoundation                      0x00007fff23bce87f __CFRunLoopRun + 1263
    38  CoreFoundation                      0x00007fff23bce066 CFRunLoopRunSpecific + 438
    39  GraphicsServices                    0x00007fff384c0bb0 GSEventRunModal + 65
    40  UIKitCore                           0x00007fff48092d4d UIApplicationMain + 1621
    41  AnalyticsExample                    0x00000001020c6060 main + 112
    42  libdyld.dylib                       0x00007fff5227ec25 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

Having that text will help us understand the issue further and any other logs you can provide, otherwise we likely won't be able to make progress.

Also note: Firebase expects to be called in didFinishLaunchingWithOptions, not init. Calling FirebaseApp.configure() after didFinishLaunchingWithOptions isn't currently a supported workflow and may not work as expected - especially for Perf and Analytics.

[bakshioye]

@Aishwaryalaxmi I was using Firebase 6.20.0 as well and it was crashing for me as well. I reverted back to Firebase 6.15.0 and everything seems to be working for now. You can try the same and see if it works for you

[rickrvo]

I have the same issue. just updated from 6.14.0 and this error started

[paulb777]

As requested above, we'd really like to get a crash backtrace to help with this one.

[mironal]

I have the same issue. updated from 6.14.0 to 6.21.0.

It doesn't crash if I launch from Xcode, otherwise the app crashes.

I got following error.

*** 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:

The following is part of a Podfile diff.

[ryanwilson]

@rickrvo @mironal are either of you able to share a stack trace for when the exception is thrown? If not, we don't have a way to debug why this is happening and likely won't be able to solve your issue for you. Thanks!

[mironal]

Hi! @ryanwilson

I can't get the stack trace at the time of the exception because there is no problem when connected to the debugger(xcode).

Instead, I added the code to output the stack trace as below and got it.

The following is the call stack when [FIRApp configure] is called in Firebase 6.21.0.
xxxxxxx is the my application target name. App is framework target.

    0   xxxxxxx                             0x0000000100461bc4 +[FIRInstallations installations] + 104
    1   xxxxxxx                             0x0000000100345254 +[FIRAnalytics updateFirebaseInstallationID] + 32
    2   xxxxxxx                             0x0000000100345180 +[FIRAnalytics startWithConfiguration:options:] + 564
    3   App                                 0x00000001027818d8 -[FIRApp configureCore] + 412
    4   App                                 0x00000001027813f8 +[FIRApp addAppToAppDictionary:] + 144
    5   App                                 0x00000001027806d4 +[FIRApp configureWithName:options:] + 1164
    6   App                                 0x00000001027800f8 +[FIRApp configureWithOptions:] + 148
    7   App                                 0x0000000102780044 +[FIRApp configure] + 176
    8   App                                 0x00000001025dd418 didFinishLaunchingWithOptions

And, The following is the call stack when [FIRApp configure] is called in Firebase 6.14.0.

    0   App                                 0x000000010663559c +[FIRApp defaultApp] + 52
    1   App                                 0x0000000106640360 -[FIROptions isMeasurementEnabled] + 236
    2   App                                 0x00000001066406b8 -[FIROptions isAnalyticsCollectionEnabled] + 176
    3   App                                 0x00000001065e139c +[FIRAnalytics startWithConfiguration:options:] + 264
    4   App                                 0x00000001066363ac -[FIRApp configureCore] + 412
    5   App                                 0x0000000106635ecc +[FIRApp addAppToAppDictionary:] + 144
    6   App                                 0x00000001066351ec +[FIRApp configureWithName:options:] + 1164
    7   App                                 0x0000000106634c10 +[FIRApp configureWithOptions:] + 148
    8   App                                 0x0000000106634b5c +[FIRApp configure] + 176

I think there is an issue in 6.21.0 where FIRApp and FIRInstallations are not properly initialized because they are on different targets.

But I don't know if this is an application issue or a library issue.

[mironal]

I checked which version caused the same problem and got the following results.

• 6.15.0 <- OK
• 6.16.0 <- OK
• 6.17.0 <- OK
• 6.18.0 <- NG (Crash occurs)
• 6.19.0 <- NG
• 6.20.0 <- NG
• 6.21.0 <- NG

[maksymmalyhin]

Could you please share the following:

1. The way you use Firebase (do you use it from a framework, or from the app target, both)
2. A sample project to reproduce the issue will speed up investigation significantly

Could you please also check the recommendations from https://github.com/firebase/quickstart-ios/issues/936 and Using Firebase from a Framework or a library

[mironal]

@maksymmalyhin Hi!

I am using Firebase from framework.

I have published a sample project that probably crashes due to the same problem. The actual application is more complicated.

https://github.com/mironal/firebase-crash-sample

[maksymmalyhin]

@mironal Thanks you for the sample project!

As far as I can see Firebase is used in both a dynamic framework and the app that depends on this framework. Unfortunately this use case is not supported (see the guide for details).

Here is one of potential fixes for you issue https://github.com/mironal/firebase-crash-sample/pull/1

Please let me know if it works for you.

[google-oss-bot]

Hey @Aishwaryalaxmi. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[rickrvo]

Hi! sorry for the late reply. I had lots of work to do modularizing my project... Now I caught a break and could try again updating firebase.

I updated to 6.21.0 and the error happened again.

I'm using Firebase in a modular project.

here is the Podfile configuration...

def shared_pods
    ...
    pod 'Firebase',  :modular_headers => true
    ...
end

def application_pods
    ...
        pod 'FirebaseMessaging', :modular_headers => true
end

def core_application_pods
    ...
    pod 'FirebaseRemoteConfig', :modular_headers => true
end

target 'Application' do

  project 'Application/Application.xcodeproj'

  # Pods for Application

  shared_pods
  application_pods

  target 'ApplicationTests' do
    inherit! :search_paths
    # Pods for testing
  end

  target 'ApplicationUITests' do
    # Pods for testing
  end
end

target 'Core' do

    project 'Core/Core.xcodeproj'

    # Pods for Core

    shared_pods
    core_application_pods

    target 'CoreTests' do
      inherit! :search_paths
      # Pods for testing
    end
end

[rickrvo]

just deleting the pod and installing version 6.15.0 fixes the crash.. without any code change

[maksymmalyhin]

A mentioned above, currently Firebase cannot be used from dynamic frameworks. Please do check Using Firebase from a Framework or a library and a workaround proposed in https://github.com/firebase/firebase-ios-sdk/issues/5143#issuecomment-606168720.

[rickrvo]

Converting the project to use only static libraries is not an option for me. The app is already big as it is.. after the modularization it got bigger, if I change everything to static it will inflate even more, making the benefits of a modular app almost not even worth.
So my option, if I'm not mistaken, is that I should create another static library only to encapsulate firebase SDK? So I could continue using my current dynamic frameworks as they are?

If so, how could I achieve this with FirebaseMessaging?

Another question I have is: Are there any plans to release a dynamic framework SDK option?

[maksymmalyhin]

@rickrvo Why do you think your app size will increase? If all modules in your app are packaged into dynamic frameworks then each of them that depends of Firebase and the app binary itself has its own copy of Firebase. So if you package the modules as static frameworks your app binary size may actually decrease because there will be only one copy of Firebase.

[morganchen12]

This will only increase the size of your app if Firebase is shared between multiple app and extension targets. Otherwise, as Maksym says, it will reduce the size of your app by reducing duplication of Firebase.

[rickrvo]

You are saying that having a static library which encapsulates firebase? that could work. I just can't quite see how I would implement FirebaseMessaging from the top of my head.
But If I have to change my Core and all features to static frameworks then my Core code would be copied into each and all of my features frameworks making the app bigger as the final result, instead of all features depending on a single dynamic framework.
Besides the load of the application would take a long time... (it's an huge application) all static frameworks getting loaded at the same time on app start may cause memory problems.

You think this could be done, having one framework encapsulating firebase?

[morganchen12]

@rickrvo how many runnable app targets do you have (app plus extension targets)?

Changing your dynamic framework to a static one shouldn't require any code restructuring. You would still be able to reference Firebase symbols directly in your main app target even if Firebase was also linked as a dependency of a sub-framework.

[rickrvo]

I have 2 runnable targets, a core framework and multiple feature frameworks... I need firebasemessaging on the main app, analytics on core and probably on main too (I'm still using fabric sdk but will update to firebase in the near future) and remote config on core. My main app and all features import core.
I had a similar problem with the googlemaps sdk too I had to import it on core framework only and encapsulate all calls to the core to make it work

[maksymmalyhin]

@rickrvo I would still suggest to try converting the modules to static frameworks as the easiest and the most starlight workaround working with the current Firebase versions. When evaluating the result please take into account that reducing amount of dynamic libraries used by your app will reduce the app launch time which will improve experience of the app users.

Allowing packaging Firebase as dynamic frameworks as another approach is being considered (see #2022). There are still open questions that block implementation of it. If you have other ideas feel free to file a separate future request ticket. Thanks.

[rickrvo]

@maksymmalyhin I will try to make the project use static frameworks to study the impact when I get some extra time. But regarding the app lunch time, I think it's the other way around.. Dynamic libraries would only be loaded when used... static are loaded always with the app launch. In case of Firebase yes, even if it is a dynamic framework, it would have to be loaded when the app launches because it uses it on the didfinishlaunching.

[google-oss-bot]

Hey @Aishwaryalaxmi. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Hey @Aishwaryalaxmi. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@Aishwaryalaxmi if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.