First Week with Xamarin
Why I turned heels on Apple’s own solutions.
EDIT 2016–06–05: This is an old article and things have changed for both Xamarin and Apple. Swift is now my beloved language and I hate how Xamarin has become. Let’s see how Microsoft will handle it!
We’ve been thinking about what to do with our iOS app for a while. After painfully discovering how Titanium got in the way of any ambitious plans we had, we had to find a better solution.
That’s when the whole question of native development vs everything else came back on the table. After a few months month of trials and errors with both native XCode/Objective-C and Xamarin, I finally took decision that I would use Xamarin to develop our next app.
One of the main contributing factor as of why I made this choice was how easy it was to jump in the code and code away without even referencing to any docs because of its C# and .NET usage.
Having such ease of use/code, very strong aesthetics and plug-and-play device debugging seemed like a fair competitor to Apple’s own IDE.
Installation & Docs
Keep in mind that I used the iOS side of things, I have yet to touch Android or Windows development with Xamarin.
After downloading it, installing it was as easy as with any other Mac application. I started it and immediately found the UI very polished, that pleased me coming back from an Eclipse-based IDE. I immediately felt at home using C# and Microsoft’s .NET framework.
I opened up the settings and only had to input my Apple’s developer credentials to get all my certificates and provision profiles up and ready to use.
Then, I started checking their docs out. To my own surprise, it’s complete and has working examples. There’s even fully working solutions for you to play with to get started more easily.
What I liked the most was the completely transparent way of handling iOS’ APIs. It worked exactly like doing Objective-C except every API call you do is in C# but works exactly like its equivalent. For example if I want to use a simple color I’d simply use UIColor.Red or to add an UIImageView, assign an UIImage to it and add it on a view, I’d go with:
UIImageView imageView = new UIImageView(UIScreen.MainScreen.Bounds); imageView.Image = UIImage.FromBundle(“name_from_resources”); View.Add(imageView);
Not bad uh? Actual development is a lot faster with C#, but that’s down to personal opinion.
Rough edges? Not so much.
That’s where you ask me, but what’s wrong about Xamarin? At the end of the week, I encountered only one annoying Xamarin-related bug that was happening only when ran on a device which is another thing that Xamarin does out of the box. (Plug an registered device and debug away!)
It was very weird as I wasn’t able to assign a UIColor to a UITabController.TabBar.TintColor when on device but it was working on simulator. So I opened a thread on their forums and within the hour I’ve got a response for one of Xamarin’s staff member asking me to testing something and confirm which I did.
He had indeed found the bug, suggested how to fix it in my current solution and everything else went as smooth as possible. It’s great to be able to make some nerd talk with another developer, it’s also fun to know what’s great and not so great within their platform from a transparent point of view.
I’ve been amazed by how easy and fast it is to get up working on an iOS project. Everything just worked as intended which is a major feat for such platform nowadays.
As for what’s next for me, I’ll keep using Xamarin and will be proud to be using it and contributing to its future.
Check out the original article on my personal blog.