🔥 Missing support for initiateOnDeviceConversionMeasurementWithPhoneNumber

[htcgh]

Issue

React Native Firebase is missing support for the Analytics (iOS-only) API initiateOnDeviceConversionMeasurementWithPhoneNumber (reference), which was added in Firebase iOS SDK 10.13.0.

---

Project Files

Javascript

Click To Expand

package.json:

# N/A

firebase.json for react-native-firebase v6:

# N/A

iOS

Click To Expand

ios/Podfile:

• I'm not using Pods
• I'm using Pods and my Podfile looks like:

# N/A

AppDelegate.m:

// N/A

---

Android

Click To Expand

Have you converted to AndroidX?

• my application is an AndroidX application?
• I am using android/gradle.settings jetifier=true for Android compatibility?
• I am using the NPM package jetifier for react-native compatibility?

android/build.gradle:

// N/A

android/app/build.gradle:

// N/A

android/settings.gradle:

// N/A

MainApplication.java:

// N/A

AndroidManifest.xml:

<!-- N/A -->

---

Environment

Click To Expand

react-native info output:

 OUTPUT GOES HERE

• Platform that you're experiencing the issue on:
  • iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both
• react-native-firebase version you're using that has this issue:
  • e.g. 5.4.3
• Firebase module(s) you're using that has the issue:
  • e.g. Instance ID
• Are you using TypeScript?
  • Y/N & VERSION

---

• 👉 Check out React Native Firebase and Invertase on Twitter for updates on the library.

[mikehardy]

Versioning note: this could be considered a breaking change to add, as firebase-ios-sdk 10.10.0 was the minimum firebase-ios-sdk last required in a breaking change (https://github.com/invertase/react-native-firebase/blob/main/CHANGELOG.md#1810-2023-06-22)

On the other hand, the ability to override the firebase-ios-sdk version explicitly comes with a warning that it may cause problems, and you have to manage versions yourself so I'm leaning towards considering requirement of new minimum firebase-ios-sdk version to be a non-breaking change so we are free to add support for new APIs without friction (though with a good changelog comment from commit message...)

I feel this warning, present in the documentation about overrides, supports the stance that simply using new symbols is non-breaking change:

Using your own SDK versions is generally not recommended as it can lead to breaking changes in your application. Proceed with caution.

So, that settled (for me at least, though open to opinion...) this should be pretty trivial to add