Unity-Utils: extension methods for the types Unity already gives you

A package that extends types rather than adding systems

Unity-Utils describes itself as a growing collection of handy extension methods, helpers, attributes and other utilities designed to enhance and simplify your Unity development workflow, and the framing is that it serves both a seasoned developer and someone just starting.

The important thing about the design is what it does not do. It is not a framework, a scene system or a rendering pipeline. It does not ask you to restructure your project around it. It adds extension methods to types you already use, which means the adoption cost is one using statement and the risk of a name collision with a method you wrote yourself.

The feature list names seven areas. Extension methods extend Unity and C# built-in types with additional functionality. Conversion extension methods convert vectors and quaternions between System.Numerics and UnityEngine. Hotkeys cover locking the Inspector, closing a tab and compiling the project, among others. Helpers are static helper methods such as a NonAlloc WaitForSeconds. Vector math utilities include RotateVectorOntoPlane. Singletons are generic singletons for various use cases. And there is an allocation counter to track memory allocations in your code.

The package is on GitHub under the name com.gitamend.unityutils, version 1.0.23, authored as Git Amend, and the category in its manifest is editor extensions. The primary language is C#, the licence is MIT, the default branch is master, the last push was on 2026-07-12, and the repository publishes no GitHub releases.

The System.Numerics conversion is the piece worth the download

One of the seven features stands out, because it is the one that comes from a genuine structural mismatch inside Unity rather than from a missing convenience.

Unity has its own vector and quaternion types, UnityEngine.Vector3 and UnityEngine.Quaternion, and so does.NET, as System.Numerics.Vector3 and System.Numerics.Quaternion. They are not the same types, they are not implicitly convertible, and the two libraries use them for different purposes. Unity uses its own in the engine, while a lot of physics, simulation and game maths code is written against System.Numerics because that is what those libraries speak.

So the moment a project mixes a simulation library with engine code, someone writes conversion helpers, and that code ends up copy-pasted between projects.

The conversion extension methods are the library's answer to that, and it is the kind of thing that is genuinely hard to get right, since the two vector types use different handedness conventions. A conversion that is off by a sign or a component swap produces a scene that looks almost right, which is the worst kind of bug.

The other entries in the feature list are smaller but the same kind of thing. Vector maths helpers such as RotateVectorOntoPlane take a vector and a plane and project one onto the other, and the helper methods such as the NonAlloc WaitForSeconds exist because the allocating version of a common operation is the kind of thing that shows up in a profiler without anybody noticing.

Editor hotkeys, and a package that is really an editor package

The hotkey list is short and specific, and it tells you what the audience is. Lock Inspector, Close Tab, Compile Project and more. These are editor actions, and the package manifest categorises the whole thing as editor extensions.

That categorisation is worth taking seriously before you add the package, because in Unity the line between editor code and runtime code is a hard one. A script under an Editor folder is compiled into the editor only and never ships in a build, while a script in a normal assembly is compiled into both. A package that mixes both has to keep the two apart, and the cost of a package that gets the boundary wrong is a build that fails at the worst moment, on a machine that is not yours.

The helpers and the vector maths are runtime-usable, the hotkeys are not, and the allocation counter sits in between, since counting allocations is most useful during development and most useless in a shipped build.

The README is also honest about a dependency that a package manager would not catch. The package requires the Core RP Library due to the LoadVolumeProfile() extension, and the dependencies field in package.json is an empty object. So the requirement is real and it is documented in prose, but it is not declared in the manifest where a tool would look for it, which means the check is on you.

Singletons, and an allocation counter that watches the garbage collector

Two of the features are about the everyday friction of Unity project structure rather than about maths.

The generic singletons are the classic. Unity scenes are built around the idea that a scene is loaded and unloaded, which makes a global object that must survive across scenes awkward to write, and every project ends up with its own version of the same manager base class. A generic singleton for various use cases removes the need to write that base class per project, and the project publishes a dedicated video about it, which suggests it is one of the parts people come for.

The allocation counter is the more interesting one for anyone with a performance problem. It tracks memory allocations in your code. In a managed runtime with a garbage collector, the cost that matters is often not the algorithm but the garbage: an allocation in a per-frame path will trigger collections that show up as a frame-time spike, and the usual difficulty is that the allocation is not where you think it is.

A counter that reports allocation counts rather than a profiler snapshot fits a different purpose, one that can run in a test or on a target device, and it is the kind of tool that changes how someone writes a hot loop once they can see the number move.

Neither of these is clever on its own. Both are the kind of utility that is unremarkable in isolation and valuable in aggregate, which is the pitch the README makes for the whole package: tools that are meant to simplify your coding process and add efficiency to your projects.

Installing it is one line in manifest.json

There are two ways to use the library, and the README gives both in a few lines.

The first is to download the library into your Unity project directly. The second is to import it with the package manager using the git URL:

"com.gitamend.unityutils": "https://github.com/adammyhre/Unity-Utils.git"

That line goes into the dependencies section of your project's manifest.json. The package name on the left matches the name in the package's own package.json, which is com.gitamend.unityutils, and the identifier prefix is the reverse-domain style Unity expects, com.gitamend for Git Amend, with the package author recorded in the manifest as Git Amend with a link to the author's GitHub profile.

Because it installs from a git URL, the package manager pulls the repository directly. There is no build step and no compiled artefact, which is what makes it a small, readable dependency rather than a black box.

The rest of the manifest is short. The display name is Unity Utility Library, the version is 1.0.23, the category is editor extensions, the keywords are extension, attribute, inspector and editor, the dependencies object is empty, and the documentation URL points at the repository's own README. The package description repeats the README's opening paragraph word for word, which is a small sign that the two are maintained together.

Meta files in the repository, and what the project does not say

The top-level listing has a detail that tells you this repository lives inside Unity rather than beside it. Almost every file has a.meta file next to it: CHANGELOG.md.meta, LICENSE.md.meta, PR_GUIDELINES.md.meta, README.md.meta, package.json.meta, and UnityUtils.meta for the package folder itself.

Those are Unity's asset metadata files. They record the GUID that Unity uses to identify an asset, and they are generated by Unity and normally committed alongside the asset. Committing them means the package imports with stable identifiers on every machine and on every project that installs it from a git URL, which matters for a package rather than for a project, and it explains why the repository carries files that look like build noise.

The rest of the tree is a small, well-organised package: the UnityUtils/ folder with the code, package.json at the root, a CHANGELOG.md, a LICENSE.md, a PR_GUIDELINES.md for contributors, a.gitignore and a README.

What the README does not contain is worth noting, because it bounds what you can learn before installing. There is no API listing beyond the feature summary, no documentation site, and no mention of a test suite, a supported Unity version range or a minimum C# version. The project points at three YouTube videos, one on extension methods, one on advanced extension methods and one on the singleton, and a channel with more Unity content, which is where the detail lives.

On maintenance, the numbers are modest but not abandoned. The last push was on 2026-07-12, the repository is not archived, the package version is 1.0.23, and there is a changelog, though the project publishes no GitHub releases, so the changelog and the version in package.json are the only record of what changed.

Editorial conclusion

Adopt Unity-Utils if you write Unity editor tooling or gameplay scripts and keep writing the same conversion, singleton or vector maths helper by hand, because the package exists to collect exactly those and it installs in one manifest line without a build step. Do not adopt it without checking the Core RP Library requirement, since the LoadVolumeProfile() extension needs it and the package's own dependencies field is empty, so the package manager will not tell you that up front. Before you commit to it, read the version in package.json against the changelog, because the project publishes no GitHub releases, and check whether the editor hotkeys and the inspector utilities are worth pulling in a runtime package for, since the package is categorised as editor extensions and some of it only exists in the editor.

Frequently asked questions

Official sources

1. adammyhre/Unity-Utils on GitHub
2. Issues
3. License: MIT
4. README