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

[davitdarsalia]

Does someone has a solution without an expo client workaround or without directly modifying pods?

[davitdarsalia]

After modifying pods, an error message appears: :modular_headers: command not found

[davitdarsalia]

Solution:

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

[mikehardy]

@davitdarsalia this is the subject of quite some discussion here already - did you search the issues list for recent / heavily commented issues? Unfortunately, you need to use use_frameworks! in your Podfile for react-native-firebase v15+ (which uses firebase-ios-sdk v9+ which brings in this requirement). Why? Because firebase-ios-sdk requires it, per their maintainers directly replying, and we're not in control of that here - they need it for their current code structure so we need it.

Your resolution above is a temporary workaround for this requirement but you should mentally prepare + start work on getting use_frameworks in your Podfile (however you have to do that, varies per project...) and work through the process before the modules you need start strictly requiring it (versus just Functions and Storage right now...)

[vargajacint]

@mikehardy What do you think. This is the right way? I mean a lot of dependency is not ready to use with use_frameworks!, maybe the biggest one is flipper. Do you know, why firebase-ios-sdk v9+ needs it?

I read some where I can "avoid" to use use_frameworks! by using use_modular_headers!. I'm not dig in to it, but what is the drawback to use it?

Thank you for your time, really!

[mikehardy]

@vargajacint it appears to me that when you enable use_frameworks, cocoapods auto-generates some headers that firebase-ios-sdk uses for cross-module interdependencies. I'm a bit vague on that but the compile errors seen by people that try the workaround you mention (use_modular_headers...) indicate that some header files are not generated. You can see this by trying the workaround while using Storage or Functions, neither will work, even with the workaround.

So the path forward is clearly use_frameworks, and to work through the modules you use until they work with it, similar to the AndroidX / jetifier conversion. It may take some time and personal effort on you or your company's part to work changes in to the modules you care about but it's the path forward.

Flipper does not work but will hopefully be fixed shortly as it's pretty important. Hermes is supposed to be fixed already but still needs some testing I think - that's the current frontier of core work, with Flipper next.