For faster iteration during development, Unity uses an incremental build pipeline that only rebuilds parts of the application if they have changed since the previous build. This includes build steps such as asset serialization, code compilation, data compressionA method of storing data that reduces the amount of storage space it requires. See Texture Compression, Animation Compression, Audio Compression, Build Compression.
See in Glossary, and signing. By default, Unity uses the incremental builds pipeline for both release and development buildsA development build includes debug symbols and enables the Profiler. More info
See in Glossary.
The incremental build pipeline also automates the Scripts Only Build feature. ScriptsA piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info
See in Glossary Only Build is therefore only available in the Build Settings window for the platforms that do not use incremental builds.
The incremental build pipeline works for both the Mono and IL2CPPA Unity-developed scripting back-end which you can use as an alternative to Mono when building projects for some platforms. More info
See in Glossary scripting backendA framework that powers scripting in Unity. Unity supports three different scripting backends depending on target platform: Mono, .NET and IL2CPP. Universal Windows Platform, however, supports only two: .NET and IL2CPP. More info
See in Glossary. Although, the output file structure changes depending on which scripting backend your project uses.
Unity supports the incremental build pipeline for the following platforms:
In some scenarios, it can be useful or necessary to create builds that don’t use the incremental build pipeline.
To create a clean, non-incremental, build:
In general, if expected changes are not present after an incremental build and you think there is a problem with the incremental build pipeline, create a clean build. The most common reason for this is when you implement or make changes to build process callbacks that affect assets.
Since the build process can’t know how a callback you’ve implemented affects an asset, it can’t determine how to rebuild the asset. Unity only regenerates files if the file’s dependencies change. This means if the callback modifies a file that Unity generates, and the file’s dependencies don’t change, the callback can apply modifications to an already modified file. For example, if the callback adds new entries to an Android App Manifest, and the dependencies for the Android App Manifest don’t change, the callback still adds the new entries, which results in an invalid file.
For development builds, if you change a callback or its input data and you want Unity to rebuild assets that the callback affects, create a clean build. For release builds, Unity rebuilds all assets so you don’t need to create a clean build. Examples of callbacks include:
Note: If you make changes to an asset, Unity rebuilds that asset when it builds the application. This also includes processing any callback that affects it which means you don’t need to create a clean build if you make changes to an asset, only if you make changes to a build process callback.