Unity 5.3.x build size increase FAQ

Recently we are seeing number of questions scattered around forums regarding build size increase when building iOS applications with Unity 5.3.x. This post aims to clarify some aspects of it in single place.

1. My application build size increased by 130-150 MB after switching to Unity 5.3.x. What's happening?
We enabled Bitcode support as default for iOS projects. It's new Apple's technology, which allows them to re-optimize your application after submission to the App Store. Though it requires to send way more information about your application as part of submission. When your application gets processed by App Store this additional information will be stripped away from your package and won't increase final download size for your users. This technology is already mandatory for tvOS and watchOS applications, so we are enabling it for iOS to help you prepare ahead of time to make sure that your applications are fully compatible when/if it becomes mandatory for iOS. Description of Bitcode technology is available at: https://developer.apple.com/library...istributionGuide/AppThinning/AppThinning.html.

2. How can I measure Bitcode size added to my application?
You should make a build of your application, locate where Xcode puts built files and navigate Terminal.app to that folder. Then just run:

otool -l <your_app_name>.app/<your_app_name>[/code]

Inspect its output and look for something like "segname __LLVM":

cmd LC_SEGMENT
cmdsize 124
segname __LLVM
vmaddr 0x00fac000
vmsize 0x07ce0000
fileoff 15564800
filesize 130940928

The "filesize" attribute is your Bitcode size. Note, if you have build for more than one architecture there could couple of such segments in your app.

3. How can I disable Bitcode for my test builds made by automated build system?
To automate this task we recommend adding Editor build post-processing script:

Code (CSharp):

1. [PostProcessBuild]
2.     public static void OnPostprocessBuild(BuildTarget buildTarget, string path)
3.     {
4.         if (buildTarget == BuildTarget.iOS)
5.         {
6.             string projPath = path + "/Unity-iPhone.xcodeproj/project.pbxproj";
7.  
8.             PBXProject proj = new PBXProject();
9.             string nativeTarget = proj.TargetGuidByName(Xcode.PBXProject.GetUnityTargetName());
10.             string testTarget = proj.TargetGuidByName(Xcode.PBXProject.GetUnityTestTargetName());
11.             string[] buildTargets = new string[]{nativeTarget, testTarget};
12.  
13.             proj.ReadFromString(File.ReadAllText(projPath));
14.             proj.SetBuildProperty(buildTargets, "ENABLE_BITCODE", "NO");
15.             File.WriteAllText(projPath, proj.WriteToString());
16.         }
17.     }

More example code is available here: https://bitbucket.org/Unity-Technol...tegration/Misc/UpdateXcodeProject/?at=5.0-dev

4. Testflight download size looks quite bigger that I expected. Any advise on it?
Testflight test build download size does not really represent how much your app will take on actual App Store, because they are going through very different preparation pipelines. It's not unusual for testflight downloads to be bigger than App Store submission size, because they might include debug symbols and other additional information.

5. Where can I read more on iOS application size analysis?
Please check out this forum post: http://forum.unity3d.com/threads/il2cpp-build-size-improvements.322079/

Edit: added sample code for disabling Bitcode in an automatic way

 

Thanks for the post, It was informative but did not solve my problems with cloud build.

As expected, upgrading from 5.2 - 5.3 pushed my development build from 31MB - > 219MB's. Each launch of the app gets stuck at the splash screen.

I tried implementing your solution to disable bit code. There were problmens:

This line of code calls a method that doesn't seem to exist:

string projectTarget = proj.ProjectGuid();
​

but since the variable assigned is never even used I just got rid of it.

Pushing this up to my cloud build repository had no effect.

Relying on the [PostProcessBuild] attribute instead setting up cloud build to call a specified postprocess seems to not work. This method exists in my editor folder, in a static build settings class. ​

The signature of OnPostprocessBuild is different from what cloud build expects.

No trailing parenthesis, and it can't have the same name as your Pre-Export method! This method must accept a string parameter, which will receive the path to the exported Unity player (or Xcode project in the case of iOS).​

Any idea's how I can get this to work? My app works perfect when I manually build it locally, but spikes in size when build with cloud build and crashes at the splash screen.

 

Thanks David. Had to change one thing:

Code (CSharp):

1.  
2. BuildTarget.iPhone
3. to
4. BuildTarget.iOS
5.  
6.  

Even after that still got the signature error:




Here was a previous error:

 

@David Berger

I see two issues with your example code.

1.
BuildTarget.iPhone != BuildTarget.iOS
Meaning the statement on row 42 will allways be false when cloud build.
I event get a compile error if I have BuildTarget.iPhone in my code.
2.
Is PBXProject different from Xcode.PBXProject ? I get error if I use Xcode.PBXProject.
Can we see the entire class? Including the usings in the beginning.


Edit: Ops, Costello beat me to it.

 

@zworp: In regards to #2, PBXProject is under the following namespace that can be surrounded with a directive to only include for iOS builds:

Code (CSharp):

1. #if UNITY_IOS
2. using UnityEditor.iOS.Xcode;
3. #endif

For #1, I'm pretty sure that the build target enum changed and iOS is now the proper build target to use.

 

After trying the various approaches I read in several posts here's what I believe is the correct solution:

Code (csharp):

1. [PostProcessBuild]
2.     public static void OnPostprocessBuild(BuildTarget buildTarget, string path)
3.     {
4.         if (buildTarget == BuildTarget.iOS)
5.         {
6.             string projPath = path + "/Unity-iPhone.xcodeproj/project.pbxproj";
7.             PBXProject proj = new PBXProject();
8.             proj.ReadFromString(File.ReadAllText(projPath));
9.  
10.             string nativeTarget = proj.TargetGuidByName(PBXProject.GetUnityTargetName());
11.             string testTarget = proj.TargetGuidByName(PBXProject.GetUnityTestTargetName());
12.             string[] buildTargets = new string[]{nativeTarget, testTarget};
13.  
14.             proj.SetBuildProperty(buildTargets, "ENABLE_BITCODE", "NO");
15.             File.WriteAllText(projPath, proj.WriteToString());
16.         }
17.     }

The main problem I had was the

Code (csharp):

1. proj.ReadFromString(File.ReadAllText(projPath));

being placed at the wrong spot. It makes sense to call this method right after the PBXProject object creation so it's populated with the correct project's datas.

I went from 145mb to 14.2mb on a near-empty project.

Of course, as stated by Mantas Puida, it will have no impact over the final download size but it can help you approximating the final build size of your game.

Hope that helped.

 

Thank you!
This version worked for me.

Hope Unity will update the blog post with a working example.

 

This worked for me but only when I build locally. When built through cloud build the app freezes at the splash screen. Both the cloud build and the manual build are on the same commit. I'm getting no error / warning in the cloud build logs.

 

I doubt it has anything to do with cloud build. The postProcess just disable bitcode so I don't see any reason for your project to freeze at the splash screen.

Your best shot is to get some kind of reporter within your game to check for any error at runtime. If you are stuck on Unity's splashscreen it might not work as it's too early in the process but it's worth a shot.

Maybe we should continue this discussion on another thread?

 

Hi,

So i have been making iOS builds of my game using latest unity (5.3.2) and Xcode 7.2 with bit code enabled to true. The app size was 69.8MB. Now with CloudBuild the IPA became 283.9MB. I do agree that bitcode increases app size but same setting on my machine gives 69.8MB and cloud build is 283.

In cloud build log i did notice one thing
[Unity] WARNING: PVRTC texture format is not supported, decompressing texture

We use PVRTC4 bits for almost all texture since its the best format for IOS. Is there an issue with Unity Could to understand this format?

I guess cloud build is un-compressing all textures which results in huge app size increase

Edit:
http://forum.unity3d.com/threads/io...-format-not-recognised-by-unity-could.387725/

 

Exception: ExtractAssemblyTypeInfo: Failed to process Library/ScriptAssemblies/Assembly-CSharp.dll, System.ArgumentException: An element with the same key already exists in the dictionary.
at System.Collections.Generic.Dictionary`2[System.UInt32,System.UInt32].Add (UInt32 key, UInt32 value) [0x0007e] in /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:404
at Mono.Cecil.MetadataSystem.SetReverseNestedTypeMapping (UInt32 nested, UInt32 declaring) [0x00000] in <filename unknown>:0
at Mono.Cecil.MetadataReader.AddNestedMapping (UInt32 declaring, UInt32 nested) [0x00000] in <filename unknown>:0
at Mono.Cecil.MetadataReader.InitializeNestedTypes () [0x00000] in <filename unknown>:0
at Mono.Cecil.MetadataReader.InitializeTypeDefinitions () [0x00000] in <filename unknown>:0
at Mono.Cecil.MetadataReader.ReadTypes () [0x00000] in <filename unknown>:0
at Mono.Cecil.ModuleDefinition.<get_Types>b__8 (Mono.Cecil.ModuleDefinition _, Mono.Cecil.MetadataReader reader) [0x00000] in <filename unknown>:0
at Mono.Cecil.ModuleDefinition.Read[ModuleDefinition,TypeDefinitionCollection] (Mono.Cecil.TypeDefinitionCollection& variable, Mono.Cecil.ModuleDefinition item, System.Func`3 read) [0x00000] in <filename unknown>:0
at Mono.Cecil.ModuleDefinition.get_Types () [0x00000] in <filename unknown>:0
at UnityEditor.AssemblyTypeInfoGenerator.GatherClassInfo () [0x0001e] in C:\buildslave\unity\build\Editor\Mono\BuildPipeline\AssemblyTypeInfoGenerator.cs:392
at UnityEditor.AssemblyHelper.ExtractAssemblyTypeInfo (BuildTarget targetPlatform, Boolean isEditor, System.String assemblyPathName, System.String[] searchDirs) [0x00066] in C:\buildslave\unity\build\Editor\Mono\AssemblyHelper.cs:319
UnityEditor.AssemblyHelper.ExtractAssemblyTypeInfo (BuildTarget targetPlatform, Boolean isEditor, System.String assemblyPathName, System.String[] searchDirs) (at C:/buildslave/unity/build/Editor/Mono/AssemblyHelper.cs:323)
UnityEditor.HostView:OnGUI()

 

@Mantas Puida
I create a empty project and build to xcode, there is a file named libiPhone-lib.a which size is 1.1G! And I archive this xcode project,I get a ipa with 560M. I uploaded a ipa with 650M early, the down load file size is 320M(on iphone)! So that means even I create a empty project, the down load size would be over 200M! What can I do to make my pack smaller? I aways make sure the Strip Engine Code is checked.
My build have to include ARMv7&ARM64.If I choose ARM64 only(or Mono2),I can't run app on device from xocde. And if I choose ARMv7 only, I can't upload at all because apple require ARM64 be included. LibiPhone-lib.a's size always be 1.1G with IL2CPP(no matter ARMv7 only or ARM64 only),but Mono2 will change the size to 500M(mono2 not include ARM64).

 

I created empty project with Unity 5.3.4p1. Archived it in Xcode 7.3 and exported with distribution profile for App Store deployment and did following analysis..

• IPA size was: 159MB (Unity-iPhone.ipa)

Then I extracted it and got following folders:

• 18MB BCSymbolMaps (these are symbol files supporting Bitcode, won't be delivered to end user)
  
• 243MB Payload (includes game assets, extra files and executable, which was 238M)
• 58MB Symbols (these are symbol files, won't be delivered to end user)

Now I had to analyze Payload, which was mostly executable + standard engine assets. Since assets were only ~5 MB, I won't dig into that, but rather focus on executable. I analyzed it with otool, by running it twice: 1) otool -arch armv7 -l exec_name, 2) otool -arch arm64 -l exec_name. Then I checked included segment sizes:

1. armv7:
   1. TEXT segment (code): 7.5 MB
   2. DATA segment (various static fields for code and il2cpp metadata): 0.3 MB
   3. LLVM (Bitcode) segment: 111.1 MB (will be stripped by Apple servers and won't be delivered to end users).
   4. LINKEDIT (linking with dynamic libraries) segment: 0.9 MB
2. arm64:
   1. TEXT segment (code): 8.4 MB
   2. DATA segment (various static fields for code and il2cpp metadata): 0.5 MB
   3. LLVM (Bitcode) segment: 110.2 MB (will be stripped by Apple servers and won't be delivered to end users).
   4. LINKEDIT (linking with dynamic libraries) segment: 0.8 MB

Exec size without Bitcode for armv7 is 8.7 MB and for arm64 it is 9.7 MB.
Total exec size without Bitcode: 18.4 MB
Estimated installation size (exec + assets): 23.4 MB
Expected download size without app thinning : 1.25 MB (compressed assets) + 15.9 MB (TEXT segment, which doesn't compress well because of encryption) + 0.5 MB (DATA+LINKEDIT, they compress pretty well) = 17.65 MB

 

hi @Mantas Puida , thanks a lot for that,

are you basically saying that the reports of large file sizes, are essentially wrong? ie, once the apps are ACTUALLY delivered to iTunes users, Apple does NOT deliver the ridiculous bitcode nonsense and the size returns to conventional values?

Please explain, and thanks.

 

Another straightforward question, @Mantas Puida .. when you upload finally to iTunes (either for TFA use or for actual submission of a new version),

quite simply you can check "off" uploading the bitcode crap.

I'm surprised this hasn't been mentioned (often) in this whole discussion.

What's your take on that? Thanks.

 

Even if bitcode adds a lot to your executable file, it does not represent your final ipa size (the one that your users will download). The best and reliable way to check your final ipa size is to upload it on Testflight.

"Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store."
​

You can check off bitcode or simply disabling it for now and that will work...for now. In the future Apple will probably make it mandatory so sooner or later you will be forced to let it on.

 

Yes, that's correct, the whole point of this discussion is that Bitcode does not increase final (user facing) download size of your app. Submitting Bitcode with your builds early will ensure that you won't get surprises when this becomes mandatory (as it is already for tvOS).

 

Testflight doesn't represent your download size reliably, because it does not contain encryption (which makes download bundle appear smaller), also it might include debug symbols for better crash reporting (which makes download bundle appear much bigger).

 

You're right, I shouldn't have said reliable but I find Testflight to be the best tool to get an approximation of your build size. Once you submitted for real you'll know how much increase you can expect from your binary. Once you know that you can know more or less how far you can get on your binary size.

Of course it may change but unless you make major changes to your binary it shouldn't double unexpectedly.

 

Say @Mantas Puida , even as an iOS dev I'm a little unclear, if you turn OFF debug symbols on final submission for a live app (nothing to do with TFA), in fact does that make the final download size for the user, smaller?

Or am I on the wrong track?

And thanks for your Bitcode explanation just above.

 

No, it should not affect download size. Debug symbols are kept on servers to sybolicate crash reports coming from users.

 

thanks for all the excellent info, @Mantas Puida

BTW is that fan art from Warrior Cats?!

 

Hi guys. I'm having the same problem, the app size in the app store is WAY too big, in comparison with the .ipa file. I've seen here that some of you found increases of +100-200mb or something like that, but in my case, my .ipa went from 84mb all the way to 1.9Gb. Insane.

I've built the project with Unity 5.3.3, and archieved it with Xcode 7.3.1. For some reason, I couldn't upload the app to the app store via xcode ('try again later' error...), so I exported the .ipa file to upload it via Application Loader. I unchecked the "use bitcode" checkbox. The result is the same, it weights 1.9gb in the app store. Here's the chart.



I've little experience with xcode and uploading apps to the app store (this is the second one that i get to the app store, I didn't have that problem with the first one, which was NOT made in unity), so I'm a bit lost on how to handle the problem. I've been reading this thread but I culdn't find a solution.

Thanks for your help.

 

Not sure which language it is, but it sounds like first column is estimated App Store download size and second column is installation size on device when app is downloaded and extracted.
Probably you have some big file that compresses very well (or maybe some texture with very large areas filled with solid color). You can use some advanced zip app to inspect ipa file and see file sizes / compression ratio inside the package.

 

Where this menu, I wish to see for my own game..

 

@Mantas-Puida Thanks I'll check that out. It's spanish btw

@MrEsquire You can access this menu in the activity tab, where you have all your builds, just click on the build number, and that opens the "Build details", where you can see your app size and a link that says something like "app size in App Store". Hope it helps!


EDIT: @Mantas-Puida I've unziped the file, the first thing that stood out to me is that while the ipa file weights about 77mb, the extracted folder weights 1.7GB, I guess that this "extracted folder" is actually what is installed in the device, am I right?

So, i see some files like "sharedassets1.assets.resS" with sizes like 800mb or 300mb, but I don't know what to do with that information. I guess that this file are a bunch of my assets compressed, and that I should use another compression method for my sprites or something like that. Am I on the right track?

I don't have textures in my app, it's a 2D game that uses only sprites.

Another piece of information that might be useful, is that my unity project size is about 2.5GB, Assets folder is about 370MB but the Library folder weights 1.77GB, could the problem be the Library folder? Or it has nothing to do with the whole thing.

Thanks a lot.


EDIT 2:
I've shrinked a little bit the size of the app, from 1.9gb to 1.5gb. What I did was deactivating the "Generate Mipmaps" option on several sprites that I forgot to, now I don't have any sprite with this option checked. What I have tough, is a lot of NPOT sprites, could that be the problem?

 

Hey,

I'm aware of the several topics about size etc. However my problem doesn't seem to be reported properly:
my IPA generated by Xcode (in release mode via Archive) is 60 Mo. Once uploaded on the App Store, it's more than 300 Mo to download (using latest Unity version).

I read that TestFlight IPAs size don't reflect the final size on the Apple Store. But unfortunately, my app is live and it shows 300 Mo. It downloads 60 Mo, but on disk uses 300Mo and so in the App Store shows 300 Mo. This is problematic.

For your information, Bitcode is NOT enabled. On Android the APK is 60 Mo too, and 80 on disk. What I'm missing? I saw some topics about stripping saving some Mos, but here there are 200 Mo coming from nowhere...

 

It sounds like your assets are taking these bytes. You could used editor log to identify these assets specifically: https://docs.unity3d.com/Manual/ReducingFilesize.html

 

@Mantas-Puida @David Berger many thanks for the above, it was really helpful. In TestFlight I see a report of around 396Mb download and 1.14Gb uncompressed. On examining the app with otool, looking for segname __LLVM I find ~300Mb of files that look to be bitcode as described above. When I try a Mono2x build of the app I see 38Mb for the executable, which seems more realistic than the 301Mb exe that I'm seeing with iL2CPP. My raw graphics size is around 380Mb, which needs to be optimised but which has been taken account of. There still seems to be a fairly large size discrepancy between what I can account for in the app and what TestFlight is currently reporting. Is the reporting tool in TestFlight likely to be that far out?

 

TestFlight also includes debug symbols, which might take a lot.

 

Ok so coming back. I've enabled Bitcode and use the latest version of Unity 5.4.2 and Xcode 8.1.
For information, my app on Android is 80 Mo on device with a 60 APK. Without Bitcode I got a 60 IPA and then 300 Mo in the store. Now with Bitcode enable I've a 200 Mo IPA (doesn't sound wrong here) but a 400 Mo estimated install file... This is crazy!

 

Ohhh Really @aymeric ?
I am worried for it then.
My Build is 13MB APK and 37MB on Device
23MB ipa but 134MB on device.
Please suggest what can I do ?

 

Hi @ad_adnan, do you have Bitcode enabled in Xcode?
For me it's still not resolved... also it's crazy the lack of communication from Unity around this issue!

 

Hi @-Aymeric- Yeah I do have bitcode enabled.
Yeah the problem isn't solved for me. The worse part is that the build size is different on different devices. It's 179MB on my 6S, 137MB on other test devices. The android apk is mere 13MB and 37MB on device.
Strangest thing I have ever come across. I have tried almost everything.

 

I'm facing the same problem but with a huge discrepancy. My apk (Android) size is less than 100 MB but the iOS version is 1.2 GB. I've tried some things suggested in the forum, but nothing solved the problem. Any Unity team help?

 

How you measure your iOS size? How your Editor.log asset sizes look like for iOS build (as described in https://docs.unity3d.com/Manual/ReducingFilesize.html)?

 

So I got:
Textures 271.8 mb 89.9%
Meshes 1.5 mb 0.5%
Animations 2.0 mb 0.6%
Sounds 7.0 mb 2.3%
Shaders 1.0 mb 0.3%
Other Assets 852.5 kb 0.3%
Levels 12.0 mb 4.0%
Scripts 2.0 mb 0.7%
Included DLLs 3.9 mb 1.3%
File headers 174.9 kb 0.1%
Complete size 302.3 mb 100.0%

I've many True Color texture files to not have issue with compression etc.
I see clearly that Textures are the issue, but on Android they are also on True Color... So why does the weight is x5 !?

I mean, on Android I've more or less the same mb of Textures but the final APK is 60 Mo not 300 Mo like the IPA. And in the Android build settings, the Texture Compression uses the "Don't override".

 

Don't override usually means compressed. Though it depends what you have in "Default" tab in texture importer. Could you check that you have "Don't override" for iOS too? Also there could be difference in max texture sizes..

 

This is exactly the same settings. I didn't override textures with the platform in the texture importer. Truecolor and 2048 max size.
For iOS, there isn't a Texture Compression in the build settings, or I'm really missing something!?

 

Guys my - .ipa - file is 159 MB , i checked it with Editor Log ,it's showing Complete size 17. 1 MB, my .apk file 21 MB when I opening XCode archiving it , i getting 159 MB , i don't know what is happing ,??
@Mantas-Puida

 

This issue is happening even with empty Unity projects, so the talk of compression and asset folders is, I think, a red herring.

I would like to see a video from Unity on how to solve these issues, perhaps they could start with an empty project, build it for iOS, and show us how to reduce the size. Or perhaps this is simply a bug / limitation with the software and there is no way around it?

 

Haha same here. My Android APK has around 80MB, the iOS version is 270MB using Unity 5.4. This is ridiculous! Same true color textures for both platforms.

 

Same thing:
Android is 31 Mb,
iOS with Bitcode is 70 Mb,
iOS without Bitcode is 31 Mb.

I'm pretty sure the best way to measure size of release build is iTunes Connect "Estimated App Store file sizes", here what I have with and without Bitcode, same game:



So currently the only solution I see is to disable Bitcode for release builds, but if Apple made Bitcode mandatory for iOS builds, then my one-tap game will be like Final Fantasy 7

 

@litebox the main problem is even without Bitcode, on mobile when the app is installed it's hundred of Mbs!
@Mantas-Puida I think many people are waiting a real solution or mostly a patch.

 

Hello everyone!
I have the following problem:
When I built in xCode ios build, the binary file now takes 111mb!
otool showed the following:

Is It bitcode takes so much, or not bitcode?
Can I somehow check why file is so large?
Thanks

 

I completely removed xCode project and rebuild again.
In previous times compiled 366 files.
Now compiled 183 files and build is 67 mb.
Something wrong happened

 

I can confirm that turning off bitcode in Xcode slashed my hugely bloated ~80mb download and ~180mb install size build to the usual 35/65mb files. All the talk about "real sizes" etc. is moot as this is sizes reported by itunes connect which are confirmed to be very close to reality. For now bitcode is off for us, but if (when) it becomes mandatory, Unity as it is will become completely unusable on iOS. I'd love to hear from @Mantas-Puida if what I'm saying is wrong, but the asset size as reported by the Unity editor log is ~30mb with an APK of 42mb, so the bloat really is caused by bitcode alone - the non-bitcode iOS size is pretty close to the APK, and both builds are exported from the same Xcode project.