Appcenter-sdk-dotnet: Large Package size for Xamarin.iOS

[InquisitorJax]

Is there a reason for the 30+ Meg package size for the Xamarin.iOS libraries?
The android libraries combined are under a meg.

[dhei]

This has been followed up in the intercom support channel.

[dhei]

As I mentioned this ticket has been followed up in our Intercom support as it's cross-posted on GitHub. For the benefits of the rest, I think it's worth sharing my investigation here.

Note that the size of the Microsoft.AppCenter.iOS.Binding.dll is the combination of all architectures, including armv7, armv7s, arm64, etc.. When users downloading the app from App Store, the app size installed on the device is probably smaller than the .ipa size. So it probably won't impact the app size as much you might think.

The reason Microsoft.AppCenter.iOS.Binding.dll has ~13 MB size is because App Center Xamarin SDK is implemented by wrapping App Center Apple SDK. App Center Apple SDK's AppCetner.framework is ~14 MB, hence the Microsoft.AppCenter.iOS.Binding.dll is about the same size. It can't be much smaller.

There are a few techniques to reduce the iOS application size. For example:

Link All Assemblies – This is a more aggressive optimization that will target the SDK assemblies and user code. For bindings this will remove unused backing fields and make each instance (or bound objects) lighter, consuming less memory.

Hope this clarify the issue a little bit.
Thanks.

[InquisitorJax]

Interesting to note though, that the same bindings for Android are under a meg... is there really a 30x penalty for writing the same functionality in swift / objectiveC?

[ElektrojungeAtWork]

@InquisitorJax
An important thing to note is that the binary size that you are integrating is not (!) the actual size increase of the app. For example the iOS binaries that are downloaded contain all architectures, also including the iOS simulator architectures. Those and a lot of other things will be stripped away when you build your app while debugging and even more will be stripped away for release builds. Our documentation includes some sample size increases for iOS apps.

[guperrot]

Also the Android SDK is pure Java and does not contain any architecture dependent code.

[sdebruyn]

@dhei @guperrot @ElektrojungeAtWork I'd like to reopen this issue.

Installing crash reporting causes the app to contain 2 assemblies, each of more than 20 MB in size. Like you explained above, this is because you haven't created a Xamarin.iOS counterpart yet, but are just wrapping the native iOS libraries. Also, like you explained above, this won't be a real issue because there is the linker and the App Store only sends you the code for your architecture.

However...

I am working on a Xamarin.Forms app and I'd like to use the Hot Reload functionality. This means that I have to disable the Linker. This causes my app to become huge and results in the following error:

MTOUCH: Error MT5107: The assembly 'Xamarin.iOS.dll' can't be AOT-compiled for 32-bit architectures because the native code is too big for the 32-bit ARM architecture. (MT5107)

I assume that most Xamarin apps will contain both App Center and Xamarin.Forms assemblies. My iPhone is still a 32-bit one...

Is it on the roadmap to create an App Center implementation in true Xamarin instead of binding libraries?

[russelarms]

Hi, @SamuelDebruyn!
I understand your concerns, but I don't think that it could be a valid option to make a true Xamarin version of AppCenter SDK for us when we speak about the Apple ecosystem. I'm not sure that we'll be able to cover all the existing functionality and also it will increase the amount of doing-same-things-multiple-times work.
While 32-bit architecture is still here, Apple tends to cease its support, so I don't think we will invest any time to improve support for 32-bit libraries.