Google's EDM4U Is Archived: Moving Unity Projects to Unity's EDM

If your Unity mobile game uses Firebase, AdMob, an ad mediation SDK or almost any other native plugin, it probably depends on Google's External Dependency Manager for Unity (EDM4U). Google set 26 October 2026 as the date its EDM4U repository becomes read-only, and Unity now ships its own replacement, the External Dependency Manager (EDM) package. This guide covers what changed, what the new package drops, and a safe migration order for a small studio with a game already live.

What happened, in dates

The handover took about five weeks, and the main points are on official pages:

• 14 September 2026: Unity publishes EDM 2.1.0, which Unity calls the launch version of the package (a 2.0.0 build dated February 2026 also appears in the EDM changelog).
• 22 September 2026: Unity announces EDM in a Unity Discussions post and on the Unity blog.
• 26 September 2026: Google deprecates EDM4U, according to Unity's FAQ in the same Discussions thread.
• 29 September 2026: Google ships EDM4U 1.2.190, the latest release listed on the GitHub releases page.
• 1 October 2026: Unity releases EDM 2.1.1 with UI and Android path fixes.
• 26 October 2026: the EDM4U repository is due to become read-only and unsupported.

Google's README spells out what that means: the old code and releases remain accessible, but there will be "no future updates, bug fixes, or new feature development from Google". Your current builds will not break today. The risk builds up slowly instead: every future Android Gradle Plugin, Xcode, CocoaPods or Unity Editor change that trips the resolver will stay unfixed in EDM4U.

What EDM does and why every mobile game needs one

A Unity plugin for ads or analytics is a thin C# layer over native libraries. Those native libraries come from Maven repositories on Android and from CocoaPods or Swift Package Manager on iOS, and each one pulls in its own dependencies. Put AdMob, a mediation SDK with five adapters, Firebase Analytics and a push notification SDK in one project and you get version conflicts, duplicate classes and failed Gradle builds.

EDM4U solved this with a simple contract. Each SDK ships a *Dependencies.xml file in an Editor folder that lists the Android packages and iOS pods it needs. The resolver collects every file, patches your Gradle templates on Android and generates a Podfile on iOS, then lets Gradle and CocoaPods do the actual downloading and version resolution. Unity's introduction to EDM describes the same model, because EDM is a fork of EDM4U.

That XML contract is the most important fact in this whole transition. Unity states that EDM "reads the same XML dependency files that SDKs use with EDM4U", so SDK vendors do not need to rewrite anything for their plugins to resolve under EDM.

EDM4U vs Unity EDM: what is different

According to the FAQ in Unity's announcement, these EDM4U features are not available in EDM:

• Package Manager Resolver, because UPM itself now covers registries.
• Pre-Gradle resolution, meaning the old mode that downloaded AAR files into Assets/Plugins/Android. The 2.1.0 changelog lists it as "Removed AAR Resolution mode".
• ABI stripping and manifest variable processing, which Unity calls obsolete.

The Version Handler still exists but is marked deprecated. The Version Handler page says it "will be removed in a future version of the package".

On the plus side, Unity lists better detection of Ruby and CocoaPods, a frequent cause of failed iOS builds. The troubleshooting page says EDM finds pod installed via Homebrew on Apple Silicon and Intel Macs, rbenv and RVM, and adds a setting for a custom CocoaPods executable path. Version 2.1.1 also replaced the old IMGUI resolver dialogs with UI Toolkit windows and fixed a DirectoryNotFoundException for packages installed from a local folder.

Who needs to act now

You must plan work if:

• Your project is still on Unity 2021.3 or older. EDM requires 2022.3 or later, so you cannot switch until you upgrade the Editor. If you are deciding which version to move to, see our earlier post on which Unity version to ship on now.
• Your Android build still relies on AARs copied into Assets/Plugins/Android instead of a custom mainTemplate.gradle. EDM no longer supports that mode.
• Your pipeline uses the Version Handler, for example to clean up files from old .unitypackage plugin versions.

You can move calmly if you are on Unity 2022.3 or Unity 6, already use custom Gradle templates, and your SDKs come from UPM or recent .unitypackage releases. For you, the switch is mostly a matter of testing.

SDK vendors are already moving. The Google Mobile Ads Unity plugin v11.6.0, released on 13 October 2026, "added support for Unity External Dependency Manager (com.unity.external-dependency-manager@2.1.0)". The same release raised its minimum Unity version to 2022.3 and its minimum Android API level to 24. Firebase made a similar jump: the Firebase Unity SDK 14.0.0 release notes (15 October 2026) set Unity 2022.3 as the minimum, raise minSdkVersion to 24, and say iOS builds now require Swift Packages instead of CocoaPods. Taken together, staying on an old Editor with an archived resolver will soon also mean staying on old ad and analytics SDKs.

Step-by-step migration for a live game

Do this on a branch, and only after you can produce a clean Android and iOS build of the current version. Unity's Get started with EDM page covers the menus; the order below is how we would run it on a game that is already earning.

1. Record a baseline. Build Android (AAB) and iOS from the current branch. Save the generated mainTemplate.gradle, ProjectSettings/AndroidResolverDependencies.xml and the iOS Podfile/Podfile.lock. You will diff against these later.
2. Check how EDM4U got into the project. It is usually one of three things: a folder such as Assets/ExternalDependencyManager from a .unitypackage, a direct UPM/OpenUPM package, or a dependency of another UPM package such as an ads SDK. Some mediation SDKs ship their own fork, for example LevelPlay's Mobile Dependency Resolver, which Unity's docs name as an alternative manager.
3. Install EDM. Open Window > Package Management > Package Manager, select Unity Registry, search for "External Dependency Manager" and install it.
4. Make EDM the active manager. If another manager is present, Unity asks which one stays active; choose "Use Unity's External Dependency Manager". Nothing is deleted. You can switch back at any time via Assets > External Dependency Manager > Change To Alternative EDM. Unity says the active manager handles all XML-defined dependencies across your SDKs.
5. Move settings over. Resolver settings now live in Edit > Project Settings > External Dependency Manager. Recheck "Resolve Automatically", "Resolve Automatically On Build", "Use Jetifier" (it needs Custom Gradle Properties Template enabled in Player settings) and, on iOS, CocoaPods integration and Swift Package Manager integration.
6. Force Resolve and diff. Run Assets > External Dependency Manager > Android Resolver > Force Resolve. Compare the new mainTemplate.gradle dependency block and AndroidResolverDependencies.xml against your baseline. The same library versions should come out. Then build iOS and compare the Podfile or the Swift packages added to the Xcode project.
7. Test on devices. Run a smoke test that loads and shows every ad format, fires analytics events, receives a push notification and completes a sandbox purchase. Dependency problems often show up at runtime as a missing class, not at build time.
8. Remove the old manager carefully. Delete the folder if it came from a .unitypackage. If it is a standalone UPM package, switch away from it first and then uninstall it. If an SDK depends on it, leave it installed: Unity warns that uninstalling it also uninstalls the SDK that depends on it. Keep it muted until that SDK moves to EDM.
9. Update CI. Make sure build machines resolve the same way the Editor does, and that your CocoaPods path is correct on Mac build agents.

Notes for plugin and SDK maintainers

If you ship an internal plugin (many studios keep shared code for ads, IAP or login in one package), declare EDM as a dependency in package.json with "com.unity.external-dependency-manager": "2.1.0" and remove the dependency on Google's package. For legacy .unitypackage distribution, Unity suggests telling users to install EDM from the Package Manager, or including a small editor script that calls Client.Add("com.unity.external-dependency-manager@VERSION") on first import.

The XML format is unchanged, but EDM adds useful options on iOS. A <swiftPackage> entry can declare replacesPod so a project gets either the Swift package or the CocoaPod, not both, and a target attribute lets you link a package to UnityFramework, the main app target, or a custom target such as a notification service extension. Details are on the iOS Resolver page.

Risks and open questions

• Closed source. EDM4U was open source under Apache 2.0. Unity confirmed in the Discussions thread that the EDM repository "is not currently public" and that the package uses the Unity Companion License. If you used to patch the resolver yourself, you now depend on Unity's release cycle and bug reporter.
• No published support window. Unity says EDM "will be actively maintained", but we could not find a stated support period or roadmap beyond that.
• Mixed SDK states for a while. Until every vendor declares EDM, many projects will have EDM active alongside a muted EDM4U that an SDK still pulls in. That is a supported setup, but check the Package Manager after every SDK update.
• Older Editors are left behind. Teams on 2021.3 can keep using the archived EDM4U, but with no fixes coming, every new SDK release becomes a small gamble.

Our take

At Lightning Games we build and ship Unity mobile games from Da Nang, and dependency resolution is one of the least visible and most fragile parts of a release. Our view is that the switch is worth doing now, while you have time, rather than during a store deadline when a new SDK version suddenly needs it. The technical change is small because the XML format is unchanged. Most of the effort goes into the baseline, the diff and a device smoke test, which are worth doing before any SDK update anyway.

If you are still on Unity 2021.3, treat this as one more reason to plan the Editor upgrade. The Google Mobile Ads plugin and the Firebase Unity SDK now both require 2022.3, so the archived resolver is the smaller part of the problem.

Sources

• Unity Blog: Unity External Dependency Manager, what you need to know
• Unity Discussions: Introducing External Dependency Manager (EDM)
• Unity EDM documentation: Get started with EDM
• Unity EDM changelog
• Unity EDM troubleshooting guide
• Google: External Dependency Manager for Unity (EDM4U) repository and archive notice
• Google Mobile Ads Unity Plugin v11.6.0 release notes
• Firebase Unity SDK release notes

Building a Unity mobile game and want a second pair of eyes on your SDK stack or release pipeline? See what we make at Lightning Games.

Cover photo: Battle- & Workstation (Unsplash) by Caspar Rubin, CC0 1.0, via Wikimedia Commons (cropped).