Invalid Executable Size - From iTunes Connect

It is difficult to give a specific answer without any details. There are many things that can affect the size of applications. Start with the basics .

What you should check:

• First, make sure your application is not building with Not referenced . This will create very large applications since you will be the AOT of the almost complete .NET framework that Xamarin.iOS ships;

• Second, make sure you are building a unified architecture (ARMv7). FAT binaries (like ARMv7 and ARMv7) are built twice and require double the space;

• Third, make sure you haven't enabled the Debug build (this can be done in Release build, this is a checkbox). This will create large binaries for debugging support,

• Fourth, make sure you are using the LLVM compiler . It takes longer to compile, but it generates better (and less) code;

These initial checks are fairly easy to use and are the most common reasons for getting very large binaries.

To understand where the size comes from, you need to know how the application is built.

• Difference between Android and iOS version is that JIT'ing (compiling exactly at the point in time) is not allowed in iOS (Apple rules).

• This means that the code must be AOT'ed (compile ahead), and this process creates much larger executables (since IL is more compact than native code);

• If your code is generic, then the final binary can get quite large because it will have to compile all of the generic features out of the box (many cases can be decoupled, but value-types cannot).

What you can do to reduce the size:

• Try to reduce the size of your managed code first. An easy way to do this is to enable the linker on every assembly, i.e. link all assemblies in your project variants.

Many people think it is not worth linking their own code because they know they will need it at runtime (so the linker cannot remove it), otherwise they would not have written that code.

This half is true. The linker may not be able to remove most of your application code , but if you are using third party assemblies that are unlikely to be 100% used. A component can remove this extra code (and also remove from the SDK any code that is stored to support this unnecessary code). The more general code you have, the more the linker can help you.

Less IL code means faster AOT times, which translates into faster builds and smaller final binaries (including executable size).

Note: there are many docs and blog posts on how you can manipulate the linker to skip some assemblies, some types or methods to handle / delete.

• Second attempt to reduce its own size. If you are building native libraries, look at them second as they will be statically (not dynamically) linked to your final binaries (another rule for iOS apps). Some of them may be impractical (especially wise) for their weight in your final binary (and there may be lighter alternatives).