Data folder in the built app

I’m trying to find out the size that my app will have once released for good on the store. I found a .app in the XCode project/build folder… is that the one?

This bundle contains a Data folder (just like any standalone Unity app), with dlls: I thought everything was translated to iPhone assembler or whatever? I thought maybe it was a cross-compiled version of the files that just happened to have the same name, but no, they’re readable in Reflector, so they obviously are real .NET dlls.

So my app is 23 MB (unzipped), with a 16 MB ‘unix executable’ file, and a 7 MB data folder (including 2MB mscorlib)… who’s who? I’m very confused here!

The downloadable size is your .app bundle (the one you found in the XCode project/build folder) zipped (at least according to Apple).

.NET DLLs are still required for running mono code, because they contain metadata information. Unity will strip all actual bytecode if you have"Strip ByteCode" selected in your code stripping options. Then DLLs in the Data folder will contain only metadata.

If you set “Use micro mscorlib” or “Strip ByteCode” in stripping options, then much smaller “micro” mscorlib.dll which we wrote specifically for Unity will be used.

Thanks a lot, much clearer now!
The “strip bytecode” option is only for pro though, right? My DLLs still show the actual code in Reflector.
Also, this has nothing to do with “strip debug symbols” in Unity’s build settings, right?

Other question: how come is the unix executable so big? Since assets are still in sharedAssets as for any other standalone, I don’t really get what it contains…

Yes, all stripping options are available only in pro version. Yes, it is nothing to do with “strip debug symbols”.
Are you saying that you set “strip bytecode” option, but you still see code in Reflector?

Well, it contains Unity Engine itself (rendering, animations, audio, GUI, math, data loading code to name some parts), ShaderLab, PhysX, Mono runtime and AOT generated code.

In your case (16Mb), almost half of it is actually Mono runtime and AOT generated code. Approximate ratio between CLR bytecode and resulting native code is 1:3 (plus Mono runtime is more than a meg).

If you want to reduce size of your final executable, you should:
a) avoid Javascript in your project, since it requires additional code to support language
b) avoid any external libraries
c) use only UnityEngine API, learn dependencies inside .NET libraries like what will include System.Security or other obscure code and what not :wink: Just forget XML
d) use our micro mscorlib and strip bytecode (only Pro version)

Then you can try playing with RegisterClasses.cpp in Unity built XCode project. You can remove classes you don’t need (neither from scripts, neither in the data, neither indirectly) that will create more stripping possibilities for linker. If you remove too much of something, you will get either link time error or run-time error (when data is being loaded).

Thanks for being so exhaustive!

Sorry for the mixup, I’m on standard.

So… 1Mb of CLR will lead to 3Mb of native?? or the contrary?

Don’t worry I loathe the fat bastard ! :smile:
Although I should probably make sure that I have no script from the standard assets lying around, even unused they get in the loop.

Yes, I learned that the hard way, I’m using serialization on Besmashed: XML alone makes the standalone 2-3Mb bigger, webplayer 0.9Mb if I recall correctly.
I tried to get away with a lite library, but it was using System.ComponentModel, which made Unity include System.dll AND System.Xml.dll… dammit! :roll:
Hopefully someday those will be part of the plugin… (even if that wouldn’t change a thing for the iPhone)

Yes, roughly…

Is there any documentation on what’s missing from the micro mscorlib.dll? It would be useful to know before build time that I’m using something not in the micro lib.