.png)
The good thing about this is that it allows you to write applications that have a shared 'core' library of platform agnostic code (for instance connections to web services, in-app database, business logic) while the user interface is written individually for each platform, providing an a good user experience while allowing for some code-sharing. This is in contrast to writing the app twice, in either Java for Android, or Objective C for iOS, and also differs from fully cross-platform solutions like PhoneGap, which requires some compromise in terms of the user interface. I often say the benefit of Xamarin is you write your app 1.5 times instead of 2, while maintaining an optimal user experience.
The project I was tasked with was to create a mobile inspection app for building certifiers which was to replace a JQuery mobile website. The goals of the replacement app were to improve the offline support, which was subject to some limitation in HTML5 offline storage API's on iOS devices, to improve the user interface and to add some extra features like the ability to take photos of defects. Given these requirements, and especially that we really wanted to give a top quality experience for the user, I decided that a native app was the best way to go (note that I'm referring to Xamarin as native apps, which isn't technically correct however the terms native, hybrid and cross-platform are often mixed around. I consider hybrid to be a combination of native UI elements and webviews, others consider Xamarin to be hybrid).
Having decided on a 'native' app, it came down to writing it with XCode and Objective-C, or giving Xamarin a go. Envoy (the company I work for) specialise in .NET development, which is one factor, however I'm a believer in choosing the best tool for the job, and that learning new languages/technologies isn't something to be afraid of. In the end I went with Xamarin because it allows code sharing with a possible future Android version of the app, and because the core library could be built out faster in C#.
The app was finished in around 7 developer-weeks (including back-end work), and is live on the app store. After completing the app, and having worked on Objective-C iOS projects previously, I thought I'd share some of my observations on the current state of Xamarin.
The Good
Xamarin is a high quality product
One concern I had was that if Xamarin goes broke the code we produce is probably useless as the framework and tooling won't get updated for new iOS updates, however they are well funded and have been around for quite a while now in various forms, and just keep getting bigger and bigger. Updates are pushed frequently, documentation is well written and kept up to date, and they even put on a yearly conference that has some great presentations. They also have a partnership with Microsoft, and there's all sorts of rumours about Microsoft possibly buying them.
Our app ended up performing well and I didn't feel my development time was held back by the Xamarin product at all.
C# and Xamarin Studio fit in well with Cocoa Touch
I don't think Objective C is that bad, however there's no doubt that I found C# to be a more productive language, you can use Linq, Async/Await and some great .NET libraries including the SQLite.NET mini ORM. Xamarin Studio, which is their IDE for the Mac worked well, and integration with storyboards in Xcode works well enough.
Growing community
There is a growing community of developers who are making great things in Xamarin, there are open source projects like MVVMCross (which I chose not to use this time, but will look at in the future) that are actively contributed to and user groups around the globe full of developers. There are many blog posts and Stack Overflow questions that are Xamarin specific, which helps to accompany the official documentation.
The Bad
Missing out on iOS open source
This is the biggest one for me, so many components and UI widgets for iOS are available as open-source drop-ins to your app. Xamarin has a component store where they attempt to make up for this, however it still has a long way to go. For me, if I knew I was creating an app that was only ever going to be on iOS, this factor alone would probably mean I gave Xamarin a miss for that particular project so that I can make use of CocoaPods, however it's pretty rare that you know for certain you are never going to want an android version of an app.
Visual studio integration is flaky
Xamarin has a feature that allows you to write code in Visual Studio and have it remotely compile and launch on a network connected Mac. This was very flaky and slow for me, so I didn't bother with it, Xamarin Studio isn't too bad, and if you like you can develop your core library code as a separate PCL DLL on Windows so you can use NCrunch for increase test driven development productivity and then develop the UI of the app on the Mac.
Extra layer of potential bugs
While the Xamarin team are extremely smart, and have created a great platform, they are not infallible. There is still an extra layer of code between your app and the hardware which could cause bugs, either in the Xamarin code itself, or as a result of you needing to know about how both iOS and the Xamarin garbage collectors/compilation works. After we released the app, we wanted to add some image resizing features, and came across a memory leak (Xamarin ships their own garbage collector in your app) that we had a hard time fixing. After contacting support with a trimmed down app to reproduce the problem they indicated to us they found a bug in Xamarin and were going to push an update shortly. They also gave us a workaround which got us going straight away which was great, however it still cost us a few days of developer time debugging it.
Other things to note
Using Xamarin is not an excuse not to learn Cocoa Touch and bits of Objective C
My earlier point about not being afraid to learn new things applies here as you'll still be reading Objective C code from blog posts and Apple's official documentation. Xamarin just wraps the Cocoa Touch libraries so you'll need to understand how that works - it's different to the web, and different to WPF, so don't think you Xamarin is a choice to help you just use your .NET developer knowledge to ship an iOS app. A great book to get introduced is iOS programming for .NET developers.
License Fees
Xamarin licenses for companies are $999 USD a year, per platform. This isn't cheap, but compared to developers salaries, or some of the common license fees for Microsoft developer products this is as cheap as chips.
Overall
All in all I'm a fan of Xamarin and would definitely use it again in the future, however I wouldn't say it's what you should always use for mobile development, it's a matter of picking the best tool for the job, which may be an Objective C/Android app, a Xamarin app, PhoneGap or a responsive website depending on the project, budget, goals etc. I do however believe Xamarin should definitely be something you consider as a serious option.
Also..
I'd like to give some credit to Vanessa Grixti (@vgrixti) for the visual design/UX work on the Buildaform app, she did a great job working to a tight deadline. Also if you are looking for Xamarin mobile developers in Sydney, get into contact with Envoy, as I'd love to work on some more Xamarin projects.
No comments:
Post a Comment