Starting with Unity 2019.1 it is possible to create patches for Android builds that only include the updated version of the code we modified. This aims to reduce the iteration time when developing for Android where we are normally forced to: build, transfer and then install the application everytime we want to see on a device the result of changing a single line of code.

Right away in the documentation we can see the limitations of the patches. The first one being:

Note: If you change the layout of a script attached to a GameObject, such adding new public variables, the Script Only Build and patching process will fail.

Additionally it can only be done with development builds, and the patching is done directly into a device with the full build already installed. If we change the build path the build process will also fail, and an error will appear in the editor asking us to perform a full build.

I gave this feature a try to see how well it works and to test for myself how it could actually speed up our development workflow.

Through an editor script and the BuildPipeline class 10 full builds were created, transferred and installed one after the other, measuring every time how much time the whole process took. A large image was added to the project to have a significant amount of data assets in the build besides the code. The resulting apk was around 70MB in size.

Similarly, 10 patch builds were created, transferred and installed taking care to modify the code between each build. A preprocessor symbol was added/removed between builds to change a single line of code in the class ScriptToModify so the editor actually has something to patch.

From the measured times we can see that in my setup the full build test took in average 73.3 ± 5.18 seconds, in comparison the patch build test took 33.93 ± 0.78 seconds. There is a clear difference between the time we have to wait to make a full build (which includes all the heavy data) and a patch build where only a patch for the code is built, transferred and applied on the device.

Using Android patch builds seem like an easy way of improving development iteration times, especially for small projects/teams where the overhead of moving to AssetBundles may be too cumbersome. However, we need to keep in mind the type of modifications we made on the project, since slightly changing the name of a behaviour’s field will make the process fail and we might be forced to perform a full build and expend more time overall.

The code for this test is available in this repository.