Introduction to Xamarin mobile apps
Back in 2000 Microsoft announced a new software framework called .Net, along with a new programming language called C#. Not long after this, a company called Ximian (founded by Miguel de Icaza and Nat Friedman) started working on Mono, a free implementation of the .Net framework and the C# compiler that could run on Linux.
Fast forward 16 years and Nat Friedman is standing on stage at the Xamarin Evolve conference giving the keynote talk - physically in front of sixteen hundred mobile developers and virtually in front of tens of thousands more. He's speaking about how Xamarin enables a mobile-optimized development lifecycle. Xamarin (the company that grew out of the ashes of Ximian and provides the tools and technology to build cross-platform mobile apps) had just been bought by Microsoft for a rumored half a billion US dollars, and had become a key part of the Microsoft 'Mobile first, cloud first' strategy.
Xamarin is now a well-known term amongst the mobile developer community, and is starting to be well known in other Microsoft based developer circles. But what do we mean when we talk about 'Xamarin Mobile Apps', and what does Xamarin give us above and beyond other tools? To really see the benefits first we need to look at how apps are built using the vendor provided development environments, or other crossplatform tools like Cordova, and compare them to what Xamarin offers us. We can do this by looking at two of the main types of developer - an indie developer working on an app in their spare time and a corporate development team building an app for their customers. We'll start by considering what the differing needs are in terms of platform support for each scenario, then compare the possible options.
First let's take the example of an indie developer who's come up with the idea of the millennium for a killer app that they want to sell to consumers on the app store - FlappyFoo.
Second we can take the example of a large corporation, FooCorp who want to build an app to help their customers with their DailyFoo app.
For each case there are four options to choose from when building these apps, and these are outlined in figure 1.1. In this diagram we can see four different mobile development platforms you could choose - vendor specific apps using the development environments from Apple and Google, Cordova, Xamarin native using Xamarin.iOS and Xamarin.Android, and Xamarin.Forms. This diagram shows the programming languages used, and where code can be shared for each layer of the app - from the application layer (the thin wrapper around the rest of the app that makes it into something that can be run on each platform), down through the UI layer to the business logic layer. The boxes are not to scale, but just a representation of the layers. Your app could be heavy on UI but light on logic so the UI layer would be bigger, or vice versa. Let's now look at these in more detail.
1.1.1 Vendor-specific native apps
Each different OS comes with a different set of API's, a different paradigm for building the user interface, a different way of handling user interactions and, most frustratingly, a different programming language (or choice of languages) for you to use. If you want to build an app for Apple's iOS based devices such as iPhones and iPads you need to program in either Objective-C or Swift. For Android phones and tablets you need to program in Java.
For each platform you will end up building the entire app from the user interface layer right down to any in-app business logic all in the vendors preferred language, as shown in figure 1.2.
For our indie developer this is a big problem. For FlappyFoo to be a success it will need maximum reach - and this means both iOS and Android versions. To achieve this the indie developer will have to learn 2 programming languages. To learn these different languages there's more to learn than just the language syntax - they will have to learn different tools, different ways of getting access to third party code, the different words developers use to express each concept, and different design patterns that make up standard apps. This is a big task.
Even if the developer is a polyglot and happy in multiple environments there is still the issue of time. They will have to code the same app twice, implementing the same logic just in different languages. Time to market is key, and if the developer hits only one platform to start with there's nothing to stop copycats flooding the other platform quicker. FlappyFoo may dominate the iOS app store but could lose serious revenue to FlappyBar from another developer on Android.
For our corporate team the biggest issue is cost. To reach multiple platforms usually means one team per platform with the associated developer and organizational costs. This can be especially problematic if you consider the difficulties in finding, hiring and retaining good developers. Ideally you want to be able to release simultaneously on all platforms, and have each new feature replicated to both platforms and released simultaneously. This is hard if you have managed to employ five Android developers but only two iOS (an easy scenario as it's much easier to find Java developers in the corporate environment to help with the Android version than it is to find Objective-C or Swift developers).
Thinking of our customers who use DailyFoo every day to track their Foo, the last thing we want is for them to change platform, find out the new platform is missing a killer feature from DailyFoo and they jump ship to MyBar from BarCorp.
It's not all bad though. The one thing you can always be sure of when writing an app using the vendor provided tools is that you are always building a truly native application that will be as high performance as possible and supports everything that the OS and devices have to offer. Whenever an OS update is released the tooling is always updated to match giving you access to all the newest features that your users want to have. This is an important consideration as app users are fickle. They will quickly drop an app for a competitor if it's not up to scratch, it's slow, clunky or just not well integrated into their device.
