Mastering Cross-Platform Development with Xamarin

5 (1 reviews total)
By Can Bilgin
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Developing with Xamarin

About this book

The main goal of this book is to equip you with the required know-how to successfully analyze, develop, and manage Xamarin cross-platform projects using the most efficient, robust, and scalable implementation patterns.

This book starts with general topics such as memory management, asynchronous programming, local storage, and networking, and later moves onto platform-specific features. During this transition, you will learn about key tools to leverage the patterns described, as well as advanced implementation strategies and features. The book also presents User Interface design and implementation concepts on Android and iOS platforms from a Xamarin and cross-platform perspective, with the goal to create a consistent but native UI experience.

Finally, we show you the toolset for application lifecycle management to help you prepare the development pipeline to manage and see cross-platform projects through to public or private release.

Publication date:
March 2016


Chapter 1. Developing with Xamarin

This chapter examines the Xamarin framework and architecture on different target platforms and identifies the differences and similarities. It also includes introductory information and tips on preparing the development environment for Xamarin and covers some of the Xamarin development essentials. This chapter is divided into the following sections:

  • Cross-platform projects with Xamarin

  • Target platforms

  • Setting up the development environment

  • Emulator options

  • A typical Xamarin solution structure

  • Quality in cross-development


Cross-platform projects with Xamarin

Developers are enjoying a new era in which development is not restricted to one single application platform but spans across various media such as cellphones, tablets, personal computers, and even wearable devices. The shared code and assets between the development projects improves the elegance and the quality of the work. There is also a direct correlation between the robustness, the effort required for maintaining a multi-platform application, and the reusable modules.

Universal application is a term previously used to identify applications targeting devices running on the iOS operating system (the iPhone and iPad). However, the same term is now used to describe Windows Runtime applications (Windows Store and Windows Phone 8.1 - WinRT) and Android applications for phones and tablets. With the release of Xamarin, a truly universal application concept was born. When considering Xamarin applications, the term, universal, refers to applications that run on all three platforms and adapt to the system resources.

In this universal application context, developers are now finding it difficult to get the necessary solutions for common tasks on all three platforms. Moreover, taking on each platform as a separate development project results in wasted developer hours even though the main driving factors for such an application, namely data, business logic, and UI, are conceptually almost identical on all platforms.

Development strategies and patterns for the Xamarin platform, some of which are described in the rest of this book, try to resolve some of these problems and provide the developers with the tools and strategies necessary to produce cross-platform, manageable, and quality products.

Xamarin as a platform

Xamarin was initially born as a community effort to port the .NET libraries and common language runtime compilers to different operating systems. Initial attempts intended to create a set of binaries to develop, compile, and run applications written in C#, the indigenous language of .NET, on Unix-based platforms. This project, Mono, was later ported to many other operating systems, including iOS (Mono-Touch) and Android (Mono for Android).

The emergence of the Xamarin development platform created a new development niche creating products for three separate platforms at the same time, while allowing users to adapt their existing .NET development skills to these new platforms and produce applications for a wider range of devices and operating systems.


Microsoft has been a strong supporter of Xamarin platform and toolset since the early phases. As you will see in the remainder of the chapter, Xamarin tools were fully integrated into Visual Studio and finally included in the Visual Studio 2015 setup. This partnership lasted until the eventual acquisition of Xamarin by Microsoft which was publicly announced in March 2016.

Xamarin provides compilers for each of the mentioned platforms so that the code written in the .NET framework (-alike) is compiled into native applications. This process provides highly efficient applications that differ greatly from interpreted mobile HTML applications.

As well as native compilation, Xamarin also provides access to strongly typed platform-specific features. These features are used in a robust manner with compile-time binding to the underlying platform. Platform-specific execution can also be extended with native invocations which is possible with the interop libraries.

Xamarin as a product

Xamarin, as a development suite, comes in different flavors. Developers with different sets of knowledge and experience can use these tools to set up their development environment according to their own needs. The Xamarin development environment can be configured on different operating systems. However, it is currently not possible to develop for all three platforms on the same operating system.

For developers who are looking to use the familiar interface of Visual Studio and leverage existing skills, Xamarin extensions for Visual Studio offer a suitable option. Once the extensions are installed, the environment is ready to develop Android and Windows Phone applications. This extension lets the developers take full advantage of Visual Studio, which includes designers for both of these platforms. In order to develop iOS applications, you need to go through the so-called pairing process of Visual Studio with an Apple OS X build machine. The build machine is used in return to visualize storyboards in the development environment (Visual Studio), compile iOS code, and debug applications.

The second option is to use Xamarin Studio. Xamarin Studio is a complete IDE with some of the features you are familiar with from Visual Studio, such as intellisense (smart code completion), code analysis, and code formatting. If you run Xamarin Studio on Apple OS X, you can develop for Android and iOS platforms with this IDE. However, with Xamarin Studio on Windows, you can only target the Android platform.

An important part of this development suite is the real-time monitoring tool called Xamarin Insights. Xamarin Insights lets developers monitor their live applications to help detect and diagnose performance issues and exceptions, and discover how the application is used. Xamarin Insights can also be connected to other applications so, for instance, application errors can be directly pushed into a bug tracking system.


Target platforms

As mentioned, Xamarin created a new platform in which the development efforts target multiple operating systems and a variety of devices. Most importantly, compiled applications do not run an interpreted sequence but have a native code base (such as Xamarin.iOS) or an integrated .NET application runtime (such as Xamarin.Android). In essence, Xamarin replaces the Common Language Runtime and IL for .NET applications with compiled binaries and an execution context, the so-called mono runtime.

Xamarin on Android

With Android applications, mono runtime is placed right on top of the Linux kernel. This creates a parallel execution context to the Android runtime. Xamarin code is then compiled into IL and accessed by mono runtime. On the other hand, Android runtime is accessed by the so-called Managed Callable Wrappers (MCW) which is a marshalling wrapper between the two runtimes. The MCW layer is responsible for converting managed types to Android runtime types and invoking Android code at execution time. Every time that .NET code needs to invoke Java code, this JNI (Java Interop) bridge is used. MCW provides a wide range of applications including inheriting Java types, overriding methods and implementing Java interfaces.

The following image shows the Xamarin.Android architecture:

Figure 1: Xamarin.Android Architecture

Android.* and Java.* namespaces are used throughout the MCWs to access device- and platform-specific features in Android runtime and Java APIs such as facilities like audio, graphics, OpenGL, and telephony .

Using the interop libraries, it is also possible to load native libraries and execute native code in the execution context with Xamarin.Android. The reverse callback execution in this case is handled through Android Callable Wrappers (ACW). ACW is a JNI bridge which allows the Android runtime to access the .NET domain. An ACW is generated at compile-time for each managed class that is directly or indirectly related to Java types (those that inherit Java.Lang.Object).

Xamarin on iOS

In iOS applications, the use of an integrated parallel runtime is (unfortunately) not permissible under the iOS SDK agreement. According to the iOS SDK agreement, interpreted code can only be used if all of the the scripts and code are downloaded and run by Apple's WebKit framework.

With this restriction in place, developers can still develop applications in .NET and share code over the other three platforms. At compile time, projects are first compiled into IL code and then (with the Mono Touch Ahead-Of-Time compiler—mtouch) into static native iOS bits. This means that iOS applications developed with Xamarin are completely native applications.

Figure 2: Xamarin.iOS Compilation

Xamarin.iOS, like Xamarin.Android, contains an interop engine that bridges the .NET world with the Objective-C world. Through this bridge, under the ObjCRuntime namespace, users are able to access iOS C-based APIs, as well as using the Foundation namespace, and can use and derive from native types and access Objective-C properties. For instance, Objective-C types like NSObject, NSString, and NSArray are exposed in C# and provide binding to underlying types. These types can be used either as memory references or as strongly-typed objects. This improves the development experience and also increases type-safety.

This static compilation is the main reason for using a build machine to develop iOS applications with Xamarin on the Windows platform. Therefore, there is no reverse-callback functionality in Xamarin.iOS where calls to native runtime from .NET code are supported but calls from native code back to .NET domain are not. There are other features that are disabled because of the way that Xamarin.iOS applications are compiled. For example, no generic types are allowed to inherit from NSObject. Another important limitation is the fact that no dynamic type creation is allowed at runtime which, in return, disables the use of dynamic keywords in Xamarin.iOS applications.


Xamarin.iOS application packages, if built in a debug configuration, are much larger than their Release counterparts when compared to other platforms. These packages are instrumented and not optimized by the linker. Profiling of these packages is not allowed in Xamarin.iOS applications.

In a similar way to Xamarin.Android development, with Xamarin.iOS, it is also possible to re-use native code and libraries from managed code. To do this, Xamarin provides a project template called a binding library. A binding library helps developers create managed wrappers for native Objective-C code.

Windows Runtime apps

Even though Xamarin does not include Windows Runtime as a target platform nor provide specialized tools for it (other than Xamarin.Forms), cross-platform projects that involve Xamarin can and generally do include Windows Runtime projects. Since .NET and C# are indigenous to Windows Runtime, most of the shared projects (such as portable libraries, shared projects, and Xamarin.Forms projects) can be reused in Windows Runtime with no further modification.

With Windows Runtime, developers can create both Windows Phone 8.1 and Windows Store applications. Windows Phone 8 and Windows Phone 8.1 Silverlight can also be targeted and included in the PCL description.


Setting up the development environment

Xamarin projects can be carried out in various development environments. Since a number of platforms are involved in such projects, the operating system, the IDE selection, and the configuration are all crucial parts of the preparation.


Environment setup not only depends on the target application platforms but also on the Xamarin license. A comparison between different licensing options and pricing information can be found on the Xamarin website (

Choosing the right development OS

Android applications can be developed and compiled on Windows using both Xamarin Studio and Visual Studio with Xamarin extensions installed, as well as on an Apple OS X operating system with Xamarin Studio for Mac installed.

For iOS application development, whether using Visual Studio on Windows or Xamarin Studio on Apple OS X, an Apple Macintosh computer, running at least OS X Mountain Lion, is required. The build machine should have the Xcode development tools with iOS SDK together with the Xamarin.iOS suite installed.

On the other hand, Windows Store applications can only be developed on the Windows platform.


Apple OS X

Microsoft Windows


Xamarin Studio

Xamarin Studio

Visual Studio

iOS Apps



Yes (with OS X Build Machine)

Android Apps




Windows Store Apps



Figure 3: Development IDEs on OS X and Windows

On the virtualization front, developers are also limited. OS X cannot be installed and run on a non-Apple branded machine nor can it be virtualized, according to the end user agreement. On the other hand, you can set up a virtual machine on an OS X development machine for Microsoft Windows and Visual Studio. However, in this case, the system should be running nested virtualization for Hyper-V to run Visual Studio for Windows Phone and Android emulators. Even though Parallels and VMWare Fusion support nested virtualization, Microsoft doesn't support nesting Hyper-V and, therefore, such machines may be unstable.

Xamarin Studio setup and configuration

Xamarin Studio can be set up on both the Windows and OS X operating systems. Developers can download it from and follow the installation instructions. Xamarin components for target platforms (for example, Xamarin.iOS, Xamarin.Android, and so on) together with the dependencies for these platforms (for example, Android SDK) should be downloaded and installed on the development machine. One required component for OS X, which has to be installed separately and configured, is the iOS SDK with the Xcode development environment.

Figure 4: Xamarin Setup on Mavericks (OS X 10.9)

On Microsoft Windows, it is important to mention that Xamarin Studio only supports the development of Android applications. Neither Windows Phone nor iOS application (even with the remote build machine) projects can be viewed, modified, or compiled with Xamarin Studio on Windows.

Figure 5: Xamarin Dev. Environment Setup on OS X

While developing on OS X, the only option for developing Windows Phone applications together with iOS and Android, is to use a Windows virtual machine and run Visual Studio in parallel with Xamarin Studio. This setup is also helpful for developers who use Team Foundation Server as the source control, since they can use the enhanced integration offered by Visual Studio Client rather than the standalone TFS Everywhere. It can also be set up so that the OS host machine can be paired with Visual Studio to become the build host for iOS applications.

Visual Studio setup and configuration

A typical Windows development platform configuration for Xamarin projects includes Visual Studio 2013 or 2015, an Apple OS X build host and Hyper-V and/or VirtualBox to be able to use Android and Windows Phone emulators. Xamarin.iOS applications are then compiled and emulated on the Apple OS X build host.

Figure 6: Windows Platform Xamarin Development Environment


In spite of the fact that it is technically possible to run OS X with a virtual machine in the Microsoft Windows environment, Apple's license agreement does not allow this:

"2.H. Other Use Restrictions: The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so."

On Microsoft Windows, the Xamarin installation is similar to the Xamarin Studio setup on Apple OS X. All of the prerequisites for Xamarin development are installed with the Xamarin for Windows package, together with the Visual Studio extension.

Figure 7: Visual Studio 2015 Setup

One of the key differences between OS X and Microsoft Windows is that Visual Studio 2015 now includes cross-platform development tools such as Android SDK, development kits, and Xamarin project templates. Therefore, the Xamarin installation is only responsible for installing the extensions for the requested platforms (that is, Xamarin.iOS and/or Xamarin.Android).

In order to develop and test iOS applications and visualize and edit storyboards with Visual Studio, an Apple OS X machine must be connected to Visual Studio as a build host. Xamarin 4.0 introduced the concept of Xamarin Mac Agent, which is a background process on the OS X machine providing the required SSH connection to Visual Studio (a secure connection over port 22). Prior to Xamarin 4.0, the build host machine needed to run the so-called Mac build host which was used to pair the Mac host with Visual Studio. The only prerequisites for Xamarin Mac Agent are to have Xamarin.iOS installed on both the Windows workstation and the OS X build host and the build host to have a remote login enabled for the current user. In Visual Studio, the Find Xamarin Mac Agent dialog helps establish the remote connection.

Figure 8: Xamarin.iOS Build Host

It is important to keep in mind that the Mac machine paired with Visual Studio has to have Xcode with iOS SDK installed. A developer account (either enrolled into the app developer program or not) must also be added to the accounts configuration section of Xcode.


If the account associated with Xcode does not have a paid subscription to the developer program, the platform for the iOS projects can only be set for simulator and debug selection to one of the simulator options, not an actual device. Otherwise, the user will be presented with an error message such as, No valid iOS code signing keys found in keychain.


Emulator options

There are a number of emulators for compiled Xamarin projects for the target platform and the development environment. Developers have most flexibility with the emulator for the Android platform, whereas the options for iOS and Windows Store Apps are limited to the SDK-provided emulators.

Emulators for Android

Android applications can be run and tested on a number of emulators on both Microsoft Windows and Apple OS X operating systems.

Android SDK comes with the default emulator that is installed on the development machine. This emulation option is available both on OS X and Windows operating systems.

Figure 9: AVD and Genymotion Emulators

This Android emulator uses the Android Virtual Devices (AVD) to emulate the Linux kernel and the Android runtime. It does not require any additional virtualization software to run, however, the lack of virtualization support makes AVD much less responsive and makes the startup time relatively longer. It also provides a wide range of emulation options for developers, from SMS and telephony to hardware, peripherals, and power events.

The Genymotion emulator ( is one of the most popular emulation options for Xamarin and Android developers. Although it is available with a free license, the free version only allows for GPS and camera emulation. The Genymotion emulator runs on (and is installed with) VirtualBox virtualization software.


VirtualBox together with Hyper-V

Virtual Box software cannot be run alongside Hyper-V virtualization software, which is required for Windows Phone development and emulation on Windows operating systems. In order to use both the Windows Phone emulator and the Genymotion Android emulator, you can create a dual boot option to disable and enable Hyper-V on Windows start-up.

bcdedit /copy {current} /d "No Hyper-V"
bcdedit /set {<identifier from previous command>} hypervisorlaunchtype off

This would create a second boot option to start Windows without the Hyper-V feature so that the virtualization can be used by VirtualBox.

The last and the most recent Android emulation option is the Visual Studio Android emulator. This Android emulator runs on Hyper-V and provides various device API versions and emulation options for developers.

Figure 10: Visual Studio Android Emulator

The Visual Studio Android emulator is installed as part of the Visual Studio 2015 installation and can also be installed as an extension later. The emulator provides a similar experience to the Windows Phone emulator and allows developers and testers to use almost the same set of emulation options with different device profiles as well as different API levels.

iOS emulation

iOS emulation is only possible with the Xcode tools and iOS SDK. The iOS simulator can be started either directly on Apple OS X while developing with Xamarin Studio, or by pairing the build machine with the Visual Studio Xamarin extension running on Microsoft Windows. It also can be used to test both iPhone and iPad applications.


A typical Xamarin solution structure

A Xamarin solution can be composed of different types of projects. Some of these projects are platform-specific projects and the others are shared project types or modules that make it possible to reuse code across platforms.

Figure 11: Xamarin project solution structure on Visual Studio and Xamarin Studio

Portable class libraries

Portable class libraries are the most common way of sharing code between cross-platform projects. PCLs provide a set of common reference assemblies that enable .NET libraries and binaries to be used on any .NET-based runtime or with Xamarin compilers—from phones to clients, to servers and clouds. PCL modules are designed to use only a specific subset of the .NET framework and can be set to target different platforms.

Figure 12: Portable Class Library Targets

Microsoft has a designation for each target combination and each profile also gets a NuGet target. A subset of .NET libraries for portable class libraries were released through NuGet with the release of Visual Studio 2013. This makes it possible for developers to release their work through NuGet packages, targeting a wide range of mobile platforms (see the NuGet packages section for more information).


The currently preferred profile and the greatest common subset for Xamarin projects is the so-called Profile 259. The Microsoft support designation for this profile is the .NET Portable Subset (.NET Framework 4.5, Windows 8, Windows Phone 8.1, Windows Phone Silverlight 8) and the NuGet target framework profile is portable-net45+netcore45+wpa81+wp8.

While creating a PCL, the biggest drawback is the fact that no platform-specific code can be included in or referenced by the project. This caveat is generally addressed by the abstraction of platform-specific requirements or by using dependency injection or similar methods to introduce the implementation in platform-specific projects.

For instance, in the device-specific peripheral example below, the common portable class library has a constructor that accepts two separate interfaces which can be injected with a dependency injection container or can be initialized with a device-specific implementation. The common library, in return, creates a business logic implementation, as shown:

namespace Master.Xamarin.Portable
    public class MyPhotoViewer
        private readonly IStorageManager m_StorageManager;

        private readonly ICameraManager m_CameraManager;
        public MyPhotoViewer(IStorageManager storageManager, ICameraManager cameraManager)
            m_StorageManager = storageManager;
            m_CameraManager = cameraManager;

        public async Task TakePhotoAsync()
            var photoFileIdentifier = await m_CameraManager.TakePhotoAndStoreAsync();

            var photoData = await m_StorageManager.RetrieveFileAsync(photoFileIdentifier);

            // TODO: Do something with the photo buffer

    /// <summary>
    /// Should be implemented in Platform Specific Library
    /// </summary>
    public interface IStorageManager
        Task<string> StoreFileAsync(byte[] buffer);

        Task<byte[]> RetrieveFileAsync(string fileIdentifier);

    /// <summary>
    /// Should be implemented in Platform Specific Library
    /// </summary>
    public interface ICameraManager
        Task<string> TakePhotoAndStoreAsync();

Shared projects

The term, shared project, was initially coined by the Microsoft team with the release of Universal Apps for Windows Phone and Windows Runtime (that is, Visual Studio 2013). With the arrival of Xamarin, shared projects can also be referenced by Android and iOS projects. These types of projects are essentially wrappers or containers for shared code and resource files that are linked to multiple projects and platforms. Shared file assets are included in the referencing projects later and compiled as part of these modules.

Figure 13: Shared Projects

While using shared projects, developers should be careful when including platform-specific code since the shared elements will be included in all the referencing projects and compiled. Compiler directives (for example, #if __ANDROID__) can be introduced in shared projects to denote that certain parts of the code are only for a specific platform.


Visualizing platform-specific code in shared projects

With Visual Studio (2013 or higher), it is possible to visualize different execution paths according to the combinations of conditional compilation constants.

Figure 14: Visual Studio shared project editor

Visual Studio provides a dropdown in the top corner of the editor window which determines the platform-specific projects that are referencing the shared project. By selecting the project, you can see the disabled sections of the code, according the target platform.

If we used the same example to take a photo, we would need to create two completely different implementations for the same action, as shown here:

private async Task<string> TakePhotoAsync()
    string resultingFilePath = "";

    var fileName = String.Format("testPhoto_{0}.jpg", Guid.NewGuid());

#if __ANDROID__

    Intent intent = new Intent(MediaStore.ActionImageCapture);
    var file = new File(m_Directory, fileName);
    intent.PutExtra(MediaStore.ExtraOutput, Net.Uri.FromFile(_file));

    // TODO: Need an event handler with TaskCompletionSource for
    // Intent's result
    m_CurrentActivity.StartActivityForResult(intent, 0);

    resultingFile = file.AbsolutePath;


    ImageEncodingProperties imgFormat = ImageEncodingProperties.CreateJpeg();

    // create storage file in local app storage   
    var file = await LocalStore.CreateFileAsync(fileName);

    resultingFilePath = file.Path;

    // take photo   
    await capture.CapturePhotoToStorageFileAsync(imgFormat, file);


    return resultingFile;


Xamarin.Forms is the unified library for creating UI implementations for target platforms to be rendered with native controls. Xamarin.Forms projects are generally created as PCL projects and can be referenced by Xamarin.iOS, Xamarin.Android, and Windows Phone development projects. Xamarin.Forms components can also be included in shared projects and can utilize platform-specific features.

Developers can effectively create common UI implementations with these forms, either declaratively (with XAML), or by using the API provided. These views, which are constructed with Xamarin.Forms components, are then rendered at runtime with platform-specific controls.

Development projects can be realized with Xamarin.Forms by creating the data access model up until the UI components with a shared implementation, thus raising the amount of shared code between the platforms to as much as, or at times more than, 90%.

NuGet packages

NuGet, which was initially an open source Microsoft initiative to share code among developers, has now become a much larger ecosystem. While NuGet servers can be used as an open source library-sharing platform, many development teams use NuGet as a private company repository for compiled libraries.

NuGet packaging is a viable code-sharing and reuse strategy for Xamarin projects since it is supported by both Xamarin Studio and Visual Studio (with no further installation following Visual Studio 2012).

The NuGet target framework moniker for Xamarin projects is mono and there are further groupings such as MonoAndroid10, which refers to projects with a target framework of MonoAndroid version 1.0 or higher. Other platform targets are:

  • MonoAndroid: Xamarin.Android

  • Xamarin.iOS: Xamarin.iOS Unified API (supports 64-bit)

  • Xamarin.Mac: Xamarin.Mac's mobile profile

  • MonoTouch: iOS Classic API

Developers are free to either re-use publicly available NuGet packages or create their own repository to store compiled packages to include in Xamarin projects.


Creating NuGet packages in Visual Studio 2015

With the release of Visual Studio 2015, there is a new project template that should help developers to create and reuse NuGet packages.

Figure 15: The Visual Studio NuGet package project template

More information on creating NuGet packages and publishing them can be found on the NuGet documentation hub: (


Components are another approach to re-using compiled libraries and modules in Xamarin projects. The Component Store is built into both Xamarin Studio and Visual Studio and it has gathered a number of re-usable submissions from developers since its release in 2013. Components can be downloaded and installed into projects in the same way as for NuGet packages by using the Xamarin Component Store. The Xamarin Component Store can be found at


Quality in cross-development

Some development terms help developers create robust, maintainable, high-quality code when developing for multiple platforms. These code descriptors help development teams identify architectural problems, software issues and random errors.


"How much of the code can be reused throughout the project?"

Reusability is one of the key quality identifiers in cross-platform development projects. Xamarin, especially with the release of Xamarin.Forms, has provided developers with extensive resources to create platform-agnostic components that can decrease redundancy and reduce developer hours in complex projects. Code quality matrices generated by Visual Studio and unit test coverage results can convert this descriptor into a quantifiable measure.


"How much do the shared components know about the platform?"

It is almost unavoidable not to include platform-specific bits in cross-platform solutions. The level that these modules are abstracted to increases the robustness of the shared components and is closely related to how loosely the implemented logic is coupled with the underlying platform. In this way, the shared components can be tested easily with mock or fake libraries without having to create platform-specific test harnesses. Unit test code coverage results help determine the testability of the application.


"How easy is it to transpose the project into another platform?"

On top of the platform-specific abstracted implementation, an autonomous shared implementation layer creates flexible solutions which can easily be adapted to other platforms. Reducing the dependencies of the shared logic to the underlying platform not only inherently increases the reusability but also the agility of the development projects. The number of conditional compilation blocks or if or else loops for the underlying platform on shared projects identifies the amount of code executed according to the platform.


"How much does your application blend into the platform?"

Even though the ultimate goal while developing with Xamarin is to create an application that can be easily compiled onto multiple targets, the applications created with Xamarin should look, feel and behave as if they were designed for that specific platform. The UI paradigms and user interaction mechanisms of each platform should be respected while creating a common foundation. Nativity is more of a nominal and subjective measure when compared to the aforementioned code descriptors.



In this chapter, we have discussed some of the key features of the Xamarin development suite and development on previously described platforms and looked at Xamarin essentials for developing mobile applications. The remaining chapters refer to these key features and the differences between the platforms to identify valuable patterns and strategies to create cross-platform applications with Xamarin.

The architectural overview of the target platforms and how Xamarin applications are developed and compiled on these platforms were also discussed. The most important difference between these platforms is that Xamarin.Android (and also Windows Phone) uses .NET binaries and mono (and .NET) runtime to execute code, whereas Xamarin.iOS applications have a completely different setup and double compilation (Ahead-of-Time) to make use of .NET binaries, but not to run them directly.

Whilst developing for Android and iOS platforms with Xamarin, developers are also forced to select between different OS platforms and development IDEs. The selection and configuration of the development environment depends on the targeted platforms. IDE features and emulator and simulator options play an important role in this selection. While providing a familiar interface and letting the developers transfer their .NET-related skills and know-how, the OS X operating system together with Xamarin Studio is currently a more viable option for developing iOS applications.

Another important refresher was for the Xamarin solution structure. We talked about how developers can share code between different platforms and re-use public or private stores to include shared modules. Shared projects make up the basis for most cross-platform development patterns and strategies together with portable class libraries.

Overall, when using the Xamarin specifications and features, the main objective of developers should be to create loosely coupled, platform-agnostic modules that increase productivity and improve the quality of cross-platform development projects.

About the Author

  • Can Bilgin

    Can Bilgin currently works with Authority Partners Inc. as a Solution Architect. He has been working in the software industry, primarily with Microsoft technologies, for over a decade and has been recognized as a Microsoft Most Valuable Professional for his technical contributions between 2014 and 2018. In this period, he took key roles in projects for high profile clients using technologies such as BizTalk, SharePoint, Dynamics CRM, Xamarin, WCF, Azure Serverless and other web/cloud technologies. He is passionate about mobile and IoT development using the modern tools available for developers. He shares his experience on his blog, social media and through speaking engagements in local and international community events.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Ich habe es noch nicht komplett, aber bis Kap.4 für mich verständlich und ausreichend umfassend. Aber es ist m.E. bestimmt kein Anfängerstoff. So wird z.B. die Garbage Collection kurz angerissen. Wer das Generationen-Konzept in .NET nicht kennt muss da aber bestimmt erst mal in der MSDN nachlesen. Die IOS Variante benötigt bestimmt auch Fremdquellen :-) Und leider weiß dann nur der etwas erfahrenre Entwickler, das der Anfänger o.g. Kapitel eigentlich überspringen kann :-)
Book Title
Unlock this book and the full library for FREE
Start free trial