4

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):

  • dSYM file: 17kb vs. 29.2MB (weird)
  • [within the .app file] app executable: 30.1MB vs. 65.7MB (where I expected the difference)
patridge
  • 26,385
  • 18
  • 89
  • 135

1 Answers1

2

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 ;-).

poupou
  • 43,413
  • 6
  • 77
  • 174
  • I'm not finding anywhere else saying mdtool is deprecated for iOS builds. Granted, all the samples are from quite a while back, but it's also still in the [continuous integration docs in the Xamarin Guides](http://developer.xamarin.com/guides/cross-platform/ci/jenkins_walkthrough/#Building_a_Xamarin.iOS_Project). If I do need to switch, is that xbuild on a Mac (`/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild/12.0/bin/xbuild.exe` and/or `/usr/bin/xbuild`)? What parameter would either xbuild or msbuild take to trigger the iOS archiving? – patridge Mar 14 '15 at 16:57
  • "deprecated" isn't really the right word, it's more like "unnecessary" – Mikayla Hutchinson Mar 16 '15 at 18:57
  • Basically, mdtool is a commandline interface to the MD/XS build system. For projects that use the xbuild/msbuild engine, mdtool is effectively a wrapper over xbuild, and therefore unnecessary, since you could just use xbuild directly. However, mdtool is still necessary for projects that use the old internal build engine, such as iOS Classic projects. – Mikayla Hutchinson Mar 16 '15 at 18:59
  • @mhutch Can you point me in the right direction of an example xbuild call that would archive with Xcode? Or should I be hitting some Xcode command-line tool directly after an xbuild AppStore build? – patridge Mar 17 '15 at 18:18