Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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
My own tests shows:
FAT: armv7+armv7s 19537040 (make sense)
FAT: armv7+armv7s+arm64 62482864 !
There's definitively something wrong when creating a FAT 32/64 binary.
FAT: armv7+armv7s+arm64 30025248
Fixed in monotouch/master 98edac7f4ab23e758c62c3a0130f4f1d24415e17
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?
@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).
Hmmm... not an msbuild expert either :/ Can we even do that on Mac?
Plus I'm not sure Indie subscriptions allow external builds...
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).
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.
@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.
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
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.
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).
As per comment 11 and comment 12, This working fine.
Hence I am going to close this issue.