fix(analytics, ios): correct hex string to NSData conversion for hashed conversion methods

[sean5940]

Description

Fixes incorrect handling of SHA256 hex strings in initiateOnDeviceConversionMeasurementWithHashedEmailAddress and initiateOnDeviceConversionMeasurementWithHashedPhoneNumber methods.

Problem

The current implementation uses dataUsingEncoding:NSUTF8StringEncoding which treats the hex string as a regular string:

// Before (incorrect) - produces 64 bytes
NSData *emailAddress = [hashedEmailAddress dataUsingEncoding:NSUTF8StringEncoding];

For a SHA256 hex string like "a1b2c3d4...":

• Current output: 64 bytes - UTF-8 encoded [0x61, 0x31, 0x62, 0x32, ...]
• Expected output: 32 bytes - hex-decoded [0xa1, 0xb2, 0xc3, 0xd4, ...]

Solution

Added a helper method dataFromHexString: that properly converts hex strings to binary NSData:

// After (correct) - produces 32 bytes
NSData *emailAddress = [self dataFromHexString:hashedEmailAddress];

---

Related Issues

• Fixes [🐛] initiateOnDeviceConversionMeasurementWithHashedEmailAddress incorrectly encodes hex string as UTF-8 bytes instead of converting to binary data #8869
• Related discussion How to pass string value to initiateOnDeviceConversionMeasurementWithHashedPhoneNumber? #8764

---

Checklist

• My code follows the code style of this project
• I have performed a self-review of my code
• My changes generate no new warnings
• I have added tests that prove my fix is effective

---

Testing

Manual Testing

1. Enable on-device conversion measurement in Podfile:

   $RNFirebaseAnalyticsGoogleAppMeasurementOnDeviceConversion = true

2. Call initiateOnDeviceConversionMeasurementWithHashedEmailAddress with a SHA256 hex string
3. Verify the native module correctly converts to 32-byte binary data

Reference

• Firebase On-Device Conversion Documentation

---

🔥

[vercel]

@sean5940 is attempting to deploy a commit to the Invertase Team on Vercel.

A member of the Team first needs to authorize it.

[mikehardy]

Ahh - this makes sense and after understanding it, it explains why I did not understand the issue before. The key insight is that it isn't an arbitrary UTF8 string that should convert byte by byte, it's a hexadecimal string that happens to be UTF8, so each char is actually a nibble (half a byte / 4 bits) and needs a specific char-by-char conversion that results in an NSData containing the bytes, that is half the length of the incoming string

I was thinking char -> byte and getting garbage results when I inspected this and attempted to fix myself

nice patch

[mikehardy]

I am going to rebase this on top of a PR that fixes our iOS CI and re-push the branch, as soon as github actions is back up to qualify my last commit there:

• test(ios): workaround simulator availability issues #8865

Then it should be good for merge