Bug 24116 - Huge binary size when using multiple architectures
Summary: Huge binary size when using multiple architectures
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 8.4.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: 8.6.0
Assignee: Sebastien Pouliot
Depends on:
Reported: 2014-10-28 16:33 UTC by Marko
Modified: 2014-11-28 10:58 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Marko 2014-10-28 16:33:58 UTC
When you create an app, which includes more than one architecture, the resulting binary is extremly huge, for no reason. The binary is more then two times the size of the sum of all architectures

I've posted about it in the forums: http://forums.xamarin.com/discussion/26842/insane-binary-size-when-creating-an-armv7-armv7s-arm64-app
Comment 1 Sebastien Pouliot 2014-10-28 22:50:04 UTC
My own tests shows:

armv7	9739440
armv7s	9772160
arm64	10479136

FAT: armv7+armv7s		19537040 (make sense)

FAT: armv7+armv7s+arm64	62482864 !

There's definitively something wrong when creating a FAT 32/64 binary.
Comment 4 Sebastien Pouliot 2014-10-29 09:38:16 UTC
FAT: armv7+armv7s+arm64    30025248

Fixed in monotouch/master 98edac7f4ab23e758c62c3a0130f4f1d24415e17
Comment 5 Fred 2014-10-31 13:20:00 UTC
Thanks Sebastien for the fix.
I'm affected too, alas I had no other choice than to publish an 80MB app to the App Store :(
Do you know in which version/release of Monotouch will this fix land?
Comment 6 Sebastien Pouliot 2014-10-31 13:27:43 UTC
@Fred it will be part of the next version, I'm not sure exactly when it will hit alpha.

Note that you should be able to manually run `strip` on your main executable (in the .app). However you'll need to re-sign the .app before submitting it.

I'm no msbuild expert but it's likely you can add the a step (the `strip`command) in between the MtouchTask and the next one (but be sure to do so only for release builds, not debug ones).
Comment 7 Fred 2014-10-31 13:43:10 UTC
Hmmm... not an msbuild expert either :/ Can we even do that on Mac?
Plus I'm not sure Indie subscriptions allow external builds...
Comment 8 Sebastien Pouliot 2014-10-31 13:47:53 UTC
All builds for unified API (or iOS8 features) are using xbuild (msbuild clone) even from inside XS. So that kind of customization should be availble to Indie-licensees.

OTOH isubmitting to the appstore is not a common operation so doing it manually is likely quicker (than learning how to tweak your .csproj wrt msbuild).
Comment 9 Parmendra Kumar 2014-11-28 08:39:09 UTC
We have tried to verify this issue by following the instructions provided in link : https://medium.com/xamarin-development/diving-into-xamarin-reusing-objective-c-libraries-18b6f29c7922 , but not able to verify this.

Could you Please provide us some steps or screencast? So that we can verify this issue at our end.

Comment 10 Sebastien Pouliot 2014-11-28 08:51:35 UTC
@Parmendra you can verify this with any application you have. Build them once for ARMv7 (only), ARM64 (only) and then a fat ARMv7/ARM64. 

The later (fat) should be close to the size of the ARMv7 + ARM64 ones. OTOH if the later is twice the size then it means the symbols were not stripped.
Comment 11 Parmendra Kumar 2014-11-28 10:38:20 UTC
Thank you @Sebastien, I have checked this issue as per your suggestions in comment 10 and below are my observations.

For ARMv7 :  Size is 7.8 MB
For ARM64 :  Size is 8.5 MB
For ARMv7+ARM64 : Size is 14.5 MB

Screencast: http://www.screencast.com/t/k5QKlwuv

As per my understanding, above observations is fine for the app which I have used for the verification.

Could you please have a look on the above observations and screencast, and let me know if I need to check anything else to verify this issue.

Comment 12 Sebastien Pouliot 2014-11-28 10:45:40 UTC
That's fine. 7.8 + 8.5 == 16.3 < 14.5

Note that it could have been a bit higher (than 14.5) that depends on how much data (versus code) is part of the .app.

A non-stripped .app would have a been around 25-30MB (instead of 14.5).
Comment 13 Parmendra Kumar 2014-11-28 10:58:53 UTC
Thanks @Sebastien,

As per comment 11 and comment 12, This working fine.
Hence I am going to close this issue.