Feature Request: Official support for Google ODM (On-device Measurement) in Unity package

[daltonbr]

Summary

We are starting to use the Google On-device Measurement (ODM) feature as documented at
dev.adjust.com/en/sdk/ios/plugins/google-odm in our Unity projects.

The feature itself works - we confirmed it in production - but the current Unity package
doesn't expose an official path to enable it without modifying the generated Xcode Podfile
manually via a post-process script.

Current workaround

We're importing the SDK via the Unity Package Manager git URL:

`https://github.com/adjust/unity_sdk.git?path=Assets/Adjust#v5.6.0`

The ODM guide states that the iOS
integration requires replacing the standard Adjust CocoaPod with the Adjust/AdjustGoogleOdm
subspec. Since the Unity package's EDM4U dependency resolver emits the standard Adjust pod,
we had to write a PostProcessBuild script that patches the generated Podfile after the build:

// Replaces:  pod 'Adjust', '<version>'
// With:      pod 'Adjust/AdjustGoogleOdm', '<version>'

This approach has several downsides:

• It is fragile - it relies on exact string matching in a generated file.
• It is invisible - a developer unaware of this script could be confused by the behavior.
• It is not portable - every project that wants ODM must copy and maintain this script.
• It silently breaks if the Podfile format changes between SDK versions.

Proposed solutions

We'd welcome any of the following, roughly in order of preference (open to other solutions)

1. A dedicated google-odm branch in the Unity SDK repo where the EDM4U dependency
   configuration already references Adjust/AdjustGoogleOdm instead of Adjust. Teams could
   then pin to that branch via UPM until the feature is mainlined:
   https://github.com/adjust/unity_sdk.git?path=Assets/Adjust#google-odm

2. A compile-time or runtime feature toggle (e.g., a scripting define symbol
   ADJUST_GOOGLE_ODM or an opt-in in AdjustConfig) that causes the SDK's own EDM4U
   configuration to emit the correct subspec automatically.

3. Documentation of an officially supported post-process hook or extension point in the
   Unity package that enables the ODM subspec without text-patching the Podfile.

Environment

• Unity SDK version: v5.6.0 (imported via UPM git URL)
• Unity version: 6000.0.x
• Target platform: iOS

We're happy to test any branch or pre-release version against our titles.

[uerceg]

Hi @daltonbr,

And thank you very much for the detailed writing. Your proposal makes sense, we'll try to (at least initially) go with your proposed solution 1, because it sounds like it should be the quickest way forwards. I'll ping you once we have this out to give it a shot and test whether it works as you expect it.

Cheers.

[daltonbr]

Thanks for the quick reply @uerceg.
Looking forward to trying it out.

[daltonbr]

Hi @uerceg, just checking whether there are any updates on this issue. We’re about to start work in this area and need to decide whether to proceed with the current workaround or wait for an official fix. Any guidance on the expected timeline would be appreciated. Thanks!

[uerceg]

Hey @daltonbr,

Sorry for delay on this one. I have just pushed google-odm branch on the public branch as your proposal number 1 suggested. Can you give it a shot whether it works as expected via UPM? If all good, we'll keep it that way for the time being and add some docs around it.

[daltonbr]

Thanks @uerceg - awesome news! Also, sorry for the delay on my side - currently, we were running with the workaround in a few apps, but I am switching to this new branch now and will report back as soon as possible.

[daltonbr]

In time @uerceg, I just noticed that with this new branch, we don't have the version "baked-in". So my next suggestion (assuming we go through with this solution) is to pair the "regular" tags with those "odm tags". E.g., 5.6.0 and 5.6.0-google-odm.

Either way, I'll pin my version to the commit hash, so no big deal. The minor annoyance is that manifest.json doesn't support comments, so I can't refer to the current version 5.6.0.

[daltonbr]

Reporting @uerceg

Ran this locally, and it already succeeded - CocoaPods generated the exact same Podfile and Podfile.lock as before, so the dependency graph resolves identically. I'd still like to verify it in production before we fully sign off, but I don't see any reason it wouldn't work, given that the dependencies are resolved equally.

But from my perspective, we are good to move with this solution.
Thanks for the effort and attention!