Xamarin.iOS provides very useful build options, that can be used with various configurations and platforms. Here I am just considering it for only two configurations and platforms, but you can make it as per your choice. The configurations that I will consider here are debug and release and the platforms are simulator and device.
Notes
Some of the build options are not selectable for debugging configuration.
You can open build option by double clicking on iOS project or right clicking on it. Select Option in Visual studio for Mac and Properties in Visual Studio for Windows, and then select iOS build option from the left panel. You can change build options for each available configuration and platform.
See attached picture for Configuration and Platform options (screenshot from Visual Studio for Mac).
![]()
As shown in the above picture there are many build options available, some of them are discussed here.
SDK Options
This option allows you to select the iOS SDK version used to build your software. It allows you to use different versions of an Apple published SDK, this directs Xamarin.iOS to the compiles, linkers and libraries it should reference during your build.
Linker Behaviour
When building your application, Visual Studio for Mac or Visual Studio calls a tool called mtouch that includes a linker for managed code. The linker can strip out unused code to reduce the overall size of the application. Linker uses static analysis to determine the different code paths that your application is susceptible to follow. It's a bit of a heavy process so it takes time while compiling, as it has to go through every detail of each assembly, to make sure that nothing discoverable is removed. The linker behavior can be customized by selecting options from the available options. There are main three options offered by xamarin which are explained below.
-
Don’t Link
This option disables linking, so it does not link anything, this is default option from simulator with debug mode because of performance reason.
-
Link Framework SDK only
This option will leave your current application assembly untouched, and reduce the size of the assembly shipped with Xamarin.iOS (Xamarin.iOS SDK) by removing everything that does not used by your application. This option is best suited when you target platform to iOS devices. The difference between this and ‘Link All’ option is that it can not perform few optimization.
-
Link All
When setting this mode, the linker can use the whole set of its optimizations to reduce the application as small as possible. It will perform linking operation on user code as well which modify user code, so it may break sometimes when your code uses a feature in way that linker’s static analysis does not detect (for webservices, reflection or serialization). It might be required some changes in code to make application link everything.
Supported Architectures
This option specifies on which devices apps can run. It has many options as per processor architecture. Each are listed below with device names.
-
ARMv7
- iPhone 3GS, 4, 4s.
- iPad 1, 2, 3, Mini.
- iPod 3, 4, 5th Generation.
-
ARMv7s
- iPhone 5.
- iPhone 5c.
- iPad 4.
-
ARMv64 (iOS v8.6 support ARMv64).
- iPhone 5s.
- iPhone SE.
- iPhone 6, 6s, 6+, 6s+,
- iPhone 7, 7+.
- iPad Air, Air 2.
- iPad Mini 2, 3, 4.
- iPad Pro (all).
-
ARMv7 + ARMv7s.
-
ARMv7 + ARMv64.
-
ARMv7s + ARMv64.
-
ARMv7 + ARMv7s + ARMv64.
ARMv64 is 64 bit architecture it is supported starting with A7 Processor which was introduced with iPhone 5s.
ARMv7s is only supported by A6 processor which was power the iPhone 5 and run on iOS 6.0 or later.
ARMv7 is supported by all the iPads and iPhones beginning with iPhone 3GS and is meant for iOS 5.0 and later. It will compile smaller and faster code then ARMv6 (ARMv6 support iPhone (original), 3, iPod 1, 2 generation).
ARMv6 is most compatible architecture which will run on all the iOS devices, but it is only supported by iOS compiler that shipped with xcode 4.4 or earlier (with latest Xamarin.ios version ARMv6 is not available in option).
Note
Specifying multiple architecture allows application to target on widest range of devices with maximum code optimization, but it will double or triple the size of the application executables.
HttpClient Implementation
This option specifies how HttpClient Implementation is used by application. There are 3 options which are as follows.
-
Managed
This is fully managed HttpClient handler that has been shipped with previous version of Xamarin. It has the most compatible feature set with Microsoft .NET and older Xamarin versions. Some of disadvantages of this options are listed below.
- It is not fully integrated with the Apple OSes and is limited to TLS 1.0.
- It typically much slower at things like encryption than the native APIs.
- It requires more managed code, thus creating a larger app distributable.
-
CFNetwork (iOS 6+)
The CFNetwork-based handler is based on the native CFNetwork framework available in iOS 6 and newer. Some of the advantages and disadvantages for this handler as follow.
Pros
- It uses native APIs for better performance and smaller executable size.
- Support for newer standards such as TLS 1.2.
Cons
- Requires iOS 6 or later.
- Not available on watchOS.
- Some HttpClient features/options are not available.
-
NSUrlSession (iOS 7+)
The NSURLSession-based handler is based on the native NSUrlSession framework available in iOS 7 and newer. Some of the advantages and Disadvantages are listed below.
Pros
- It uses native APIs for better performance and smaller executable size.
- Supports for the latest standards such as TLS 1.2.
Cons
- Requires iOS 7 or later.
- Some HttpClient features/options are not available.
LLVM Optimizing Compiler
It produces both faster and tighter code than the Mono engine does, at the cost of long compile times. This option is not available in debug configuration, because it required more times to compile. It is good to enable this option when you create release build or app store deployment, otherwise use Mono code generation engine as it will let you iterate quickly. There is one option inside this called “Thumb-2 Instruction set for ARMv7 and ARMv7s”, as the name suggests it is supported on ARMv7 and ARMv7s devices. It is a more compact instruction set used by ARM processors. It can reduce the size of your executable, at the expense of slower execution times.
Perform 32-bit float operation as 64-bit float : as name suggest, perform all the 32-bit float arithmetic operation as 64-bit float which yield the higher bit precision and stricter .net compatibility, but it is substantially slower.
Enable Incremental builds
This is used for development build. It tells IDE to rebuild only components that are changed since previous builds, instead of rebuilding the whole project. Check this option for faster rebuilding and deployment during development, and uncheck this before publishing.
Use the concurrent garbage collector
Concurrent garbage collection perform collections on the old generation (what we call major collections) mostly concurrently with your application - it happens at the same time as your program is running. When the major collection is completed, the collector only needs to pause the Mono threads for a very brief period of time at the end.
So enabling this option can reduce the pause times for major collections, which improves the performance and responsiveness but it can slightly increase memory usage.
Enable device specific builds - this can be used to improve deployment time by targeting only currently selected iOS devices. This should not be used for release build configuration.
Additional mtouch arguments - you can use this option to specify some additional mtouch command, which passed to application bundling tools. For example, if you want to skip linking on System.Runtime assembly when you select LinkAll option in link behaviour, just pass “--linkskip=System.Runtime;”.
Optimize PNG Images - this options uses Apple’s modified PNGCrush utility to optimize PNG images by byteswap image data from RGB(A) to BGR and premultiply alpha component to make image loading faster on iOS devices. More detail for PNGCrush for mac found here (http://osxdaily.com/2013/08/15/pngcrush-mac-os-x/).