An old friend of mine, who I worked with back when I was a .NET developer, emailed me recently. He was looking for some advice on which platform to use for creating iOS software, mostly focusing on native versus Xamarin (MonoTouch). My answer does not delve into specifics about Xamarin, because it’s been years since I used their platform in earnest. It does, however, express my opinion on native vs. non-native. He left out other options, such as PhoneGap, perhaps because he simply was not yet aware that they exist.
Below is his email, followed by my reply. I don’t expect this to settle the matter once and for all (where’s the fun in that?!) but perhaps it will give others a new perspective on the topic.
His Question
Since I have started playing around with iOS, two questions that came to my mind and I thought I should ask you.
To be or not to be native iOS?
Xamarin or not to Xamarin?
My real purpose is
- to create some productivity apps for handheld devices and
- to create some re-usable control libraries.
It will be great if you can share your expertise on this 🙂
My Reply
Your question is a good one, which I’ve discussed with many people. So far my answer is broken down into three considerations:
- Reach – Is getting the same codebase onto as many devices as possible a high priority, or are you more interested in keeping the app on one operating system for the first launch (in order to create the best app possible – no compromises)?
- User Experience – Are you willing to make sacrifices in the user experience to use a non-native layer (ex. building HTML-based UI via PhoneGap)?
- Budget – Can you afford to build a separate app for each platform? If so, that’s probably the best route since you won’t need to rely on lowest common denominator solutions that bring their own bugs and limitations to the table.
In your particular case, the re-usable control libraries should be native because I doubt that such performance-sensitive, low-level rendering code would be reusable via Xamarin’s platform across different OS’s. You can always wrap your native libs with their runtime wrapping API, which I read about a while back, and use them from Xamarin apps if necessary.
Regarding the productivity apps, I don’t know enough details about your situation to say anything definite. Using Xamarin for those apps might make sense, and you will probably have a temporary advantage of avoiding the learning curve associated with native iOS programming (note: I wrote temporary). Truth be told, learning native iOS programming isn’t all that difficult, it just takes time and a little brain rewiring. Also, when working with Xamarin, or PhoneGap, you often end up dealing with Objective-C code anyways (plug-ins, StackOverflow examples, etc).
I have a bias toward native since it is inherently better than any 3rd party layer, and I’m not interested in dealing with the bugs of Apple and another company as well. Unfortunately, technical preferences don’t usually drive business decisions!
iJoshSmith 
Interesting post. I also have a preference for native. I was very enthusiastic about cross-platform libraries a few years ago. Then I used one and that all changed. lol I see a lot of negative comments from users of apps that just “feel” like they’re holding back because they rely on a layer that may not support a native feature (i.e. implements some kind of “approximation”), and of course the HTML ones get a bad rap (my bank’s app is like that, and it’s less than impressive…)
If a company is serious in supporting multiple mobile platforms, my opinion is that they’re better off sharing as much “business layer” code as possible – which shouldn’t be too hard if written in a language available on all platforms (famous last words?) – and spend the extra effort in building a native UI for each one that make the users feel at home.
Pingback: Dew Drop – January 7, 2013 (#1,476) | Alvin Ashcraft's Morning Dew
@Josh: I completely agree with you opinion about using a native language is always the best path to choose. I’m currently reading you excellent book in which you express your opinion further, but also mentioning some cons of Objective C, like the absence of a standard XML parser and support for SOAP web services.
Last month Xamarin released a new version with a much better IDE and a further enhanced native compiler. I’ve tested it shortly and must say it looks very good. Also I hear many comments that say the performance is not noticeable lower than Objective C.
So my question would be: do you still believe Objective C is a much better choice than Xamarin iOS?
Marc,
A better choice in what context?
I haven’t tried Xamarin 2.0 yet so I can’t compare it to anything. However, my list of cons for Xamarin didn’t include performance of their compiled code. My primary concern is relying on a third party to expose a stable subset of the native API that my apps need. Also, third parties are inevitably playing catch-up in terms of supporting the latest features in their tooling, such as Storyboards. I read that Xamarin 2.0 apps can be written in Visual Studio, which is neat, but you must use Xcode to create user interface files (XIBs). To me, that’s a huge drawback because I am editing XIBs all the time.
The idea of Xamarin appeals to a lot of people, so it might succeed in the market. I would only consider using it if my client needed an app to run on Android and iOS, didn’t have the budget to develop both apps separately, and had .NET devs on staff. In all other situations I would much rather go native, to avoid the headaches introduced by third party software.
Josh
I completely agree with you Josh, Pardon with my English, I just wanna share my experience here.
I am a long time C#/Java programmer and I had a lot of sleepless night before I decided on where and how to begin on creating a phone apps that whould link to our data. Lets face it, Objective-C is an ugly language. Its like being made hard for no reason. But nevertheless I tried diving into both Xamarin and Objective-C.
Xamarin is like homecourt advantage for me but I find it wierd going back and fort from Xamarin Studio to Xcode and most erritated part is you have to renew every year to stay updated cause everytime Xcode will be updated the Xamarin should made an update too cause its a third party.
When I start burning my eyebrow and have patience learning this stupid square bracket language(Objective-C) then it started opened my mind. I realized that building phone apps specially in data driven apps, it does not require a lot of logic in the client side. So in my case I used WCF in our web server and put a lot of heavy stuff over there using C# then retun a clean JSON data that would be just easilly deserialized in client side(iPhone). Then all you need to learn in Xcode is just some basic MVC stuff which is same principle in MVC.NET.
Great feedback, Ray. Thanks for sharing your thoughts on this.
I don’t find Objective-C to be ugly after years of using it, but maybe that’s just a matter of personal preference. I’ve recently been working on an Android project and have found Java, C#’s close relative, to be verbose. Obj-C code can be quite minimal, which I like, but that also comes at the cost of limited compile-time error checking (which is where a language like Java shines).
Josh
if you don’t want to just stick with ios, take a look at this PCL + mvvmcross + xamarin
Amazing stuff…
Hey Ray, you said that the most irritated part is to renew the developer account of Apple to stay updated . Is that means you no need to renew if you are using Xamarin ??. My answer is no . Without an updated Xcode how will you create a native UI for updated OS or how will you generate provisional profiles/Certificates for debugging or how will you upload an app to AppStore. LOL , please give me the exact reason where you can avoid Xcode using Xamarin .