So what is Xamarin?
Xamarin is a cross development platform for developing native applications in C# for iPhone, android, windows phone and Mac. Xamarin comes in two flavours, the first is a proprietary IDE named Xamarin Studio that runs on Mac and windows and the second is a direct integration with Microsoft Visual Studio. With later versions of Microsoft Visual Studio Xamarin comes pre-installed.
Why has Xamarin been so successful in the mobile space?
Typically when developing mobile applications, to see true success, your apps need to be created for more than one platform. As of writing this post there is a rough 50 / 50 split between iPhone and android devices active in the market place (discounting windows phone etc…).
With this requirement for success, there comes an issue; android applications are written in Java, and iPhone application in Objective-C, windows phone in C#. The big issue is that before Xamarin came around, you needed to know three different programming languages to be able to deliver an application to each respective App Store.
Xamarin came along and brought the ability to learn one programming language, and develop applications in a cross platform methodology. This means that developers can write an application for all 3 core platforms in one language, allowing you to share code among your applications.
For all windows based developers working with .net and C#, it has also introduced an awesome opportunity to navigate into the mobile space with ease, enabling transition to Xamarin quickly from a .Net background.
What about compilation, is my app truly native?
The simplest answer here is yes. Unlike many other offerings on the market, Xamarin truly produces a native application binary for each individual platform. From Apple perspective the app appears just as if it had been built in XCode in Objective-C.
Some points of note, each platform has a slight difference when it comes to the compilation of your app, and this has to do with the type of compilation that occurs:
- IOS – When working with IOS, your C# code is compiled into ARM assembly language with ahead-of-time compilation (AOT). With your application the .Net framework is included, however with all unused classes stripped out, which in turn reduces your application binary size. There are several limitations to AOT, and one example which is based round an apple restriction is the restriction on running dynamic runtime generation code, i.e. using System.Reflection. In simplest terms Apple don’t want apps on their app store that have the potential to do more than they are supposed to.
- Android – Android uses just-in-time, and is compiled to IL, as above the application includes the .Net framework, however with unused classes stripped out. Apps run side-by-side with Java/Dalvik and call native types via JNI
(Dalvik – this is a process virtual machine in the Android operating system / JVI – This is an acronym for Java Native Interface and is a programming framework that enables Java code in Java Virtual Machine to call and be called by native applications and libraries written in different languages)
Do I need a Mac to develop an iPhone app?
You do not need a Mac to develop an iPhone app is the simplest answer, however to actually build your app and prepare it for submission to the app store you would. You can currently use Microsoft Visual Studio to develop apps for IOS, and Xamarin have created some pretty clever tools to link up your Mac on your network so that you can test and debug your app in the iPhone Simulator directly from within Visual Studio.
What options are there for sharing code in Xamarin projects?
When setting out your project you have two options when it comes to sharing code among your different target platform, these are:
- Shared Projects – This is a special project type which allows you to share the exact same code across different platforms. This project type makes the classes and files enclosed appear to your platform specific project as if they were directly included.
- Portable Class Libraries (PCL’s) – This type of project works in a similar way to a standard class library, however with somewhat of a limitation; that limitation is that dependent upon the number of platforms that are being targeted, the library will only include a limited subset of the .Net framework. The more platforms the less cross platform .Net classes are available due to limitations on each platform.
So when it comes to designing and laying out your project, you would typically create 3 projects in your solution (assuming that you are only building for IOS and Android), these would be the following:
- Core Project – This project can either be a PCL or a shared project as outlines above, and will be where you share all of your cross platform code. Typically this is going to be code which is not tied to the UI of each platform, i.e. Database logic, webservice logic etc…
- Android Project – This project will be where you develop your android specific code, and will reference your Core Project.
- IOS Project – This project will be where you develop your ios specific code, and will reference your Core Project.