EDM4U dependency resolution for Unity Android and iOS

EDM4U's place in a Unity native dependency workflow

External Dependency Manager for Unity, or EDM4U, addresses a specific gap between ordinary Unity package installation and native platform dependencies. Android libraries such as AAR files must be obtained from local or remote Maven repositories and placed in the Unity project. iOS work can depend on CocoaPods or Swift Packages. Those dependencies can also bring transitive requirements that need version reconciliation. EDM4U gives packages and project owners one XML-based place to declare these requirements.

The intended users are broader than a single category of Unity developer. A package maintainer may need a package to declare native libraries without embedding a separate resolver. A legacy `.unitypackage` maintainer can ask users to install EDM4U separately. A Unity project owner may add it directly when the project consumes Android or iOS dependencies that are not managed through the assets already present in Packages. The repository also supports Package Manager registries through a resolver component designed for Unity 2018.4 and later.

There is an important adoption constraint. Google states that the repository will become read-only and unsupported on October 26, 2026. Google recommends transition to Unity's supported EDM package, which is described as an official fork using the same XML format and workflows. That continuity lowers the format-change cost, but it does not remove the timing issue: a project started under EDM4U will soon depend on a repository with no future Google updates, bug fixes, or feature development. This maintenance status comes directly from the project's archive notice, not from release frequency alone.

How EDM4U moves dependencies into Unity projects

On Android, the Android Resolver acts when the Unity editor build target is Android. It reads dependency declarations, resolves the specified libraries from local or remote Maven repositories, and copies those dependencies into the Unity project. The README gives `com.google.android.gms:play-services-games` at version `9.8.0` as the example dependency, which illustrates why coordinate and version data can matter for plugins.

For iOS, the package names CocoaPods and Swift Packages among its supported native dependency mechanisms. The README does not show the exact iOS processing sequence, so it would be inaccurate to claim when pods are installed, whether Swift packages are resolved through Xcode, or how a failed resolution is surfaced. The confirmed point is narrower: EDM4U contains an iOS Resolver for those dependency types.

The Version Handler addresses transitive dependency versions. It requires Unity 5.x or later because it depends on the `PluginImporter` UnityEditor API. The Package Manager Resolver handles Package Manager registries and requires Unity 2018.4 or later, the release in which scoped registry support was added. Platform resolver components require Unity 4.6.8 or later.

These version floors are component-specific. A project on a particular Unity version should not treat the whole plugin as compatible merely because the Android and iOS components work there. Version management and registry handling impose their own requirements. Based on the repository layout, the implementation is split among `source/`, `plugin/`, `upm/`, `gradle/`, and sample assets rather than existing as one editor script. Exact internal classes and failure handling are not documented in the README excerpt, so those details should not be inferred from directory names.

Installing EDM4U through OpenUPM and Unity Package Manager

For a package registry workflow, the README gives an OpenUPM command. Run it where the OpenUPM CLI can install the package into the Unity project context expected by that tool.

openupm add com.google.external-dependency-manager

The package name is `com.google.external-dependency-manager`. The README also provides a direct git URL installation path for Unity's Package Manager. Open Package Manager, choose the plus control, select `Install package from git url...`, and paste this exact URL:

https://github.com/googlesamples/unity-jar-resolver.git?path=upm

The `?path=upm` selector tells Git hosting to expose the repository's `upm/` directory as the package location. The README also says EDM4U is available through Google APIs for Unity as both a `.tgz` UPM package and a legacy `.unitypackage`. It does not recommend the `.unitypackage` format because an embedded copy can conflict with another installation.

There is a specific conflict case to check before installation. A package maintainer may have embedded EDM4U directly, so installing the registry package or adding a second package that embeds EDM4U can produce a dependency conflict. For an EDM4U copy imported into `Assets`, the README says it may be deleted. If a UPM package embeds it, the documented path is to ask that package maintainer to declare `com.google.external-dependency-manager` as a dependency.

Declaring the first XML dependency file

The first concrete configuration step is not to create an arbitrary XML file. The README says to copy and rename `SampleDependencies.xml` from the sample plugin, then add the dependencies required by the project. The resulting file must meet both naming and placement constraints: it must be below an `Editor` directory and its filename must end in `Dependencies.xml`, as shown by `MyPlugin/Editor/MyPluginDependencies.xml`.

That rule matters because the project already has a sample implementation at `sample/Assets/ExternalDependencyManager/Editor/SampleDependencies.xml`. Starting from that file preserves the expected root structure and editor-only placement. The README begins an Android example with `<dependencies>` and `<androidPackages>`, but the excerpt cuts off before showing the complete element, so this article does not invent the missing attributes.

After the file is placed correctly, changing the Unity build target to Android causes the Android Resolver to process the declared libraries. The iOS Resolver applies its documented responsibilities when used with its supported dependency types. For package maintainers, the placement rule should be applied inside the package rather than copied manually into every consuming project.

UPM package authors must also declare EDM4U as a package dependency if their package requires it and does not already include that dependency. The README gives this manifest form, with `1.2.178` as the documented example version:

{
  "dependencies": {
    "com.google.external-dependency-manager": "1.2.178"
  }
}

This example illustrates manifest syntax, not a recommendation to pin every project to that version. A new installation would need to account for the repository's October 26, 2026 archive notice. Legacy `.unitypackage` maintainers are instructed to ask the user to install EDM4U separately and to install it themselves while testing.

EDM4U component and Unity version boundaries

Compatibility is constrained by the requested component. The Android Resolver and iOS Resolver require Unity 4.6.8 or later. The Version Handler requires Unity 5.x or later because it relies on `PluginImporter`. The Package Manager Resolver requires Unity 2018.4 or later because scoped registry support entered Unity Package Manager at that point.

This division makes EDM4U unsuitable as an undifferentiated compatibility claim for an old editor. A project may be new enough for Android dependency resolution but still outside the documented range for registry management. Conversely, the lowest version accepted by one component does not establish support for every other component.

The replacement named by Google has its own documented boundary: Unity's External Dependency Manager can be evaluated and installed through UPM for Unity 2022.3 and later. The README says it retains existing XML dependency configurations and workflows. That makes it the more credible default for a new implementation, but teams with older Unity projects must first determine whether they can upgrade or whether they need to remain on the archived Google repository.

The archive deadline is also a component-selection issue. Google has stated that no future updates, bug fixes, or feature work will come from this repository after October 26, 2026. Existing releases remain accessible, and the repository is intended to become archived and read-only. Teams using the project should therefore treat migration planning as part of initial technical evaluation, not as optional maintenance work after installation.

Archive, licensing, and ongoing upgrade costs

The last push was on 2026-09-29, matching the documented release `v1.2.190`. That date shows recent repository activity, but the stronger fact is the project's own maintenance declaration: Google says the repository will be archived on October 26, 2026 and will become read-only and unsupported. Recent commits should not be interpreted as a commitment to future support.

License classification also needs direct inspection. GitHub reports the repository license as a custom license that cannot be classified automatically, and the repository contains a `LICENSE` file. The README does not state its permissions, restrictions, redistribution terms, or notice requirements. This article therefore does not characterize those terms. Anyone using EDM4U as a dependency in a distributed Unity plugin or product should read the repository's `LICENSE` file and confirm the actual obligations rather than relying on a general open source assumption.

Migration has two visible cost categories. XML compatibility may reduce editing work because Google says Unity's package uses the same format and workflows. Installation, embedded-copy conflicts, and editor version requirements can still require project work. In particular, teams must check whether a dependency is installed from OpenUPM, git, a local UPM package, a legacy `.unitypackage`, or an embedded copy inside another package. The README does not describe an automated migration command, so it provides no basis for claiming migration can be completed with one step.

When EDM4U is the wrong dependency tool

EDM4U is the wrong choice for a new Unity 2022.3 or later project that has no legacy EDM4U configuration to preserve and can use Unity's supported External Dependency Manager. Google explicitly positions the Unity package as the successor, with the same XML model. Selecting the archived repository would add an upcoming maintenance boundary without an established need for compatibility.

It can also be the wrong tool when the desired dependency does not fit its documented mechanisms. The overview covers Android libraries, CocoaPods, Swift Packages, transitive versions, and Package Manager registries. It does not claim to resolve arbitrary Unity asset dependencies or every native build tool. A package with only editor assets or a workflow already handled entirely by Unity Package Manager may not need EDM4U at all.

Embedded resolver copies are another failure mode. The README documents conflicts when EDM4U is installed separately while another package embeds it, or when two packages carry their own copies. This can happen during incremental adoption rather than only on a fresh install. The proposed workaround of copying a package into `Packages/` and using the embedded-package mechanism is described as temporary while package maintainers update their declarations.

The repository includes a `troubleshooting-faq.md` file, but its contents are not reproduced in the README. As a result, known Maven outages, CocoaPods errors, Swift Package resolution failures, authentication requirements, and rollback procedures cannot be described as supported by this repository documentation. Teams should not assume this plugin can repair an invalid repository URL or an inaccessible native dependency host.

Editorial conclusion

EDM4U fits existing Unity projects that already express native dependencies through its XML format, especially packages that cannot immediately move. New projects and teams planning continued support should evaluate Unity's External Dependency Manager for Unity 2022.3 or later first. Before adoption, inspect existing embedded copies, verify that every required `*Dependencies.xml` file follows the `Editor` placement rule, and confirm whether the archived Google repository is acceptable for the project's maintenance policy.

Frequently asked questions

Official sources

1. googlesamples/unity-jar-resolver on GitHub
2. Issues
3. README
4. Releases