CODEWITHSUNDEEP
xamarin.iosxamarinmdtool
patridge
patridge

Reputation: 26565

iOS Archive size difference: command line vs. Xamarin Studio

How do I get mdtool to build an iOS archive that is as small as the Xamarin Studio's menu option (Build > Archive)?

I've got a project build archives from script that are coming out much larger than what Xamarin Studio is producing manually from the menu command.

Steps

For Xamarin Studio, I just set it to AppStore|iPhone and hit the Build > Archive menu item.

For command-line, here's the command line call the RAKE script is making to mdtool:

.../mdtool -v archive \"--configuration:AppStore|iPhone\" -p:SomeProject.iOS SomeSolution.sln

The "AppStore|iPhone" build configuration they both use is set to "Link SDK assemblies only" under the iOS Build project settings.

While the command line archiving runs, it definitely prints LinkMode: SdkOnly in the MTouch Task portion of the console output.

Resulting Archives

On the project giving me trouble, the resulting xcarchive files are 102MB for command line and 66MB for Xamarin Studio (difference: 36MB), with Xcode estimates of 69MB and 35MB in App Store size, respectively.

Inside the xcarchive files, it gets more confusing. There are two files with differences and those two files are different by ~60MB (which doesn't match the above difference):

Upvotes: 4

Views: 578

Answers (1)

poupou
poupou

Reputation: 43543

Note that mdtool is mostly deprecated (still used for classic, not unified, apps) since Xamarin.iOS moved to use msbuild as it's build system.

dSYM file: 17kb vs. 29.2MB (weird)

The former is wrong. Note: a bug was fixed recently, you might need to rebuild, not just build, to get the correct .dSYM.

This is the symbol directory size. This is not something that is shipped (to customers) as part of your application. However it's important to archive since it will be used to symbolicate any crash reports (coming from customers) for your application.

30.1MB vs. 65.7MB

If looks like the first case is a thin (e.g. only ARMv7) binary while the later is a fat (e.g. ARMv7 + ARM64) application. For new applications Apple will only accept fat applications (i.e. both 32 and 64 bits) on the AppStore.

Xcode estimates

The estimates can be quite wrong since there's compression on the files. It's even more complex since Apple's DRM will encrypt the executable part of your application - and encrypted data does not compress well (or it's a very bad encryption ;-).

Upvotes: 2

Related Questions