Evaluating Xamarin

For the past couple of days I have been evaluating the Xamarin framework. Here are my thoughts:    

Storyboard Editor: 

Xamarin Studio Storyboard editor is quite slow as compared to Xcode. First, I thought that this might be on the first launch only but the slowness persisted after subsequent launches. Another problem I noticed immediately is when you are zoomed out to and click on any of the Storyboard scene then it selects "view" by default instead of selecting the "view controller". This really bugged me since when I am in zoomed out view I want to assign a custom class to the view controller instead of tinkering with the view. 

The Storyboard designer feels in a very fragile state. There are a lot of occasions where I was not able to delete the existing scenes on the designer. I also noticed that there is no way to select the segue from the designer. You have to expand the "Document Outline" to select the segue.  The Xamarin Studio also crashed multiple times after my Mac woke up from sleep. 

Auto generated Code Overriding Custom Code:

In Xcode when I add a custom UITableViewController class I don't immediately assign that class to my view controller in Storyboard. I usually write some code in my custom class and then finally when I am satisfied with the code I assign the custom UITableViewController class to the scene in Storyboard. I tried to do the same thing in Xamarin and unfortunately, that kicked in auto generated code which wiped all the custom code I wrote in my custom UITableViewController class. The workaround is to use the UITableViewController template for your custom table view controllers. 

One to One Method Name Matching .. Not Exactly: 

In the native implementation of the UITableViewDataSource protocol there is a method named "cellForRowAtIndexPath". If you try to find this method in Xamarin implementation it will yield no results. This is because in Xamarin it is called "GetCell". Now, I do agree that GetCell is a much better name but when you are reflecting another API in your framework you should not randomly name methods as you please. UITableViewDataSource's GetCell was easy to spot since I am quite familiar with it but what will happen when I am in an unknown territory then I will be sent on a wild goose chase to hunt down the equivalent method name in Xamarin.    

Consuming Third Party API:

In the native world if I have to consume some open source API then I simply copy and paste the source code in my own project and be done with it. Of course if I am feeling adventurous I can also use CocoaPods to manage my dependencies. In Xamarin  consuming existing Objective-C and Swift API's is not as simple. Check out the following link which explains all the steps you need to take to consume open source native API's implementing in Objective-C or Swift. 

http://developer.xamarin.com/guides/ios/advanced_topics/binding_objective-c/

Code Sharing:

One of the good features of Xamarin is that you can write your service layer entirely in C# and then consume it from iOS or Android application. Code sharing in Xamarin really depends on per app basis. If your service layer is composed of complicated objects then your code sharing percentage will be high. In my case the services are implemented in C# and returning JSON objects. So, yes the consuming party which is iOS and Android application should have their own custom code to iterate and populate their own custom objects. Once, again depending on your domain model it can be complicated or simple.

Community:

Xamarin has a large community but when compared to the native iOS community it is still very small. Community is also an important factor when choosing a product because if you are stuck on some issue or need help then you are more likely to get help from a larger, move active community rather than the small community. 

Bottom Line:

Xamarin is a good choice if your background is in C# and you don't want to either learn or train your team in the native Objective-C or Swift. There is also a code sharing aspect which really depends on the size of your app. For me Xamarin still has a long way to go before I use it in my application. I also like to test out the brand new frameworks which Apple puts out in Beta builds which are usually not available on Xamarin on day one.