FastScriptReload: hot reload for Unity with a list of limits worth reading first

A tool whose pitch is a three step loop

Unity's default behaviour after you edit a script during play mode is a domain reload, which stops the session and costs you the state you had built up. That loop is the thing FastScriptReload exists to break. The description in the repository metadata is blunt about it: are you tired of waiting for full domain-reload and script compilation every time you make a small code change. The project's own summary line compresses the pitch into three verbs, play, make change, see results.

The mechanism is selective compilation. The tool compiles only what you changed and then applies the result to the current play session, which means you keep your scene, your game objects and your runtime state instead of rebuilding them. The README is careful on one point that matters for adoption: you do not have to adjust your code, you just import. That framing explains why the project has over two thousand stars and one hundred open issues, because there is no annotation to add and no wrapper to wrap.

There is a commercial companion worth naming so you do not conflate the two. On-device or Live Script Reload is a separate paid extension asset, sold through the Unity Asset Store, and the open source repository is the editor-time version only. The parent project reports selling over a thousand copies of the editor tool in a single February, which briefly put it in the number one best-selling slot and kept it on the first page of that chart for most of the month.

Installation: a unitypackage or a git URL

There are two documented paths, and both are short. The quickstart has you download the latest release unitypackage and import it into Unity. The alternative uses the package manager: open Window, then Package Manager, then the plus button, then Add package from Git url, and point it at the repository's Assets path. Both routes land the same code inside your project.

The branch form of that git URL is the detail that matters if you are evaluating rather than simply installing. The README shows that you can append a branch or commit name to pull something other than the default head, using a feature branch as the example, so a reviewer can try unreleased work against a real project without touching their default branch. That is a small thing, but it is the difference between evaluating a release and evaluating a commit.

The documented support matrix is narrower than most Unity plugins and worth reading literally, because it says tested rather than supported. It lists Windows, Mac with the Intel editor version only, and Linux, then names Unity 2019.3, 2020.3, 2021.3 and 2022.2 as the tested versions. The releases then move the floor in the other direction: version 1.8 dropped official Unity 2019 and 2020 support while adding Unity 6 support. So the tested list in the README and the release history are describing different things, and the newer release note is the more recent statement of where support stands.

One-off custom code on hot reload

Reloading a method body is the common case, and the tool covers a second one that is genuinely useful: running your own code at the moment of a reload. If you add a method with one of two recognised names to the script you changed, it executes during the hot reload. The instance form runs on the existing object, so it can reach that object's state through this.

void OnScriptHotReload()
{
    //do whatever you want to do with access to instance via 'this'
}

The static form runs without an instance at all, which the comments point out is the useful case when you have added a brand new type or when you simply want a one-off action such as reloading the scene or calling a test function.

static void OnScriptHotReloadNoInstance()
{
    //do whatever you want to do without instance
    //useful if you've added brand new type
    //or want to simply execute some code without |any instance created.
    //Like reload scene, call test function etc
}

The static entry point appeared in the 1.5-rc1 release, which also brought package import straight from GitHub, a fix for hot reloading internal interfaces, and better compile error reporting. That combination tells you something about the project's direction: it was moving toward running a real editor-side rewrite pass over your code, which is exactly why the limitations list below is as long as it is.

The performance story is honest and small

The performance section is short because the honest answer is short. This is a development tool, not something you ship: the compiled result exists only in the editor, so none of it reaches a deployed Android APK or a standalone Windows build. The README says as much in plain terms about the on-device variant being a separate paid extension asset.

The one real cost is memory, and specifically the additional memory used by recompiled code. The stated threshold for noticing is blunt: it will not be visible unless you make hundreds of changes in the same play session. In other words, for ordinary iteration the tool is effectively free, and for a marathon session you are trading memory for the state you never had to rebuild.

What that budget does not pay for is compatibility. The limitations section is where the real engineering trade-off sits, and the project does not soften it.

Limitations you should read before adopting it

Five limits are documented with enough specificity to plan around.

Generic methods and classes will not be hot reloaded. This is the hard stop, and the stated workaround is to move that code into a non generic class or method. If your architecture leans on generics in the code you iterate on most, that is a structural constraint rather than an inconvenience.

New public methods only work as private ones. A method you add while the session is live will be usable by the code that changed, but not called from outside the class.

New fields are labelled experimental, and the behaviour is specific: code outside the class cannot call new runtime fields, and a field appears in the editor only if it has been used at least once. Version 1.5-rc1 records allowing new fields as an adjustable editor option, which frames the maturity honestly.

Heavy use of nested classes and structs produces more compilation errors, so deep object graphs in the hot path work against the tool.

Mac Silicon is not supported, and this is the failure mode most likely to waste an afternoon. On Apple Silicon the logs look clean and the change simply does not apply at runtime. A silent failure with a happy log is worse than an error, so on a Silicon Mac you need a second check before you trust any reload.

The project points at User Defined Script Overrides as the route around most of these, though that means reading the documentation rather than guessing.

Troubleshooting that maps to specific causes

The FAQ section in the README is unusually targeted. Auto compile stopping on its own is explained as a preference change rather than a crash: the tool probably flipped auto-reload to disabled and nobody noticed. Two remedies are given. Reload manually with CTRL+R, or go to the Asset Pipeline section of the editor preferences and set Auto Refresh to Enabled Outside of Playmode, which lets the tool work during play mode while Unity still does a full recompile when you hit stop.

That distinction is the whole design in one sentence. You are not replacing the full compile, you are deferring it to the point where Unity would do it anyway.

Two other documented quirks deserve to be known in advance. An import error naming the ImmersiveVRTools.Common.Runtime.dll assembly is described as occasional, more likely when upgrading between versions, and harmless, because it resolves once you enter play mode. And upgrading versions can leave example scenes with pink materials, which the answer traces to the Point shader reference inside a prefab rather than to anything you changed.

One note on how releases have moved: 1.6 in late 2023 brought unit tests, selective file and folder watching, Odin support and a custom file watcher on Roslyn 4.6.0, while 1.8 in late 2024 added Unity 6 support and improved extension method rewriting. Both entries point the same way, toward a rewrite pass with real test coverage behind it, which is what makes the generic and field limitations worth tracking across versions rather than treating as fixed.

Editorial conclusion

FastScriptReload earns its place in a Unity workflow where you spend more time tuning behaviour than rebuilding a domain. The workflow it describes, play, change, see the result, is the one every Unity developer wants and no stock editor gives you inside a running session. Read the limitations section before you commit, because generics will not reload at all, new fields are labelled experimental, and the Mac Silicon editor fails silently. The first thing to verify on a new machine is that a change actually applies: press play, edit one method body, and watch for the reload log. If nothing happens, the cause is usually the Auto Refresh preference sitting on disabled rather than a fault in the tool. On a Windows or Linux editor the fit is straightforward. On an Apple Silicon Mac, plan for full recompiles until a future release changes that.

Frequently asked questions

Official sources

1. handzlikchris/FastScriptReload on GitHub
2. License: MIT
3. Project website
4. README
5. Releases