We all thought it was happening last year. At /BUILD one of the most pervasive predictions was that Microsoft would announce that it was acquiring Xamarin (rumors go back to 2014) the increasingly popular cross-platform toolset that allowed developers with a C# background to build for multiple platforms with a shared C# backend. It didn't happen. However, Microsoft did announce an increasing partnership with the Xamarin team, and began building integration into Visual Studio 2015 including support for an Android emulator within our IDE (integrated development environment - not interactive as a previous version of this article stated) of choice. So, you may have seen developers going a little nuts with the news this week that Microsoft are acquiring Xamarin for $400M and be wondering why exactly that is, and what it means for the future of both companies. I'm going to do my best to explain what Xamarin is, what it is not, and what might happen now that Microsoft will own it. Best VPN providers 2020: Learn about ExpressVPN, NordVPN & more Full disclosure: I am not Xamarin certified so this will be a distillation of knowledge picked up from dabbling with the products and the various presentations I've seen from Xamarin employees. What is Xamarin?

Xamarin is a company that builds tools for developers, and has two particular products that I'm going to call out specifically; Xamarin Platform, and Xamarin Test Cloud, both of which will no doubt have been appealing to Microsoft in the acquisition. The Xamarin platform is what most of us are excited to see joining Microsoft, and there are a couple of important sub-products which you'll hear more about in the future I'm sure: the shared C# project, and Xamarin forms. For C# developers, the platform allows us to write all of our logic in that one language, allowing for much of it to be shared across solutions. We then write the specific front-end markup and/or code for each native screen (i.e. XAML for Windows). Of course there will always be a few specifics for each platform – you won't be pinning a live tile on Android for instance – but the majority of the code should be shareable. Xamarin forms is an attempt to take away those platform specifics, by giving a universal UI language that will map to the relevant platform's controls depending on where it is running. In my experience, it has limitations and usually results in some fairly basic UIs being created. However, I'm given to understand that the newer versions have made great strides. You may wonder what the benefit is to Xamarin compared to other cross-platform tools, of which there are several. Many of Xamarin's rivals use web technologies to deliver their solutions, which usually incur significant performance costs compared to coding in the platform's native language. Xamarin's code is compiled into native code for each platform using their tools rather than being interpreted – in simple terms it's substantially faster, matching or sometimes beating the usual languages. In fact, there is an excellent independent test performed by Harry Cheung (an ex-Googler) here which places Xamarin above Objective-C on iOS for performance (but below Swift) and above Java on Android.

Xamarin Test Cloud provides incredibly powerful service for developers on all platforms which allow for automated testing on almost every device imaginable from one deployment. Developers write test scripts which will be used to confirm the app is working as expected and these tests are then deployed and run on a myriad of devices. It's worth noting these are actual devices off in a Xamarin warehouse all working around the clock rather than virtualized tests. When you imagine the number of possible devices for iOS, Windows and especially Android: the value to developers is clear. What isn't Xamarin? In a word, cheap. I expressed it in an image earlier on twitter, Xamarin is not an inexpensive proposition. Understandably so, as they have built a series of excellent products and have a team dedicated to ensuring they offer 100% coverage of all native APIs. That means the second an Android or iOS release goes live they have to make sure they are mapping/exposing the new platform capabilities to their C# writing customers.