The cross-platform mobile development framework Xamarin has been getting a lot of press lately, thanks in no small part to its recent acquisition by Microsoft. All this news coverage has some people scratching their heads and wondering what’s the big deal? Mobile frameworks are nothing new, so what sets Xamarin apart? And it’s made by Microsoft; doesn’t that mean it’s going to be closed source and Windows only?
The answer to the last question is a resounding “No.” It’s been widely reported already, but it’s worth stating again, Satya Nadella and the new Microsoft are embracing open source software and cross platform development. Many of Microsoft’s tools and platforms have already been made open source and are available on the Microsoft GitHub page. Microsoft has also greatly expanded its toolset for non-Windows users. SQL Server is available in Linux and Visual Studio Code is available for every major platform. The big news at Microsoft Build this year was that the Linux Bash shell would be coming to Windows.
Xamarin is no exception to the new Microsoft OSS strategy. It was announced at Build that the entire platform would be free and open source. One of the major hurdles to Xamarin adoption before the acquisition was its hefty price tag, so this was welcome news, indeed. And while there is, unfortunately, no Linux support for Xamarin development as of yet, Windows and OSX are both supported via Visual Studio and Xamarin Studio.
What are the Alternatives?
In addition to Xamarin, there are two basic approaches to mobile development. The first is pure native code. For Android that means writing Java, for iOS it means writing Objective-C, and for Windows Phone it means writing C#. The amount of work that can be shared between platforms is painfully low with this approach. Maintaining an application on all three platforms requires maintaining three completely separate code bases written in three different languages.
Despite the maintenance nightmare this can cause, native development does have its advantages. For one, it’s fast. Apps are optimized and compiled down to machine code to squeeze every bit of performance from the device. Also, the creators of the platforms have done an excellent job of documenting their SDKs, which is a great help when learning or troubleshooting. Additionally, access to the native SDKs and UI elements means it’s easy to create an app on all platforms that has the look and feel that users of that platform expect.
The second approach to mobile app development is to create a single application that targets a native platform wrapper. These are typically HTML5 apps leveraging a mobile framework such as Ionic that make calls to a wrapper such as Apache Cordova. These solutions solve the biggest problem of native development: writing and maintaining three separate code bases. The application makes calls to Cordova, which translates the requests and makes the proper calls to the underlying SDK for each platform.
The potential downside to this approach is that the benefits of native development are lost. It is difficult to achieve native speeds running Javascript against a native platform wrapper. Users have come to expect snappy performance and zero lag time and this is just harder to achieve in Javascript. The second issue stems from the fact that users of different platforms have different UI expectations. A single, middle-of-the-road UI approach can end up being frustrating for everyone. The Ionic team is making great strides to solve these issues, but for the time being it’s something that should be taken into consideration by mobile app developers.
Xamarin: Cross Platform with Native Performance
Xamarin is an attempt to create a best-of-both-worlds mobile development platform. All code is written in C# and compiled down to native assembly on each platform. In this way developers can have a consistent code base written in a single language that can be deployed to all three platforms. And because the code is compiled down to assembly Xamarin applications benefit from true native speeds. Xamarin projects are standard .Net projects, which means existing .Net libraries can be referenced and utilized without issue.
In addition, Xamarin is fully integrated into Visual Studio. Current .Net developers should have no trouble picking it up and understanding its conventions. The UI editors for all three platforms are fully integrated into Visual Studio, as well, and provide a consistent way to develop native UIs. At the time of writing NuGet, Microsoft’s package manager for .Net, currently shows more than 1,400 free plugins tagged with Xamarin. These plugins help to wrangle the cross-platform and cross-device peculiarities, such as display size and hardware-specific features, and provide a simple, consistent API for development.
While Xamarin’s consistent UI editors are a nice feature, it can still be troublesome manually creating a UI for each platform. Thankfully Xamarin provides a free plugin, Xamarin Forms, which allows a single UI to be created, from which three separate, native UIs are generated. This saves developer time and results in native UIs that users of each platform have come to expect. However, this approach is not without limitations. If fine grain control and specific branding requirements are necessary developers may find that they need to fall back to traditional platform-specific UI design.
…And Now the Bad News
Xamarin is not without its downsides. The Visual Studio integration is almost there, but glitches and crashes are not uncommon. This is especially true for the Xamarin provided Android simulator. While it is a step up from Google’s Android emulator, it is by no means perfect. It is slow and crashes are frequent. Developers and testers would be wise to get their applications on a real device quickly.
Another downside, specifically for iOS development, is that iOS apps require a Mac running XCode to build and deploy to the app store. All development can be done in Windows, but due to Apple restrictions a Mac is needed to complete this process. Xamarin makes it fairly simple to identify a Mac on the network and use it for this purpose, but it is one more inconvenience, and potentially an expensive one if you don’t already have a Mac handy.
The Xamarin community is growing, but it is still not as big as the community of native mobile developers or HTML5/Javascript developers. As such, documentation, tutorials, and Stack Overflow answers are still sparse at this point. The buzz is growing, though, and the new free price point should attract more users pretty quickly. The support will be there soon enough, but in the meantime debugging and learning are going to be a little slower than developers might like.
In Conclusion
Xamarin is a welcome addition to the mobile app development scene. It’s by no means a silver bullet, and there are certainly times when other approaches are more appropriate. But for the millions of developers out there already familiar with .Net it’s a great way to transition existing skillsets to the mobile space. Likewise, for current mobile developers looking for native speeds in a single, unified project Xamarin is definitely worth checking out.