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

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

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

```yml 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 ?