Remove use of configureWithApp from iOS init sequence

[mikehardy]

Tracking planned upstream method removal: https://github.com/firebase/firebase-ios-sdk/issues/2933

It looks like dynamic links has a very visible example of what the change means - that configureWithApp should go away, and that 'componentsToRegister' becomes the new natural home for the logic, with a new flag to initialize quickly

https://github.com/firebase/firebase-ios-sdk/pull/4137/files/71f589926b74e69ea76d0a25ae24e58efee6836b#diff-61367186bfcedbaaa5b0554cd03f8821R126-R162

What I don't know though is where to put that flag that says we want init eagerly (for the default app since crashlytics does not do multi-app) - e.g. this https://github.com/firebase/firebase-ios-sdk/pull/4137/files/71f589926b74e69ea76d0a25ae24e58efee6836b#diff-f33c561b2a3430b947e6da076758c6d9R1887

For RNFB Crashlytics we need to figure out how to set whether crashlytics should be enabled or not during startup, in the new style

Originally posted by @mikehardy in https://github.com/invertase/react-native-firebase/pull/4236#r486507138

[ryanwilson]

Thanks for picking this up! I'm curious how this affects this SDK - is this going to be a large refactor?

This is more of a code-cleanup thing and the breaking change isn't a hard deadline for this to be removed. It could also be deprecated for the breaking change and removed next time if needed.

Re: eager init, it goes in the componentsToRegister: bit which it looks like isn't populated at the moment. Perhaps we could sync up at some point in the near future about the needs of the RN SDK and make sure we don't do anything that breaks it.

[mikehardy]

Hey @ryanwilson - this seemed like it was a 95% "understand the change and current code" / 1% implementation / 4% testing type change to me. I didn't fully understand the current code here in RNFB so I have work to do there if I implement it, and this issue was mostly me filing my notes for when it did happen. My quick take was that the proposed change upstream had an end result that offered everything we needed with regard to init sequence, we just needed to bend to match.

With Invertase focused heavily on FlutterFire right now we (mostly "I" at the moment) are unfortunately really light on resources so I'm happy to hear there is not a hard deadline, though in practical terms it may not receive attention here until there is a hard deadline to motivate it, given we're just barely keeping up with breaking changes at the moment as a resources vs priorities practical matter, and are lagging on tracking new APIs

[ryanwilson]

Sounds good, thanks for letting me know! I'll remove this from the breaking change for now and make sure we reach out before making any changes to figure out a good solution for you.

[stale[bot]]

Hello 👋, to help manage issues we automatically close stale issues. This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Closing this issue after a prolonged period of inactivity. If this is still present in the latest release, please feel free to create a new issue with up-to-date information.

[paulb777]

Voting to reopen to unblock https://github.com/firebase/firebase-ios-sdk/issues/2933 to potentially unblock initialization speedup improvements

[mikehardy]

Oh no @paulb777 - hadn't realized this fell prey to the stale bot. Indeed - this was a "thing" in my mind, just wasn't a priority at the time. Re-opening, pinning, labeling up correctly...

[ryanwilson]

Hey @mikehardy - breaking change time coming up and wanted to check in and see the feasibility of getting this addressed in the next little bit! Cheers

[mikehardy]

@ryanwilson your forbearance has been extremely polite, and I think based on objective evidence this is just going to have to be a demand-pull sort of thing. You guys should just go ahead and I'll get it shortly, at the same time I work through module name and version injection as Mike Diarmid started for me here #5620

[mikehardy]

At least this time there does not appear to be all the other motion (like Admob extraction - finally done, ML, Instance ID -> Installations, AppCheck, AppDistribution etc, M1 support) - there was so much to handle the last year, right now this is about at the top of the queue finally!

[github-actions[bot]]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[mikehardy]

:facepalm:

[github-actions[bot]]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.