Unity has detailed MethodReload, an experimental feature that applies edits to tagged C# methods in a running Play Mode session or on a development build on a device, without a domain reload or a new build. A 22 October post on the Unity blog says it ships in the com.unity.pipeline package, currently version 0.7.0-exp.1, for Unity 6.0 and later. Unity demoed it on stage at Unite Seoul. The post claims it “turns a long wait into a matter of seconds, in the Editor and on device alike”, but gives no benchmark figures.
How a tagged method gets a new body
Developers mark a method with a [MethodReload] attribute. The method must be public and return void or IEnumerator, and the attribute has to be there before entering Play Mode or building. At compile time, Unity adds a short prologue to each tagged method. The prologue asks a registry whether a newer version exists. If one does, an interpreter runs it and the original body is skipped. Otherwise the compiled code runs as usual.
The interpreter is hand-written C#. Because it is ordinary C#, IL2CPP compiles it into the player along with the game. Unity says this is what lets MethodReload work on IL2CPP builds, which have no runtime that can load new code. A file watcher in Project Settings (Pipeline, Editor) picks up saved .cs files that contain the attribute. The Unity CLI can also push changes directly, for example with reload_file_editor_interpreter for the Editor or reload_file_player_interpreter to compile in the Editor and push to connected players. Players connect over the existing Profiler or Console link. According to the blog, no extra server or open port is needed in the player.
What MethodReload cannot reload
Only the body of a tagged method changes. Fields, call sites and type layout stay as compiled: “No new fields, no new classes”, as the post puts it. A reloaded body can call a newly written helper method, but that helper can’t be reloaded later until a full compile. Inside tagged bodies, Unity’s interpreter does not support:
async/awaitandTask,try/catch/finally,lock, LINQ query syntax andchecked;decimal,dynamic, reflection and threading types;ref,outandinparameters, ref returns and locals, multi-dimensional arrays and generic methods.
A Roslyn analyzer shipped with the package flags these cases in the IDE. On devices there is a further limit: IL2CPP strips code the game never referenced, so a reloaded body can only call UnityEngine or .NET members that survived the build. The push lists missing members as warnings, and code that reaches one anyway throws an exception. Interpreted methods also run slower than compiled ones. Unity says this cost applies only to tagged methods in development builds. Release builds contain neither the prologue nor the interpreter.
Coroutines need care. A tagged IEnumerator uses the new body only the next time it is started, so loops already running keep the old code. An [OnMethodReloaded] callback on live instances can restart them. While the watcher runs, Unity turns off asset auto-refresh, so other assets do not import until a manual refresh (Ctrl/Cmd+R). Stopping the watcher restores the setting.
Check the attribute name in your package version
The naming has moved twice in two months. The package changelog shows that version 0.6.0-exp.1 (31 August) renamed “hot reload” to “code reload”: [HotReload] became [CodeReload], the old attributes were removed, and user code had to be updated. That release also added the IL interpreter for IL2CPP players. Version 0.7.0-exp.1 followed on 10 September and moved the reload attributes into a separate Unity.Pipeline.Attributes assembly. Assembly definitions that referenced Unity.Pipeline for those attributes need the new reference. The 0.7 manual still documents [CodeReload], while the blog’s examples use [MethodReload], the Unity.Pipeline.MethodReload namespace and [OnMethodReloaded]. Teams trying the package should check which names their installed version actually exposes before tagging methods across a project.
The pipeline package itself is a local HTTP API that lets a CLI, CI job or coding agent run commands in a running Editor or development player. Unity first announced IL2CPP support for the reload feature in a 3 September forum post for version 0.6.
Where it fits next to Hot Reload tools
Unity’s post compares MethodReload with existing options. Hot reload packages from the Asset Store patch methods inside a running Mono runtime, support full C# and need no tagging, but cannot work on IL2CPP players. .NET Hot Reload in Visual Studio and Rider targets CoreCLR, not Unity’s Mono or IL2CPP. Unity’s own advice is that if most waiting happens in the Editor, the existing tools are mature. MethodReload is aimed at the case they don’t cover: changing behaviour on a phone or console development build without rebuilding and redeploying it. It is still an experimental package, and Unity says the process “may change in the future”.