Moving from EDM4U to Unity EDM: a migration checklist

A maintenance handover, with two dates.

Unity’s 29 September 2026 migration post describes its official External Dependency Manager (EDM), following an initial forum announcement on 22 September. It is distributed through Unity Package Manager and supports Unity 2022.3 and later. It reads the XML dependency declarations used by Google’s EDM4U.

Google’s repository notice schedules EDM4U’s archive for 26 October 2026. After that date, the repository will be read-only, with no further Google updates or fixes; existing code and releases remain accessible. The notice does not say installed games stop working on that date.

For a small mobile game team, the useful next step is a controlled build experiment. Ads, analytics and other SDKs can bring native libraries into the same project. Changing the tool that assembles them deserves a test even when the game’s C# code stays the same.

Start with a build you can reproduce.

Before changing packages, create a migration branch from a known working revision. Record the Unity Editor version, SDK versions, dependency manager, native build tools and build command. Keep the current package manifest and lockfile in version control.

Find how the old resolver arrived: a manually imported package, a direct UPM dependency, or a dependency of another SDK. Locate the SDK-owned dependency XML files and any custom Gradle, Podfile or Xcode configuration. Do not assume every resolver-looking folder is safe to remove.

Make an Android or iOS baseline build for each platform you ship. Save its resolution and build logs. For an ad-supported game, a useful baseline includes SDK initialization and a test rewarded-ad flow on a device, including the reward callback. An existing successful Editor session is a weaker comparison.

Choose the active manager before removing anything.

Follow Unity’s setup and migration instructions to install com.unity.external-dependency-manager from the Unity Registry. The manual reviewed on 30 September is labelled 2.1.0-pre.1. Check the compatible version and release status offered in your Editor, then record the exact version you test.

When another manager is present, Unity offers a choice of which one stays active. Its menu also supports switching back. The documentation distinguishes a direct installation from a resolver required by another UPM package: keep an SDK-required resolver installed until that SDK migrates. Removing it can also uninstall the dependent SDK.

For this first experiment, keep the Editor, SDKs and their dependency declarations unchanged. Change the active manager, inspect the diff, and resolve again. Separating those changes makes an unexpected native-library version or build failure easier to explain.

Test the native build and device flows.

Unity EDM supports Gradle, CocoaPods and Swift Package Manager resolution. Test the path your project actually uses; adopting EDM does not require simultaneously changing your iOS dependency system.

Our suggested acceptance checklist:

• Android: compare resolved library versions and generated build changes with the baseline. Build the release variant you distribute and inspect any new duplicate-class or dependency errors.
• iOS: export a fresh Xcode project, resolve with your existing package system, and complete the device build or archive. Review changed native dependencies and linker settings.
• On device: check startup, SDK initialization, consent handling and the affected product flows. Use ad test mode and purchase sandbox tools where applicable; verify the outcome, not only that a button opens a screen.
• On CI: repeat from a fresh checkout using the recorded versions and normal credentials. A local build that depends on a previously generated file is not yet a reproducible result.

Use your event plan to check that the same confirmed outcomes still arrive. Keep purchase attempts separate from confirmed purchases, and ad display separate from an earned reward.

Make the rollback as clear as the migration.

Accept the change when the intended platforms build from the recorded configuration and the affected SDK flows pass the same checks as the baseline. Review unexplained dependency changes before merging. Archive the tested build logs with the revision so the next release has a useful reference.

If a check fails, switch back where supported or restore the baseline revision, including its package and build configuration, then rebuild. Keep a failing case with its Editor, package and SDK versions for investigation. Avoid layering an SDK upgrade onto the same experiment just to make the error disappear.

Compatibility with your exact project remains the deciding question. A short, reversible test now gives you evidence for scheduling the migration before the old tool loses maintenance.