Unity 6000 migration notes from four production plugins

Four plugins, one migration window

When Unity 6000 went LTS, we had to decide whether to support it across our entire catalog simultaneously or stagger the rollout. We went simultaneous — one two-week window, four plugins, one batch of store updates. Here's the compatibility log.

What didn't change

Most of it. The C# language level Unity ships with didn't move. The scripting runtime is the same. UnityWebRequest, EditorPrefs, SerializedProperty — all stable. Ninety percent of our code compiled cleanly against the 6000 assemblies with zero changes.

If you write ordinary gameplay or editor code, the migration is probably a non-event for you. You'll update your project version, get one or two warnings, move on.

What broke (and how we fixed it)

1. Handles.DrawWireDisc signature drift

Unity 6000 added an optional parameter to several Handles.Draw* methods. Our Scene Compass code called the four-argument version:

Handles.DrawWireDisc(center, normal, radius, thickness);

In 6000 this still works, but in 2020 LTS the same call with a thickness parameter doesn't exist. We guarded it with #if UNITY_6000_0_OR_NEWER — the cleanest compile-time switch since Unity added named version defines in 2022.

2. AssemblyBuilder API warnings

Older Unity versions warned softly about some AssemblyBuilder property deprecations. Unity 6000 upgraded those warnings to errors. The fix was mechanical — swap .buildTarget for .buildTargetGroup where the API had renamed.

We caught this by running the full build matrix (2020 LTS, 2022 LTS, 6000) in CI before submission. This is the whole argument for CI even on tiny plugins: one afternoon of setup saves you from the week where you ship something that builds clean on your machine and breaks for half your customers.

3. EditorWindow.wantsMouseMove behavior

This one was subtle. In 2022 LTS, setting wantsMouseMove = true and then re-opening the window would preserve the setting. In 6000, re-opening an EditorWindow of the same type fires OnEnable from scratch — which is actually the correct behavior, and was a bug in older versions. Scene Compass's measure mode depended on the old behavior without us realizing.

The fix was one line — set the flag in OnEnable — and it made the plugin more robust on older versions too, because it no longer assumed non-reset state.

The backport strategy

We keep Unity 2020.3 LTS support for the same reason we kept our prices low: it's where a large part of our audience still lives. The plugins all build and ship with:

#if UNITY_6000_0_OR_NEWER
    // the newer, cleaner API
#else
    // the older path
#endif

Not the most elegant thing in our codebase. But the minute we drop 2020.3 support, we lose a chunk of users who can't or won't upgrade their projects. The preprocessor guards are the tax we pay for that audience. They aren't going anywhere.

What to watch for in your migration

If you're porting your own Unity project or plugin to 6000, the three most common gotchas from our experience:

1. Check every [Obsolete] warning from your 2022 build. What was a warning may be an error in 6000.
2. If you touch EditorWindow lifecycle, assume OnEnable fires from a fresh state on re-open.
3. Any custom build scripts that inspect BuildTargetGroup need to validate against the renamed enum values — especially for the iOS and Android split.

Everything else, in our experience, is uneventful. Unity 6000 is the most backward-compatible major release we've shipped against. Migrate when you're ready, not in a panic.