FirebaseApp.configure() Blocks the main thread for too long

[lucasmarcal-faire]

Description

While running FirebaseApp.configure() the main thread gets blocked for more than 100ms on iPhone 15 Pro Max and it's causing our App Startup time to grown.

* Configures a default Firebase app. Raises an exception if any configuration step fails. The
 * default app is named "__FIRAPP_DEFAULT". This method should be called after the app is launched
 * and before using Firebase services. This method should be called from the main thread and
 * contains synchronous file I/O (reading GoogleService-Info.plist from disk).

It should have be a better solution than running synchronous file I/O on main thread, as some apps usually call it while initializing.

While evaluating the option to use + (void)configureWithOptions:(FIROptions *) noticed the following comment:

/**
 * Configures the default Firebase app with the provided options. The default app is named
 * "__FIRAPP_DEFAULT". Raises an exception if any configuration step fails. This method should be
 * called from the main thread.
 *
 * @param options The Firebase application options used to configure the service.
 */

So no alternatives since we use Firebase Analytics.

Any ideas of how to improve the configuration time in this case?

Reproducing the issue

No response

Firebase SDK Version

10.11

Xcode Version

15.3

Installation Method

Carthage

Firebase Product(s)

All

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.

[paulb777]

Please share a reproducible example or details of what's in firebaseStartup including the call of what's actually blocking.

[google-oss-bot]

Hey @lucasmarcal-faire. 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!

[nashysolutions]

We've encountered a similar issue with blocking on the main thread, leading to increased startup times in our application as well. Our measurements indicate substantial delays that seem out of the ordinary for what one would expect during app initialisation. We've taken a deep dive into the startup process and have isolated the problem to a specific line of code that we believe is the culprit.

If it's helpful for diagnostic purposes, we can provide additional details on the exact line and the observed behavior in our codebase. Collaboratively, we hope to find a resolution that reduces the blocking time, potentially through asynchronous loading or another optimised approach. Looking forward to more discussion on this and potential solutions.

[paulb777]

@nashysolutions Two areas for deeper investigation:

• The Promises SDK is a dependency of several Firebase products. Can you isolate which library/call leads to the hang?
• I notice the FirebasePerformance InstrumentorForClass method. Does removing FirebasePerformance impact the hang?

[cassianomonteiro]

+1

[google-oss-bot]

Hey @lucasmarcal-faire. 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.

@lucasmarcal-faire 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.