Why I Chose Xamarin for My Big iOS Project

About a year ago I started on the first phase of what was to become a multiphase project to create a data collection app for a client. They wanted to target iPad, and they wanted a proof of concept (for money) that their idea could work. Having already written a few apps in Objective-C, I was not relishing the idea of cranking out another code pile in Xcode with a large collection of .h and .m files.

I’d heard about this MonoTouch product that was out there that would allow a developer to compile .NET into native apps, and even be able to share code from server to iOS to Android. I figured that could be a selling point. So I got some POs together and made my pitch. Somehow I got my POs signed.

So that was a while ago, and now I’m working on the full app after the POC was a smashing success. I can say wholeheartedly that despite the many challenges with using Xamarin (not least of which is the yearly price tag), I made the right choice. It’s been a dream writing code for iOS using .NET instead of Objective-C.

It’s The Little Things

The fact is, a Xamarin.iOS app is still a Cocoa Touch app. To launch, the app still needs to do all the things that an app written with Xcode would. It still will use UIViewControllers and all the other UIKit stuff, and run on an NSRunLoop and at the heart of it, the app integrates to the OS using bindings to the native libraries. In fact, these things add some small amount of operational overhead and the occasional debugging challenge.

But it gives you a lot of little things that sum up to a great advantage over using Objective-C. Some of my favorites:

  • Combined interface and implementation – No annoying header and source files to mess with.
  • Events – Notifications are cool, but the open structure of them makes it easy to use them improperly. And sure, there are other ways to facilitate this sort of inter-module communication, but at the price of more engineering or learning weird design patterns that apply only to this 40-year-old programming language.
  • No pointers – I learned OOP on C++, and I love pointers. I know that there are pointers under the hood. Making well-designed software depends on understanding how the computer actually executes my program. But giving the developer access to the pointers makes every program he or she writes into a 200-level Intro to OOP exam–an exam designed to make sure you know how the computer deals with this stuff. In the real world, and especially the consulting world,  you don’t lose points for little mistakes, you lose time (read: money).
  • Generics – In my opinion, this is a HUGE thing. One of my biggest frustrations with Objective-C was the way it handles types. I get it, the whole language is built around dynamic typing and it doesn’t need generics. My beef isn’t with how it works. My beef is with how “how it works” affects my team’s ability to produce quality software. A big benefit of strong typing compared to weak typing is that a higher proportion of  valid programs will also be correct programs.

The purist might be inclined to say that these are all nothing more than syntactic sugar, which is true. But when it comes to making good software quickly, syntactic sugar is key. Little things that enforce constraints, reduce the potential for bugs and save code will help generate better code quicker, a little bit at a time. And better code means fewer bugs in dependent code, so the gains are compounding.

It’s Not All About Me

But if it were, I’d probably still chose this route. Objective-C developers are not easy to find in the middle of Wisconsin, but just about every developer resume I’ve seen has .NET on it–quite a few with certifications even. For my team, Xamarin means that iOS is easily within every developer’s grasp. The iOS APIs are much easier to come to terms with when they don’t also have to figure out the unusual syntax of Objective-C at the same time.

With one solid Apple developer to every few .NET devs, a team can easily find their way through a complex mobile project. At the end of a couple of those, you have a team of decent mobile developers that can potentially move up a level and handle their own team. Rookie developers can come in and learn the trade and spend their sleepless nights solving our clients’ problems instead of wrestling with the platform.

Disclaimer: I don’t want to underestimate the ability of graduate-level employees. They are brilliant, and I know that one of these days a particularly sparkly one could come in and do my job better than me. Anyone can learn Objective-C. But with Xamarin they can hit the ground running and spend far less time on the bench before they become productive.


Like I said, my project is nearly finished with its second phase, and there are many more to come. I’ve estimated that using Xamarin has cut at least half of the development time off the project, considering gains across the team and cross-platform code reuse. We were able to build a data model layer that has a single code base across the server and the device. We couldn’t use much of anyone’s specific experience in ASP.NET, Windows Forms or the like, but Visual Studio made a great place to explore Apple’s API while still being able to use familiar collections and reflection APIs.

There are a few hiccups, like when a crash happens at the native library level and no indication is given as to what code is causing the issue or when a 3rd party vendor of an iOS library refuses to support my app simply because it uses Xamarin. But we’ve had a great deal more success. New developers have joined the project and been able to pick right up because they’re already familiar with Visual Studio and .NET. We can keep our code in a TFS repository and use an ALM-esque process, which is attractive to our customers, most of whose IT stack is pretty much purely Microsoft, with Lotus Notes thrown in occasionally.

In summary, it’s been great. I feel a bit defensive talking about why I chose this framework, because it costs a thousand bucks per developer. There are a lot of free options out there (including native), and why use one of those when there’s free? Well, I didn’t necessarily start out having all the reasons, but sometimes hunches pay off.

Thanks for reading!

Comments (3)

  1. Hi Aaron.
    This is a very interesting article. I must be honest. I’m a developer and the same way you did, I started with C++ and built my way through the Win32 API/MFC to reach the Android and iOS API-s when they became popular. These days I’m mostly programming in Objective-C and C#, and I couldn’t find a very good opinion on why should I make a switch to a XAMARIN Studio. But there is actually one thing that concerns me. I use quite a lot of blocks in my code, so I wondered does XAMARIN allow you to use these sorts of lambdas and passing them as a function parameters?
    Thank you.

    • Hello Antonio, thanks for reading! First, the quick answer to your question: yep, lambdas are supported and encouraged by the Xamarin API. At one point I remember reading and article that talked about some potential issues with lambdas causing memory leaks, and I’m not sure if that was resolved or not, but I haven’t yet noticed any (I suppose that doesn’t mean they don’t exist, though). LINQ works great despite the limitation imposed by iOS on JIT (I only ran into an issue with JIT once or twice, and there are hundreds of LINQ expressions with lambdas in my current project).

      A goodly portion of this article to illustrate how I could justify paying money to add overhead to my software–the idea of adding an extra layer to a piece of software that actually makes my software use a bit more memory and run a bit more slowly is absurd (for the record I haven’t really noticed any perceptible performance issues due to the Xamarin framework). But when you start analyzing it from the business perspective, it starts to make more sense. I can create software much more quickly and reuse code between platforms, and being able to use developers who only know .NET means I find people to hop right into projects much more easily. They are becoming more numerous, but I still don’t have many resumes that list Objective-C experience cross my desk.

      Thanks again for reading, and the best of luck to you in choosing your way forward.

      • Hello again.
        First, thank you for the quick and prompt answer. I actually have couple of people here who are very good .Net developers, but they never worked “close to the metal” if you know what I mean (plain old C), so I could never ask them to participate iOS (CF stuff) and Android NDK programming since they mostly did .NET on WP. We build an enterprise class software that’s built for the specific needs of the companies we work for, so the visual design isn’t that important, but the functionality and the time frame is. And if we can save some time and increase our productivity by spending some bucks I think it’s definitely worth it. Thank you so much for this tip and a great review, and apologies if I made any grammar mistakes, because English isn’t my native language.

Leave a Reply

Your email address will not be published. Required fields are marked *