Here at BonusXP, we have shipped two titles using the popular Unity3D engine. We developers can (and will!) debate the merits of various engines and technologies, but one of the great features of Unity is that it makes cross-platform development fairly straightforward. There are still annoyances in dealing with multiple platforms, of course. Some of these you can’t do much about, such as differences in how platform-specific APIs work, but there’s a Unity-specific annoyance with platform switching that we CAN work around: when you switch platforms in Unity it can often take a very long time. This is because Unity reimports assets for the new platform to account for the correct texture compression formats, and so on.

Toots is tired of waiting!

Toots is tired of waiting!

The Official Solution

Unity offers a solution for this in the form of the Cache Server, but this is an investment in terms of extra licensing fees and running a server, which hobbyists or small teams might not want to undertake. Its centralized nature is not necessarily ideal for distributed teams either.  It does has the advantage of sharing import burden across your whole team, though.  And it’s officially supported.

Our Workaround

All is not lost, however, if you don’t choose to use the Cache Server. The trick is to look under the covers at how Unity caches imported assets. These end up in a directory called Library within your project directory. When you switch platforms, the assets are reimported and the contents of the Libary directory are overwritten with versions for the new platform. So the trick is to preserve the contents of the Library directory for each platform you switch to instead of allowing it to be overwritten.

You could do this manually by renaming directories, but to make this convenient, we use a few scripts and the power of symbolic links. You simply put these scripts in your project directory, and then when you wish to switch platforms, you exit Unity, run the appropriate script, and then restart Unity. Note that the first time you do this for each platform, you’ll need to go into the Build Settings and switch Unity to the appropriate platform to get things set up. This will be a painful full import the first time, but subsequent switching will be very fast. In fact it will basically be instant unless there are new files since the last time you used that platform.

Mac OS X

Here are some example scripts if you run the Unity editor on OS X.  Don’t forget you’ll need to make the scripts executable via chmod +x.  You’ll also need the “pidof” utility installed on your system.  The easiest way is via a package manager, which you are probably already using if you are a developer on OS X.  For homebrew, which is what I use, it’s simply “brew install pidof”.  I’m sure macports, etc. have a package for it as well. (Or you could come up with your own way to detect if Unity is already running.)

The main script:

And then for each of the platforms you wish to use, you add simple scripts that invoke the main one, like so:


Here’s our solution for using the editor on Windows.  Note that symbolic links have some strange issues on Windows with access control.  You need to be a user who has permission to make symlinks and is NOT an administrator.  Or if you are an administrator, you need to open an elevated command prompt with “run as administrator” and run the scripts from that instead of a regular command prompt.  (See more info here.).

The main script:

The per-platform batch files look like:

Wrapping Up

You can easily add additional platforms in the same way. If you make separate Android builds using different texture formats, you will want to consider each of those a separate “platform”. For example “androidETC”, “androidPVRTC”, “androidDXT”, etc.

Hopefully this will save you some precious development time.  It has certainly made our cross-platform Unity workflow a lot more efficient.