The two main ways of reducing the size of the player are by making proper Release build within Xcode and by changing the Stripping Level within Unity.
Since Unity 4.2 it is expected that final release builds are made using Xcode 4.x/5.x command Product -> Archive. Using this command ensures that build is made with release configuration and all the debug symbols are stripped. After issuing this command latest Xcode switches to Organizer window Archives tab (you can navigate there manually via Window -> Organizer menu). You will find there two very useful functions there: App Store size estimation and Distribution. Build size estimation function works pretty well, but it is always recommended to have some small extra margin for error when aiming for 3G download limit (which currently is 50MB).
Note: xcodebuild utility currently does not have proper equivalent of "Archive" command. If you rely on building for distribution on this tool you might consider passing -Wl,-S,-x extra linker flag to it.
The size optimizations activated by stripping work in the following way:
These levels are cumulative, so level 3 optimization implicitly includes levels 2 and 1, while level 2 optimization includes level 1.
Note that Micro mscorlib is a heavily stripped-down version of the core library. Only those items that are required by the Mono runtime in Unity remain. Best practice for using micro mscorlib is not to use any classes or other features of .NET that are not required by your application. GUIDs are a good example of something you could omit; they can easily be replaced with custom made pseudo GUIDs and doing this would result in better performance and app size.
Stripping depends highly on static code analysis and sometimes this can't be done effectively, especially when dynamic features like reflection are used. In such cases, it is necessary to give some hints as to which classes shouldn't be touched. Unity supports a per-project custom stripping blacklist. Using the blacklist is a simple matter of creating a link.xml file and placing it into the Assets folder. An example of the contents of the link.xml file follows. Classes marked for preservation will not be affected by stripping:-
<linker> <assembly fullname="System.Web.Services"> <type fullname="System.Web.Services.Protocols.SoapTypeStubInfo" preserve="all"/> <type fullname="System.Web.Services.Configuration.WebServicesConfigurationSectionHandler" preserve="all"/> </assembly> <assembly fullname="System"> <type fullname="System.Net.Configuration.WebRequestModuleHandler" preserve="all"/> <type fullname="System.Net.HttpRequestCreator" preserve="all"/> <type fullname="System.Net.FileWebRequestCreator" preserve="all"/> </assembly> </linker>
Note: it can sometimes be difficult to determine which classes are getting stripped in error even though the application requires them. You can often get useful information about this by running the stripped application on the simulator and checking the Xcode console for error messages.
An empty project would take less than 22 MB in the App Store if all the size optimizations were turned off. If you own an Advanced License (and therefore have access to the stripping option), the empty scene with just the main camera can be reduced to less than 12 MB in the App Store (zipped and DRM attached).
When publishing your app, Apple App Store service first encrypts the binary file and then compresses it via zip. Encryption increases ''randomness' of the code segment and thus makes it worse for compression. Check "Building for distribution" chapter above how to estimate App Store size before submission.
Page last updated: 2013-08-27