Why Xamarin

While there are many ways to build for mobile form factors, let's explore what's in it for developers if they choose the Xamarin technology stack.

Even after years of building for mobile, developers still heavily debate the choice of technology stack. Perhaps there isn't a silver bullet and mobile strategy really depends - on app, developer expertise, code base maintenance and a variety of other factors. If developers want to write .NET however, Xamarin has essentially democratized cross-platform mobile development with polished tools and service integrations. Why are we then second guessing ourselves?

Turns out, mobile development does not happen in silos and all mobile-facing technology platforms have evolved a lot. It always makes sense to look around at what other development is happening around your app - does the chosen stack lend itself to code sharing? Are the tools of the trade welcoming to developers irrespective of their OS platform? Do the underlying pillars of chosen technology inspire confidence?

Let's take a deeper look and justify the Xamarin technology stack. Spoiler - you won't be disappointed.

This article is a part of a long content series on Chasing Success with Xamarin Apps - we explore the Xamarin technology stack, tools and services that help developers build successful mobile apps.

Mobile Strategies

While there are variety of ways to build for mobile, the following are the broad categories:

Thankfully, whichever technology stack mobile developers choose, there's mature tooling and easy access to mobile platform APIs. Let's discuss some pros and cons of each approach however:

• Native: The most straightforward way of building for mobile is native apps for iOS, Android and Windows. Native apps run closest to the metal and developers get to use platform-specific SDKs/languages/tools. While fast and beautiful, native apps are rather expensive, requiring maintenance of platform-specific code bases.

• Mobile Web/PWAs: The lowest hanging fruit to go cross-platform with mobile is often mobile web - there are plenty of frameworks that help web applications work nicely on mobile browsers. Mobile web apps can be taken to extreme smartness through Progressive Web Apps - where web apps start behaving as legitimate citizens in the mobile app world. Users can pin web apps to their home screens, have service workers run in the background and get push notifications. There is a lot of tooling help when building mobile web and mature JavaScript SPA frameworks for building PWAs.

• Hybrid: Cordova popularized the idea of building cross-platform mobile apps with web technologies - HTML, CSS and JS bundled together to make a mobile app. Such hybrid apps ran within the browser shell and the user would not notice if done well. While hybrid apps enjoy good tooling, mature frameworks like Ionic and app store presence, the browser sandbox does hamper their runtime speed a little.

• JS Native: The last few years have been witness to the rise of cross-platform mobile apps written in JavaScript/Typescript - the point is, why go hybrid when you can go native with the same technologies? JS Native apps enjoy complete native platform access and render native UI - all from a single code base. JS Native apps enjoy wonderful frameworks like NativeScript, NativeScript with Angular/Vue integration and React Native.

• X-Compiled: If you would rather write .NET code and use familiar tooling like Visual Studio, the cross-compiled mobile app solution is rather enticing. The trick is compiling higher level .NET language code into binary bits for each mobile platform, all the while rendering native UI. Xamarin has largely democratized the X-compiled space for .NET developers, with the Uno platform lending a helping hand of late. If you are ok writing Dart, Flutter offers another enticing approach to writing native mobile apps for iOS/Android with fast dev-reload cycles.

While you'll find this article advocating for the Xamarin technology stack, the point of this mobile strategy discussion is that you don't have to always do Xamarin to reach cross-platform mobile. If you are invested in the web stack and happy writing JS/TS, the web route of getting to mobile form factors will yield rich dividends and lend itself better to code sharing.

All the .NETs

As one dives into the Xamarin technology stack, it is often beneficial to taka a step back and understand the .NET ecosystem - where does Xamarin fit? Here's the big picture story with .NET:

As developers know, the .NET stack has evolved a lot in the past couple of years. There are multiple .NETs for different types of apps - to be read as multiple Base Class Libraries (BCLs). The three most popular ones are:

• .NET Framework: This is the full .NET Framework that has the been the darling of developers on the Microsoft stack for 17 years now. The .NET Framework provides as rich an ecosystem as you can get - top notch tools, community support, extensibility and runtime for hosting variety of .NET applications. Over the years however, the .NET Framework has shown obvious bloat and the monolithic nature of the framework invites brittleness, as well as upgrade headaches. Make no mistake, the .NET Framework isn't dying and remains a core part of Windows. However, it may not see serious innovations going forward - existing apps would continue to run fine, but any greenfield development should look ahead at other .NETs.

• .NET Core: This is the new .NET, built from ground up to address some of the concerns of .NET Framework. .NET Core is lean, modular and for the first time, boasts a cross-platform runtime taking .NET apps to MacOS/Linux. While new, .NET Core has seen rapid innovations and sports near-par API features compared to the .NET Framework. The lightweight nature of .NET Core lends itself naturally for building high performance web applications, while the command line/cross-platform tooling provides developers with liberties. The benefits of side-by-side .NET runtimes are stretching back to desktop with .NET Core 3, while .NET Core itself pushes the envelope with technologies like ML.NET.

• Mono: Since the inception of .NET, there has been a desire to take .NET apps outside of Windows. Meet Mono - the port of .NET APIs to other platforms that is as old as the .NET Framework itself. Mono is the runtime for all Xamarin applications and remains an incredibly versatile way of supporting .NET on an increasing number of non-Windows platforms.

It is not hard to see how this variety of .NETs in the ecosystem provides flexibility - developers get to choose which .NET works best for their apps. Xamarin running on Mono is a very important piece of the puzzle for Microsoft - it is what gives .NET the extensive platform reach. With all the .NETs, there are very few devices/platforms that modern .NET developers cannot reach.

Mono or .NET Core

Mono has always been a great natural fit as a runtime for Xamarin apps. Developers write .NET code which is compiled down to generic Intermediate Language (IL) code, and then the Mono bridge/virtual machine translates .NET IL to native assembly code for iOS/Android or other platforms. It is only recently that much of .NET became open source - prior to that, Mono painstakingly made .NET code portable and executable on other platforms.

However, there is .NET Core now, which is modern, versatile and cross-platform. Developers in the Xamarin ecosystem have wondered of late - could .NET Core actually replace Mono as the runtime for Xamarin apps?

While it is enticing to expect everything out of the new polished runtime, the realities dictate otherwise. Turns out, age does make you wise and Mono, to this day, sports a bigger API surface area than .NET Core. Mono is also very performant for .NET apps running on iOS/Android - both through IL interpretation or statically compiled. Mono is also way ahead of the game in .NET implementations on future-facing platforms, like the all-important WebAssembly. So, it is safe to say that Mono is here to stay and power .NET apps across a wide variety of platforms.

The other question to consider is fragmentation of .NET. While having various .NET BCLs optimized for different platforms is nice, is the present state of the ecosystem inviting confusion for developers? Does it make sense for Microsoft or the open source community to maintain so many .NET? Perhaps a unification of the various runtimes is called for - only time will tell.

How to Xamarin

Developers choosing the Xamarin technology stack to build for mobile can be assured of a solid performant runtime and a plethora of rich tooling. This frees up developers from having to worry about the logistics of building an app, and lets them just focus on the app itself. As one gets started with Xamarin, there are two broad choices:

Xamarin iOS/Android

From the early days of Xamarin, the goal was to write .NET code that could be shared across mobile platforms, and this is traditionally what is called Xamarin.iOS/Android. Often dubbed Xamarin Native, the goal is to have a shared code layer written in .NET and platform-specific projects for the UI part of the mobile apps.

The goal with Xamarin.iOS/Android is to abstract out as much of the app feature set as possible into a .NET code library - this is shared across all platforms. While a great step in the right direction, Xamarin Native does require developers to build the UI layer of each supported mobile platform on its own. This means developers do need to know how to build app UI for iOS, Android and Windows natively - all pulled together into a single project and referencing the shared library.

So when should developers choose to build with Xamarin iOS/Android? Xamarin Native is a good choice in general when mobile apps tend to cater heavily to a certain platform - where lots of native behaviors and custom UI are called for. Mobile games are also served well with Xamarin Native - essentially, Xamarin.iOS/Android is a good choice anywhere developers want to run as close to the metal as they can. Xamarin Native still benefits from a shared .NET code layer, but the UI is written natively for each mobile platform. Additionally, Xamarin.Forms (see below) can now be embedded inside of Xamarin Native, thus getting the best of both worlds.

Xamarin.Forms

What started out as a prototyping tool for cross-platform abstractions has grown into what we call Xamarin.Forms today. In addition to the shared .NET code, there is a layer of shared UI that stretches across platforms and renders corresponding native UI. This shared UI layer is an abstraction allowing developers to write .NET code/markup, which gets translated to native UI on each platform at/before runtime. Xamarin.Forms has the huge benefit of .NET developers not having to know the intricacies of building iOS/Android UI by hand.

Keep in mind though, Xamarin.Forms is trying to solve an incredibly hard problem - a consistent UI abstraction layer that renders native UI on platforms that are uniquely different. While Xamarin.Forms has a large breadth of control coverage, the developer community and partner ecosystems fill in the gaps with cross-platform UI. If developers are up for it and app demands it, developers can always jump down to native UI land from Xamarin.Forms by writing custom renderers for platform-specific behaviors or rendering native UI controls on a per platform basis.

So Why Xamarin Again?

The bottom line is, it is 2019 and hopefully mobile isn't an afterthought. A legitimate mobile strategy reduces developer frustration and allows for code reusability. If you are invested in web technologies, modern mobile web, hybrid or JS native apps are the way to go - you have rich tooling and plethora of native API access.

If however you want to go with the .NET option, Xamarin is an easy choice. Here are some indicators that will help you make up your mind that you want to choose the Xamarin technology stack:

1. You want to write C#/F# code
2. You are comfortable with XAML as a markup language
3. You care for maximum code reusability with other .NET projects
4. You want to stay within the comforts of Visual Studio
5. You expect a solid runtime, polished tools and a rich ecosystem

Convinced about Xamarin? Your code is in good hands and the future looks awesome.