feat(ios): podspecs now utilize CoreOnly instead of Core

[dlockwo]

…xcept Analytics which should continue to reference Core.

Description

iOS does not allow applications in the Kids category to collect Firebase analytics. Firebase has refactored their libraries to utilize the CoreOnly module instead of Core to accommodate this. Currently RNFirebase pods rely on Firebase/Core. Pull request updates RNFirebase pod files to utilize CoreOnly instead of Core (except Analytics)

Related issues

Fixes #3570

Release Summary

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android
  • iOS
• My change includes tests;
  • e2e tests added or updated in packages/\*\*/e2e
  • jest tests added or updated in packages/\*\*/__tests__
• I have updated TypeScript types that are affected by my change.
• This is a breaking change;
  • Yes
  • No

Test Plan

Ran e2e tests without errors. Tested libraries I use locally in my application (app, auth, database).

Think react-native-firebase is great? Please consider supporting the project with any of the below:

• 👉 Star this repo on GitHub ⭐️
• 👉 Follow React Native Firebase and Invertase on Twitter

[CLAassistant]

All committers have signed the CLA.

[mikehardy]

Seems sensible enough based on my reading, @Ehesp I think you were looking at this over in flutter-land? You may have insight

[Ehesp]

Yep this is one we need to sort on FlutterFire too - thanks for submitting the PR. Looks like everything is Green too which is handy.

[Ehesp]

Infact, looking at the Podspec for Firebase, the pods already include CoreOnly as a dependency - just not versioned. cc @Salakar any ideas whether we even need to include these?

[dlockwo]

I wondered if they needed to be included as well, but followed the convention in place..

[Salakar]

They no longer need to be added it seems, so they can be safely removed - would you mind making the change to do that @dlockwo?

[dlockwo]

I've made the changes, but wanted your thoughts on the following pods: AdMob, DynamicLinks, InAppMessaging and RemoteConfig.

The Firebase documentation for DynamicLinks, InAppMessaging and RemoteConfig specify you should add that pod and Analytics. The Firebase podspecs for these libraries pull in the FirebaseAnalyticsInterop pod which I assume interfaces with Firebase/Analytics if it exists. E2E tests pass without Analytics included.

The original RNFirebase AdMob podspec included Analytics. The documentation for AdMob does not reference Firebase/AdMob at all. It instead references the pod Google-Mobile-Ads-SDK. E2E tests pass without Analytics included.

Do you want to include Analytics in these podspecs or instruct users to add the Analytics library separately?

[Salakar]

Thanks for making these changes;

The Firebase documentation for DynamicLinks, InAppMessaging and RemoteConfig specify you should add that pod and Analytics. The Firebase podspecs for these libraries pull in the FirebaseAnalyticsInterop pod which I assume interfaces with Firebase/Analytics if it exists. E2E tests pass without Analytics included.

If this is what the docs suggest then I think we should have the Analytics pod by default in each of these.

The original RNFirebase AdMob podspec included Analytics. The documentation for AdMob does not reference Firebase/AdMob at all. It instead references the pod Google-Mobile-Ads-SDK. E2E tests pass without Analytics included.

Firebase/AdMob is just a shell podspec afaik that brings in the Google-Mobile-Ads-SDK pod automatically - It's easier using this one as when we update the Firebase iOS SDK version then this also covers updating the Ads SDK

[Salakar]

Going to go ahead and merge this - will sort the analytics pods separately (will conditionally add them in if RNFB analytics package is installed in users project). Messaging is another one: https://firebase.google.com/docs/cloud-messaging/ios/client

Thanks for taking the time to see this PR through 🎉