FirebaseApp.configure() triggers "Slow launches" warning on Xcode 16 / iOS 18

[alex-vasenin]

Description

I just switched to Xcode 16 and iOS 18 and running my app on the device started producing following runtime warnings on every app start:

/Pods/FirebaseCrashlytics/Crashlytics/Crashlytics/FIRCLSUserDefaults/FIRCLSUserDefaults.m:288 Performing I/O on the main thread can cause slow launches. This is known to cause slow launches for your users.

/Users/alexvasenin/Documents/MeteorActive/Pods.nosync/FirebaseCore/FirebaseCore/Sources/FIRApp.m:348 Performing I/O on the main thread can cause slow launches. This is known to cause slow launches for your users.

The first warning appears one time while the second one is repeated 6 times. All of the stack traces go through [FIRApp configure]. I did a quick test and indeed I found a call to FirebaseApp.configure() takes about 400-600ms on iPhone 15. However, I found if the debugger is NOT attached, the call takes only ~30ms, so it looks like the multiple stack unwinding takes the most time.

Having 7 runtime warnings without a good reason is bad. Please help to solve or silence this warnings.

Reproducing the issue

No response

Firebase SDK Version

10.2.0

Xcode Version

16.0

Installation Method

CocoaPods

Firebase Product(s)

Analytics, Crashlytics, Performance

Targeted Platforms

iOS

Relevant Log Output

No response

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[alex-vasenin]

[paulb777]

Do you see the same thing with more recent releases? 11.2.0 is the latest release.

[alex-vasenin]

My bad, I do actually use the latest release 11.2.0

[chenyanping01]

I also face the same issue. I use the release 11.1.0

[paulb777]

I'm not able to reproduce, but it seems to be related to Analytics and Crashlytics doing I/O on the main thread during initialization. @htcgh @themiswang would you take a look?

[oglerma]

we are encountering this as well. Same issue as above.

[hsoi]

I'm using Firebase 11.4.0 and encountering this. @paulb777 @htcgh have you been able to explore this? What additional information would be useful towards helping investigate and resolve this? Thank you.

[paulb777]

The best help would be a fully reproducible example.

[hsoi]

To take @chenyanping01 's screenshot a bit further, I opened one of our logs in Xcode (note: this is coming via Apple's analytics via Xcode Organizer; so this is production version of our app -- no debugger involved).

So yes, people are calling FirebaseApp.configure() at their app launch (on the main thread), and eventually it winds up blocking to wait for a dispatch group (on the main thread).

I found the highlighted comment in there interesting: "…we also want to wait as long as possible for these to be complete. If we do not, there's a chance that we will not be able to correctly report a crash shortly after start." That certainly seems… conflicting. 🤔

I doubt I could create an isolated simple repro (if you're unable to reproduce it yourself) -- sounds like you'd need our project. I'd have to talk with the boss-man about lobbing the whole project to y'all. If it winds up being doable, @paulb777 how would we work this (to get it to you, etc.)? Thanks.

[paulb777]

Thanks. To be clearer, we have a reasonable understanding of the Crashlytics problem, but not yet a solution.

The Analytics/Installations/Performance hangs are less clear and that is where we'd like to find more data since we haven't been able to reproduce

[hsoi]

@paulb777 appreciate the clarity. I chatted with the boss-man and sending the whole codebase is a no-go (not unexpected). Still, is there any way I could assist? Instrument something? generate some logs? I mean, it's basically "debugging by carrier pigeon" here 😆, but hey, if there's something I can do to help to move the needle, I'm game.

[SuryakantRapido]

Yes we also face same issue in our application ? When there will be solution

[MichaelVerdon]

I was investigating a similar issue on the Android-SDK and confirmed that Crashlytics and Analytics performing i/o disk read operations on main thread was intended behaviour and I do not think it would be outlandish to assume the same here. It may not be something to worry about unless its significantly increasing app startup time or compromises functionality.

[paulb777]

@MichaelVerdon Thanks for investigating. Our SDKs should not cause warnings for app developers and we should develop plans to stop doing I/O on the main thread.

[SuryakantRapido]

@paulb777 Any update are we doing something on this ?

[gereons]

We're seeing these warnings too, from [FIRapp configureCore]:

Xcode 16.1, Firebase SDK 11.4.0 added via SPM

[xavipedrals]

Same here but in remote config: Xcode 16.1, Firebase SDK 11.5.0 added with CocoaPods

[salmaanahmed]

We also face same issue, currently using release 11.6.0 Xcode organizer shows 380 ms spent in this code path during launch.

[cnordvik]

Just to add to this we have an app with 5M+ users and this now contributes to 30% of our slow launches. Would be great to have an update on the issue.

[akbashev]

Same here, but somehow shows the error when setting deepLinkURLScheme.

[lifely]

Any update planned on this ?

Edit: After More testing by removing sides effect from my projects I found that:

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

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

does not reproduce the issue but having a single Analytics.logEvent calls anywhere in the codebase produce it

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        FirebaseApp.configure()
        Analytics.logEvent("TEST", parameters: [:])
    }
}

the only working solution I see if we want to call configure from app-delegate asap would be to use a Task

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        Task(priority: .high) { @MainActor in
            FirebaseApp.configure()
            Analytics.logEvent("TEST", parameters: [:])
        }
    }
}

The requirement becomes to prevent any calls to Firebase and friends before this is called, you could make a dirty actor for that or something.

[alflix]

This issue now contributes to 40% of our slow launches. Version: Firebase/Crashlytics (11.9.0) Would be great to have an update on the issue.

[htcgh]

Hi all. I can't speak for Crashlytics, but I increased the relative priority of the Analytics dispatch queues in Firebase 11.11.0, which was released earlier today. Please let us know if it helps resolve the "slow launches" warnings.

[alflix]

Hi all. I can't speak for Crashlytics, but I increased the relative priority of the Analytics dispatch queues in Firebase 11.11.0, which was released earlier today. Please let us know if it helps resolve the "slow launches" warnings.

It does not help in Firebase 11.11.0

[htcgh]

@themiswang Can you take a look on the Crashlytics side?

[samedson]

Hey folks, for Crashlytics we are working on improving the startup time. We'll let you know when a fix is ready.

[samedson]

Hey folks, we just made a change that should improve the startup time of Crashlytics. It'll be included in the next Firebase SDK release.

If you'd like to test it out early it's on this PR: https://github.com/firebase/firebase-ios-sdk/pull/14754.

[hr147]

We are also facing this issue in 11.12.0. can you please update us when it will be fixed?

[ncooke3]

Thanks everyone for your patience. A fix has been merged and will release as part of 11.13.0 which is planned for the week of May 15th.