Search Unity

“In the Labs” is a series of blog posts that put focus on features that have been prototyped internally but are experimental in nature and are not guaranteed to be included in Unity.

In this issue of “In the Labs” we’ll have a look at an experimental feature that introduces user-defined custom build configurations. The idea is that custom defined build configurations replace the fixed set of target platforms, and the things you used to be able to specify per target platform can be specified per build configuration instead.

This way it’s possible to specify more than one build configuration for the same platform; for example one for iPhone and one for iPad, or one for regular desktop builds and one for Steam builds. These are not built-in options to choose from; rather each build configuration is defined and named by the user and there is no limit to the number of them.


Current build window to the left and prototyped build window to the right.

Support for inheritance

The custom build configurations support inheritance. One build configuration can inherit from another and only override select player settings.

This means it’s possible to define custom abstract parent build configurations, for example one shared by all builds for touch devices. All player settings common to these builds can be defined there once and for all instead of having to be duplicated for each build configuration.

Build configurations can either be for a specific platform (e.g. iOS) or be abstract. To keep inheritance rules simple, only abstract build configurations can have child build configurations.

Player settings integrated into build window

For each custom build configurations it’s possible to specify specific player settings. As part of making the player settings be per build configuration rather than per platform, the feature also includes the player settings inside the build window.

The build window and player settings always had a special connection apparent from the button in the build window to open the player settings, and the new build window takes it a logical step further and includes them directly in the same window. The new build window shows the build configuration tree as a replacement for the Platform list, and has tabs for Build Settings, Player Settings, and Scenes in the build, for each build configuration. Like player settings, each build configuration can also override (or not) the list of scenes that are included in the build.

Texture overrides

In Unity it’s currently possibly to specify per-platform overrides in a texture, where the texture max-size or format can be overridden for certain platforms if desired. While not yet implemented in our experimental prototype, custom build configurations would provide the ability to specify these overrides per build configuration instead.  This would allow for example for a custom iPad build configuration to specify a higher max-texture sizes than in the abstract parent Touch Devices build configurations. Naturally each override is still optional.

Build config defines

Unity includes the ability to write code that’s only compiled for certain platforms using platform defines. Another feature that’s not prototyped yet, but has powerful potentials, is the use of build config defines, so each custom build configuration can have associated code that only applies for that configuration.

Simple defaults

By default when creating a new project, a set of build configurations are created out of the box. One configuration is created for each platform, and they all inherit from a common base build configuration. This means that the workflow can be just as simple as it is currently in Unity, and the extra flexibility (and complexity) that build configurations offer is entirely optional.

If you had access to custom build configurations, what would you use them for that you can’t do today? Or what workflows would become simpler for you?

47 replies on “In the Labs: Custom Build Configurations”

“To keep inheritance rules simple, only abstract build configurations can have child build configurations.”

What’s simple about this, compared to just not having this arbitrary restriction?

I like you to think again about this statement. What problem in which use case does this solve?

If you don’t require this restriction, you not only get a simpler to understand system (less rules), you could also rename “abstract” to “hide in configuration UI” and be done with it. Even easier to understand what it really means.. ;)

(Not all build system configurators are also programmers who have heard of abstract types)

I’ll use it for building server scenes of the game, client scenes and other multiplayer/MMO related exes which need to be made.
We usually have a lobby.exe, several server.exes for different parts and clients for different platforms.
MS Build and custom coding saved us with the help of current build functionality in unity but it’s good to have something graphical like this.
For almost all project we have custom build scripts.

To make full use of asset pipeline customization it would also be great if the texture importer accepted compressed textures (PVRTC, DXT, ETC1, … and maybe the AFT format).

It is a real handicap when all conversions are handled under the hood. It does not only limit us in the way we store and handle assets, it also limits us when trying to use other conversion related quality features like dithering or other channel processing options. We are e.g. splitting the alpha to a separate texture only when using ETC1 compression and we assemble other target platform specific textures with aux channels.

The same applies to audio compression, like doing a volume normalize on a temp version of the original asset followed by the actual compression (maybe also done with a standalone tool) without modifying the actual source assets.

I am quite interested in the Steam build. What is it? What does it do? Will this make it easier to make Steam games? So many questions…

I like it :)
But, “These are not built-in options to choose from; rather each build configuration is defined”. I strongly recommend to have “some basic” custom build options like “iPhone” , “iPad” , “Steam”, etc…

What about batch building of a set of configs. So that you can set up an overnight build of all versions of an app (much like the cloud build does). I would like to set up a build server so that I can simply have it look at a directory and do a build of it at a set time each night, reporting any errors back to me via an email.

PLEASE, DON’T FORGOT of this -> be able to include/remove scene files for a specific build configuration. it’s really ultra important!

I agree! ALSO VERY IMPORTANT: Separate Assets Folders per configuration! My iPhone App may have smaller textures than my iPad app. My Amazon Marketplace version needs Amazon’s Game Circle libraries and is not allowed to include the google play libraries needed for my Google Play version (yet both are Android). Maybe my free version of the game has ads (and third party sdks to show them etc) but my paid version shouldn’t not include all that extra junk. Etc, etc.

A step in the good direction, but before it is useful it indeed needs including/excluding assets.

We use a custom build script that is executed by a build server, is the new build settings system equipped for headless builds?

Also, we target the web player and build many asset bundles, I don’t see the tool helping out on that.

Very nice! I have custom build scripts for almost every project I do now. It’ll be nice to have something built-in that I can use for my custom builds.

For those of you who need some of these more advanced build features, please take note: As of today, Unity Cloud Build now supports:

– making development / debug builds
– using your own pre- and post-export methods
– custom scripting defines
– custom scene lists

If you haven’t already, consider signing up for the beta:

People are doing this already, but with 3rd party scripts, it would be nice to have a more powerful builtin feature.
First I`ll use it for development builds and live builds, then split by platform and input types.
A nice addition will be to have other project settings like Input dependable by custom build.

hi, Make Building to all platforms OS independent. It means I can build to all targets on windows or macos. Currently to build for IOS I must use macos, to build for win8 I must use Windows PC. it’s really bad.

this is an Apple Requirement, not a Unity one. (Apple says “to dev for iOS, be an a Mac or get lost”)

We have now like in one Unity Project more sub projects that we need to build. Current build workflow does not allow us to have multiple builds ouputs (different scenes for each project, different splash screen, different settings) With your prototype I can see it will be possible to have one Unity Project with different build projects ouput. Like one unity project can create more built apps. Thank you for this.

Please make sure you add Post and Pre editor scripts functions that we can tag with an attribute.

I really need “pre” events to add compiler defines etc.

As new build targets become available, the need for this feature grows.

There are multiple Unite videos where the guys from Owlchemy Labs break down the need for this feature and how they accomplished this functionality internally.

Until now, I was thinking that I’d have to roll my own solution. I really hope Unity provides a built-in mechanism for this.

And integrating it with Unity Cloud Build would be even better.

Awesome! We build a similar tool with editor scripts to deal with the different Android app stores (Amazon, Google Play, Ouya, Stores in China,…). Would be great to get all the Unity features with custom build configurations.

Sounds great as a first foundation to support multiple target platforms within one project. We definitely need more:

1. Ablilty to swap and exclude resources (textures, sounds, …) per target going down to the material level so we can also replace materials and the actual shaders used.

2. Max texture size per target is not enough. We usually produce all graphics in HD and a per target/per texture downres factor would be more useful (1:1, half, quarter, …).

3. That team license should be a standard Pro feature of Unity, not a separate option we have to pay for. Having to pay to prevent hours of asset conversion is lame, after buying multiple Pro licenses and each individual exporter. Per target asset caching and version control are must have features.

Please also include a setting that exclude certain files from a specific platform. This is useful for things like opening cutscene video, which different platform uses different video format. I wish to use .mp4 for android, .mov for iOS but I don’t want both the files to be included into the app as its too big in size. Would be great if able to exclude the .mp4 video file from iOS platform, and exclude .mov from android.

Please integrate this into Unity. I have been mulling around ideas for an editor script to do this for a while now since it is critical for people targeting multiple stores under a specific platform. For example, Android builds can refer to low/mid/high performing phones, tablets, Amazon Fire TV, OUYA, GameStick … the list goes on and on and there have been many times where having specific defines for each platform would have saved me a ton of headaches and sped up my development. Also, the added benefit of having texture size overrides would be excellent in helping with keeping build sizes down on devices with more restricted hardware while not compromising the experience on higher performing hardware.

Still not enough. We use custom build pipeline, as we need to exclude some resources from build e.g. by putting them to Editor folder and then return them back.

That’s why this is still not the replacement for a custom build tool.

This is just great! When it will be available?

It will be very much useful if I can set my textures import settings per plataform (including mipmapping) .

Looks great. Combine this with a couple of additional build hooks (pre-build-starting, for example) and I’ll finally be able to have my team start using Unity’s build window again :)

This would be awesome… similar to build configurations in Visual Studio. Configure each of your builds / environments and flip the switch before you build.

We really need this in unity!

This would be fantastic to have built into Unity, especially if it was fleshed out some more.

For our Android build I’ve created a custom solution where the /Plugins/Android/ content is added during the build process, based on Preprocessor values. This means that I’m able to build with the correct plugins and AndroidManifest.xml that I need per platform, so I’m not using Amazon plugins and manifest data when building for Google (or even more exotic platforms that are even less compatible, where you need the switch the MAIN activity for example, so you have to use a different AndroidManifest file).

It would be great to be able to have this level of control and functionality built in, go for it! ;)

Our team has built something very similar to this and it has saved so much time and improved workflow. It would be fantastic to have this officially supported.

Agree completely with @ANOMALUSUNDRDOG

It would be really useful to have per-buildconfig Resources folders. This could even be done automatically based on folder name (ex /Resources-[BuildConfigName]/ or /Resources/[BuildConfigName]/). This is a very important feature that Unity is sorely missing right now.

This is a much-needed addition. Please don’t lock this one under the Pro licenses! Architecture-based platforms really no longer apply to modern development, an “Android” build could be going to three or four different marketplaces for example, each with different requirements, sometimes vastly different – controller-based 10 Foot Experience unconsoles vs 5″ touch screens.

As has been mentioned, to really work properly we need to be able to mark individual assets as belonging to different build configs. As it stands, we’re having to choose between bloated packages or manually maintaining multiple collections of assets.

I’d use it for sure. Custom defines would be sweet, e.g. for OUYA. This way my OUYA code would not be compiled when targeting other Android devices.

Well, as now I can only think of Android where I would need something like that (OUYA and mobile build). But if other developers can use it for other platforms too it’s nice.

Excellent! As the creator of Steamworks .NET this is definitely something that I and my users have been wanting.

The biggest thing that I would want from this is the build config defines that were mentioned.

Also a feature suggestion: be able to turn on/off certain Resources folders for a specific build configuration. Something like you can drag & drop which Resources folders you want added, or perhaps Unity looks for all Resources folders in your Assets folder and lets you check/uncheck which you want.

Same with scenes: be able to include/remove scene files for a specific build configuration.

This was the reason I bought Advanced Builder on the Asset Store. Build-specific defines, replace the art assets with high-res versions for newer phones but of same platform, builds to be released specific to a particular digital store (Amazon Appstore, Samsung store, Google Play, et al), etc.

Would love to see this in the official builds soon!

Comments are closed.