use_frameworks causes all kinds of worrying side effects

[espenjanson]

Hi,

Thanks for a great library and good work with replying to and fixing issues.

Like many others, I've had some trouble with the latest version of the library due to the usage of use_frameworks. First, it didn't build with hermes, then Flipper etc. Then I had to modify my Podfile to make it work with react-native-permissions. Then, I saw some very strange behavior with react-navigation (and react-native-screens) so I needed to patch that in my Podfile as well (set the pod build type).

The most worrying of all these was the last issue, as that failed silently. It wasn't until I moved around in the app that I noticed that routes started freezing.

What I'm trying to get to is that use_frameworks seems to cause all kinds of worrying side effects with other libraries, some of which I can't seem to catch with tests or failing builds.

React Native Firebase is the only library I've come across that uses it, so I'm just curious to understand why it's needed, and if there's no way of getting around it? I. e. stop having to enable use_frameworks.

Partially using this solution found on StackOverflow, seems to work (pod install, app builds, no errors from what I can see) without "use_frameworks":

target 'xxx' do:
...

  pod 'FirebaseCoreInternal', :modular_headers => true
  pod 'GoogleUtilities', :modular_headers => true
  

Any reason this shouldn't work? Am I missing something? Otherwise, this should be the recommended setup instead of use_frameworks?

After all, the error I'm getting when trying to pod install without any other modification of the Podfile except for setting $RNFirebaseAsStaticFramework = true is very much in line with the fix from StackOverflow:

[!] The following Swift pods cannot yet be integrated as static libraries:

The Swift pod `FirebaseCoreInternal` depends upon `GoogleUtilities`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.

If doing exactly what the error message says fixes the problem, why the need to add use_frameworks?

Thanks!

[espenjanson]

Tried to remove this question but couldn't figure out how - so I'll write an answer instead if anyone else is looking:

Okay, so after having gone through the last 200 issues in this repo, I've learned that it's the underlying Firebase SDK for ios that requires use_frameworks. However, it seems to be almost impossible to get this 100% stable if you're using other libraries as well. Will keep trying to find a solution.

[mikehardy]

Yep - it's part of the underlying library firebase-ios-sdk and their conversion to Swift, and some part of that where certain headers are only created at build time, and only if you turn on use_frameworks. It is uncomfortable but also from our perspective at this layer (react-native-firebase, one layer up from firebase-ios-sdk) non-negotiable. We're just working our way forward and making use_frameworks work everywhere.

On the plus side, with use_frameworks static linkage, app startup time should be quicker, so the end state is actually a technical positive, but the current situation is not great unfortunately. We're getting there

[swizes]

Hey @mikehardy

I see that some standard crucial libs does not fully support use_frameworks for example react-native-screens

software-mansion/react-native-screens#1532

What is the correct way to handle this kind of general unavoidable issue while trying to use the latest version RNFB.

I am forced to use below block instead of use_frameworks and I am wondering what does it break on Firebase "silently"

  pod 'Firebase', :modular_headers => true
  pod 'FirebaseCore', :modular_headers => true
  pod 'GoogleUtilities', :modular_headers => true