How to decide between MonoTouch and Objective-C?

Question

After sitting through a session today on Mono at a local .Net event, the use of MonoTouch was 'touched' upon as an alternative for iPhone development. Being very comfortable in C# and .Net, it seems like an appealing option, despite some of the quirkiness of the Mono stack. However, since MonoTouch costs $400, I'm somewhat torn on if this is the way to go for iPhone development.

Anyone have an experience developing with MonoTouch and Objective-C, and if so is developing with MonoTouch that much simpler and quicker than learning Objective-C, and in turn worth the $400?

Solution 1

I've seen this question (and variations on it) a lot lately. What amazes me is how often people respond, but how few answer.

I have my preferences (I enjoy both stacks), but this is where most "answers" start to go wrong. It shouldn't be about what I want (or what anybody else wants).

Here's how I'd go about determining the value of MonoTouch - I can't be objective, obviously, but I think this is pretty zealotry-free:

• Is this for fun or business? If you wanted to get into consulting in this area, you could make your $399 back very quickly.

• Do you want to learn the platform inside-out, or do you "just" want to write apps for it?

• Do you like .Net enough that using a different dev stack would take the fun out of it for you? Again, I like both stacks (Apple and Mono), but for me MonoTouch makes the experience that much more fun. I haven't stopped using Apple's tools, but that's mainly because I really do enjoy both stacks. I love the iPhone, and I love .Net. In that case, for me, MonoTouch was a no-brainer.

• Do you feel comfortable working with C? I don't mean Objective-C, but C - it matters because Objective-C is C. It's a nice, fancy, friendly OO version, but if pointers give you the heebie-jeebies, MonoTouch is your friend. And don't listen to the naysayers who think you're a dev wuss if it happens that you don't like pointers (or C, etc.). I used to walk around with a copy of the IBM ROM BIOS Pocket Reference, and when I was writing assembly and forcing my computer into funny video modes and writing my own font rendering bits for them and (admittedly trashy) windowing systems, I didn't think the QuickBasic devs were wusses. I was a QuickBasic dev (in addition to the rest). Never give in to nerd machismo. If you don't like C, and if you don't like pointers, and if you want to stay as far away from manual memory management as possible (and, to be fair, it's not bad at all in ObjC), then... MonoTouch. And don't take any guff for it.

• Would you like to target users or businesses? It doesn't matter much to me, but there are still people out there on Edge, and the fact is: you can create a far smaller download package if you use Apple's stack. I've been playing around with MonoTouch, and I have a decent little app going that, once compressed, gets down to about 2.7 MB (when submitting your app for distribution, you zip it - when apps are downloaded from the store, they're zipped - so when figuring out if your app is going to come in under the 10MB OTA limit, zip the sucker first - you WILL be pleasantly surprised with MonoTouch). But, MT happiness aside, half a meg vs. nearly three (for example) is something that might be important to you if you're targeting end users. If you're thinking of enterprise work, a few MB won't matter at all. And, just to be clear - I'm going to be submitting a MT-based app to the store soonishly, and I have no problem whatsoever with the size. Doesn't bother me at all. But if that's something that would concern you, then Apple's stack wins this one.

• Doing any XML work? MonoTouch. Period.

• String manipulation? Date manipulation? A million other little things we've gotten used to with .Net's everything-AND-the-kitchen-sink frameworks? MonoTouch.

• Web services? MonoTouch.

• Syntactically, they both have their advantages. Objective-C tends to be more verbose where you have to write it. You'll find yourself writing code with C# you wouldn't have to write with ObjC, but it goes both ways. This particular topic could fill a book. I prefer C# syntax, but after getting over my initial this-is-otherworldly reaction to Objective-C, I've learned to enjoy it quite a bit. I make fun of it a bit in talks (it is weird for devs who're used to C#/Java/etc.), but the truth is that I have an Objective-C shaped spot in my heart that makes me happy.

• Do you plan to use Interface Builder? Because, even in this early version, I find myself doing far less work to build my UIs with IB and then using them in code. It feels like entire steps are missing from the Objective-C/IB way of doing things, and I'm pretty sure it's because entire steps are missing from the Objective-C/IB way of doing things. So far, and I don't think I've sufficiently tested, but so far, MonoTouch is the winner here for how much less work you have to do.

• Do you think it's fun to learn new languages and platforms? If so, the iPhone has a lot to offer, and Apple's stack will likely get you out of your comfort-zone - which, for some devs, is fun (Hi - I'm one of those devs - I joke about it and give Apple a hard time, but I've had a lot of fun learning iPhone development through Apple's tools).

There are so many things to consider. Value is so abstract. If we're talking about cost and whether it's worth it, the answer comes down to my first bullet item: if this is for business, and if you can get the work, you'll make your money right back.

So... that's about as objective as I can be. This is a short list of what you might ask yourself, but it's a starting point.

Personally (let's drop the objectivity for a moment), I love and use both. And I'm glad I learned the Apple stack first. It was easier for me to get up and running with MonoTouch when I already knew my way around Apple's world. As others have said, you're still going to be working with CocoaTouch - it's just going to be in a .Net-ized environment.

But there's more than that. The people who haven't used MonoTouch tend to stop there - "It's a wrapper blah blah blah" - that's not MonoTouch.

MonoTouch gives you access to what CocoaTouch has to offer while also giving you access to what (a subset of) .Net has to offer, an IDE some people feel more comfortable with (I'm one of them), better integration with Interface Builder, and although you don't get to completely forget about memory-management, you get a nice degree of leeway.

If you aren't sure, grab Apple's stack (it's free), and grab the MonoTouch eval stack (it's free). Until you join Apple's dev program, both will only run against the simulator, but that's enough to help you figure out if you vastly prefer one to the other, and possible whether MonoTouch is, for you, worth the $399.

And don't listen to the zealots - they tend to be the ones who haven't used the technology they're railing against :)

Solution 2

There is a lot of hearsay in this post from developers that have not tried MonoTouch and Objective-C. It seems to be mostly be Objective-C developers that have never tried MonoTouch.

I am obviously biased, but you can check out what the MonoTouch community has been up to in:

http://xamarin.com

There you will find several articles from developers that have developed in both Objective-C and C#.

Solution 3

So, my answer to a previous similar question is to learn Objective-C. (Also, don't forget about debugging support)

This will probably offend some but to be honest, if you are going to do any serious development, you should learn Objective-C. Not knowing Objective-C in iPhone development will just be a hindrance. You won't be able to understand many examples; you have to deal with the quirks of Mono whereas if you had a working knowledge of Objective-C you could get a lot more out of the platform documentation.

Personally, I don't understand the position that says increasing the amount of information you need in favor of using Mono over the platform's native language. It seems somewhat counterproductive to me. I think if this is a very expensive proposition (learning a new language) then it may be worthwhile spending some time on fundamental programming concepts so that learning new languages is a fairly cheap proposition.

Another user also wrote this:

---

Monotouch is easier for you now. But harder later.

For example, what happens when new seeds come out you need to test against but break MonoTouch for some reason?

By sticking with Mono, any time you are looking up resources for frameworks you have to translate mentally into how you are going to use them with Mono. Your app binaries will be larger, your development time not that much faster after a few months into Objective-C, and other app developers will have that much more of an advantage over you because they are using the native platform.

Another consideration is that you are looking to use C# because you are more familiar with the language than Objective-C. But the vast majority of the learning curve for the iPhone is not Objective-C, it is the frameworks - which you will have to call into with C# as well.

For any platform, you should use the platform that directly expresses the design philosophy of that platform - on the iPhone, that is Objective-C. Think about this from the reverse angle, if a Linux developer used to programming in GTK wanted to write Windows apps would you seriously recommend that they not use C# and stick to GTK because it was "easier" for them to do so?

---

Solution 4

Using Mono is not a crutch. There are many things that it adds to the iPhone OS. LINQ, WCF, sharable code between a Silverlight app, an ASP.NET page, a WPF app, a Windows Form app, and there's also mono for Android and it will work for Windows Mobile as well.

So, you can spend a bunch of time writing Objective-C (You'll see from many studies where the exact same sample code in C# is significantly less to write than OC) and then DUPLICATE it all for other platforms. For me, I chose MonoTouch because the Cloud App I'm writing will have many interfaces, the iPhone being only one of them. Having WCF data streaming from the cloud to MonoTouch app is insanely simple. I have core libraries that are shared among the various platforms and then only need to write a simple presentation layer for the iPhone/WinMobile/Android/SilverLight/WPF/ASP.NET deployments. Recreating it all in Objective-C would be an enormous waste of time both for initial dev and maintenance as the product continues to move forward since all functionality would have to be replicated rather than reused.

The people who are insulting MonoTouch or insinuating that users of it need a crutch are lacking the Big Picture of what it means to have the .NET framework at your fingertips and maybe don't understand proper separation of logic from presentation done in a way that can be reused across platforms and devices.

Objective-C is interesting and very different from many common languages. I like a challenge and learning different approaches... but not when doing so impedes my progress or creates unnecessary re-coding. There are some really great things about the iPhone SDK framework, but all that greatness is fully supported with MonoTouch and cuts out all the manual memory management, reduces the amount of code required to perform the same tasks, allows me to reuse my assemblies, and keeps my options open to be able to move to other devices and platforms.

Solution 5

I switched. Monotouch let's me write apps at least 3-4 times as fast (4 apps per month compared to my old 1 per month in Obj C)

Lots less typing.

Just my experience.

View more solutions

Comments

[sivabudh]

I think a lot of comments about MonoTouch not being able to run on iOS is not valid anymore since Apple relaxed its dev tools restriction. See: apple.com/pr/library/2010/09/09statement.html

[Iain Collins]

The market share for Mac OS X is very small and so the iPhone is for many the only compelling reason to even consider bothering with X-Code and ObjC. Both were great 15+ years ago back when it was Project Builder and did cross platform complication and packaging but frankly - as someone who uses a range of platforms - with arguably better tools and languages out there now it's hardly surprisingly developers want to leverage a common codebase and use alternative development tools. It doesn't imply their creations will be below par.

[Iain Collins]

s/complication/compilation/ - Freudian slip...

[philsquared]

With Objective-C's Key-Value Bindings and Core Data you get something very similar to Linq-to-SQL. Not the same. Maybe not quite as powerful - but covering a lot of the same ground. Note that Core-Data is not currently supported by MonoTouch

[Rory Blyth]

I don't know, dude... I think Objective-C and CocoaTouch are a crutch. If you're not writing assembly, I'm going to feel like you just didn't care that much, and I'm not going to download your app (because the first thing users do, of course, is check what tools were used to built the flatulence-simulation app they're downloading).

[jamesaharvey]

Wow, Rory, thanks for taking the time to answer my question in such detail. From what I can tell you're the only one who has used both options, which is who I was looking for an answer from. I'll definitely give both a try a go from there. BTW, I heard you on the most recent SO podcast, right? Good stuff. Thanks again!

[Rory Blyth]

Thanks for the comments :) I've gotten frustrated with some of the knee-jerk hating I've seen. Over and over the question is responded to with "Ur a idiot lurn to rite the opurating system first looser!!??" Which is unhelpful and insulting. MonoTouch has its rough spots, but those guys have a track record of genius. MT has advanced quickly and is more beautiful every day. I keep saying: give 'em a couple months. They're being prudent about features, but I think we're going to see big stuff. I love Apple's stack, but I have another playground now - that's a good thing and I'm giddy :)

[Rory Blyth]

First off, C# is not a "domain specific language" - far from it. It's a commodity skill. That's part of the value of MonoTouch. It could be argued (unfairly and inaccurately) that ObjC is a DSL in that most devs (outside finance and university labs and basements) will only ever use it for OS X or iPhone development. But it isn't. Like C#, it's a versatile language that basically exists to let you focus on frameworks rather than the language itself (I think we agree there). But keep in mind that your ObjC code will break with Apple updates. That's not an MT specific issue.

[Rory Blyth]

MT could even save you in some cases because there's this layer of abstraction. Apple modifies an API? Well, your ObjC app and your (let's pretend it exists) equivalent MT app will break. The MT guys could release a stopgap solution to modify how the MonoTouch API handles the call behind the scenes. Your MT code wouldn't have to change - you could just rebuild against the stopgap MT release. Yes: this is a dirty fix that could easily lead to problems, but properly deprecating the stopgap MT API would give devs time to handle the change seamlessly and buy time for a real fix.

[Rory Blyth]

Plus, new as MT is, it just got a lot easier to create your own bindings if necessary (MT 1.2). You're not completely dependent on the MT peeps to do all that work (though they are doing that work), and never were. They have dead-simple ways of creating bindings. They expose enough of the ObjC runtime with the MT frameworks that you're not locked into their way of doing things. I've reimplemented bindings just to see if I like my way better. You can ignore the MT frameworks and send and receive messages "manually" if you want, and it takes little code. They're smart people. Trust them :)

[NSResponder]

They certainly should, and they should also reject Flash apps, but their App Store terms don't preclude using them.

[bpapa]

Which as we all know doesn't really mean much of anything. :)

[bpapa]

Is Linq to SQL even relevant for an iPhone app? It works with SQLite?

[Rory Blyth]

@NSResponder - Have you used MonoTouch? It's a v1.x release, practically brand new, and is already amazing. Try it before commenting on it. There are big changes (its Interface Builder integration is far better than Xcode's), and there are little changes (compare the ObjC/Cocoa way of getting the user's documents folder compared to MT's, for example). I still use Apple's stack for some things, but MT is beautiful and full of potential. Seriously - just try it. Or look at how the Cocoa APIs have been bound - you don't have to use it - just don't trash the work without learning about it.

[Rory Blyth]

@bpapa - that's a totally valid concern, but: 1) There's no reason to reject the apps (users don't care what their apps are written with - they care about the apps themselves), and 2) MonoTouch has a lot of potential for enterprise development, and as long as you have an enterprise dev account, Apple can't stop you from distributing your app. Also, Apple accepts games built with Unity. Ultimately, MT follows the rules. Apple's process seems random at times, but... MT follows the rules :|

[bpapa]

Of course there are valid reasons to reject the apps. In the past week we've seen 2 3rd party frameworks get busted for using private APIs. One was Unity, the other was the engine the FB app guy built. Also Apple may just want devs to use Obj-C for their own reasons. If you want to do enterprise apps it's a pain in the ass w/o going through apple. It's really a big question mark as to how Apple feels about Mono Touch and how they will react to it. Why bother playing with that kind of fire, because you hate the format of a method call in objective-c?

[Bryan]

And you want your users to share data over a network. What are you doing with SQL lite?

[MordechayS]

"MonoTouch is based on a hybrid .NET 2.0 and Silverlight 2 API profile" Is LINQ to objects supported?

[Bryan]

"because the first thing users do, of course, is check what tools were used to built the ... app" You are in dreamland. 99.9% of iphone users are NOT CODERS and they could care less what tools were used. Also, Monodevelop can output to xCode for building and signing anyway.

[Rory Blyth]

You've, probably unintentionally, misrepresented MT. It's not at all - not remotely - analagous to using GTK to write Win apps. MT's bindings are very faithful to CocoaTouch. They've actually improved on some of the CT API conventions. But you're not writing your apps using, say, a Windows Forms based abstraction over CT. MT with MonoDevelop has better integration with IB than Xcode (if you want it), and you can often get the same things done in half the code or less. Binary size is being improved, and the tools (binding generator, etc.) are better all the time. A MT app is a native app.

[Rory Blyth]

To give examples rather than expect you to take my (obviously) MT-fanboy opinion on its own, I can do things like (and this is just a teeny subset of advantages): Create a property with one line; grab a reference to the Document folder without ridiculous array spelunking (an app has one docs folder, always in the same place - why all the extra work to "find" it?); use the .Net framework where Cocoa stinks (NSDate, anyone?); use commodity skills for enterprise apps; use proper, modern XML bits (I love it when Cocoa silently chokes on characters and just stops - no crash - just stops).

[Rory Blyth]

Not saying I'd use it for everything. I like ObjC and still use it. And, if performance is an issue, I have more granular control over what's going on. But... there are times when MT will make more sense, and I think it's going to make the iPhone a viable option for enterprise development. Throw a rock in the air and you'll hit a .Net dev. Most companies don't have in-house ObjC devs. And for enterprise work, they shouldn't have to. MT is much easier for working with web services and DBs. You really can write many kinds of apps with MT with half the code it'd take in ObjC.

[Rory Blyth]

Finally (I could go on, but I think I'm making mt point), changes that "break" MonoTouch are probably just as likely to break ObjC apps. Once your app is in the store, it's a native iPhone app (as it must be). The calls are ultimately no different - same runtime as apps built with Apple's stack. If your MT app breaks due to a change to the runtime environment, so will apps built with ObjC. And the MT team has been on top of this stuff, releasing updates and bug-fixes quickly. MT's bindings map closely enough to CT's that the likelihood of any real trouble is low. Aight - I'll shut up now :)

[Rory Blyth]

@Bryan - I was being sarcastic - we're on the same side :) And, though you can output to Xcode and build there, it doesn't really make a difference since, as you and I both know, MT apps are native iPhone apps. So... yeah. It can be hard for sarcasm to get through online, but we're very much in accord.

[NSResponder]

"as you and I both know, MT apps are native iPhone apps" This is not true, and you know it.

[Rory Blyth]

@NSResponder - How are MT apps not native?

[Rory Blyth]

@bpapa - Don't know how I missed this comment for so long, but: 1) Tons of ObjC apps get "busted" for using undocumented ("private") APIs - FB, as you noted, being one of them, yet FB is still alive and available for download, 2) Unity's problem was rapidly addressed, and Unity is back out there. -- As far as Apple wanting you to use their own stuff, I wouldn't disagree, but want and require are vastly different. As for enterprise apps: you can deploy MT enterprise apps. They're just native binaries. I don't see the problem, nor do I understand why you're so anti-MT.

[bpapa]

I'm not sure how you missed it either.

[Rory Blyth]

@bpapa - Which doesn't explain why you're so anti-MT. It's puzzling to me that there are people (like, well, you) who spend this kind of time slamming a product they aren't interested in and don't have to use. There's nobody telling you to stop using Apple's tools. I still use Apple's tools. I enjoy ObjC, and CocoaTouch is pretty good considering its ancient underpinnings. Thing is, while I can say I enjoy ObjC (from experience and work on some pretty big apps), I'm not sure you can talk about MT from personal experience, which makes your comments all the more confusing (and unhelpful).

[Rory Blyth]

I should add that it's not that I "hate" the syntax of ObjC, but that I much prefer C#. I also prefer the .Net framework's Ways to Cocoa's. String manipulation, processing XML, anything involving dates, etc. - I'll use the MT CocoaTouch bindings for UI work, but for most other tasks, the subset of the .Net framework that ships with MT makes life far easier. I could go on and on (such as my preference for finding certain bugs at compile time). I'm critical of Apple's stack, but I don't dislike it. It's possible to like MT and ObjC/etc.

[Stephan Eggermont]

What exactly are you missing in date & string manipulation in Cocoa?

[Rory Blyth]

@Stephan - It might not be right to say what's "missing" - I can get the job done with Cocoa. It's more about the APIs. It's just far easier to work with strings, dates, XML, etc., with .Net. Dunno if you're familiar with the .Net way of doing these things, as well as the extent of MonoTouch's support for them - if you haven't looked into it, you ought to - just to check it out. I don't mean to say that there are things you can't do with Cocoa, but there are many things that are far more easily done with .Net. Parsing is easier across the board - date math is easier across the board - etc.

[Andrew Rollings]

@NSResponder. MT apps are native. Period. Objective-C is (in my opinion) a backwater. Apple seem to be very advanced on the UI and very backward on the development tools.

[Andrew Rollings]

Having said that, Objective C is okay... But it's nothing compared to C#. (Just my opinion, of course).

[NSResponder]

Andrew, you know not whereof you speak. Objective-C is no backwater; it's the backbone of the native development environment for the Mac, the iPhone, and the iPad.

[Andrew Rollings]

No, it's definitely a backwater. What percentage of machines in use are Macs again? You may not believe this, but I am fairly unbiased. I don't care what I program in as long as the tools and documentation are good, and the language is nice to program in. For Objective C, documentation is good, language not so good, tools so-so. Telling me that "I don't know of what I speak" is a bit silly when you don't actually know me from Adam. (cont.)

[Andrew Rollings]

I've obviously not done as much Mac programming as you (as I didn't work for Apple), but I've done enough to be able to make a reasonably objective comparison between Objective C and (for example) C#. The result? Objective C feels old fashioned and clunky in comparison. It's harder and more long-winded to do fairly simple things, due to it's C heritage.

[NSResponder]

Now that we've exchanged the formalities, Andrew, would you care to explain how you'd implement undo functionality in C#? Looks to me like you have to do far more work than we do in Objective-C.

[Andrew Rollings]

So you pick out one simple example of something Apple has built into the framework, and claim superiority, while conveniently ignoring the parts of the framework that are far clunkier than the C# equivalent? Isn't that something of a strawman argument?

[NSResponder]

Undo IS simple in Objective-C. It's NOT simple in C#, or Java, or C++. In Objective-C, we send a message. In the others, you call a method. The difference is fundamental.

[Ian Vink]

I switched to MonoTouch and have published 47 apps so far on 4.0 as well. I do it full time. Works great, fast. I used to write in Objective C but find C# with Linq faster with a lot less code to write.

[Andrew Rollings]

Apparently they're good enough now. Apple has sensibly relaxed restrictions on development tools - and presumably upped their admission restrictions to compensate (And not before time!) voices.washingtonpost.com/posttech/2010/09/…

[Dinah]

If this is the only iPhone app you will ever develop, the $99/yr isn't worth it either.

[Monoman]

Also there is the issue of your own code reuse in the iPhone/iPad with MT. We have some crypto code, and business logic code, running on our server and desktop counterparts, that we could just recompile with MT and use in our iOS client app. That may be important for some projects.

[Monoman]

Apple has changed minds and now it accepts apps in any language/framework, and set out a more 'objective' list of criteria for accepting apps on the store.

[jl.]

I find the argument that by using MonoTouch you get locked into a vendor that Apple might discontinue to allow/support very strong. You could end up investing in a platform that is at the mercy of a Apple which has their own development platform anyway...

[basarat]

I think slf is not aware of the fact that Monotouch is just C# (with GC) that binds directly to the ObjC libraries + optional .NET libraries. So you still use the API provided by apple. But with a neater syntax and garbage collection.

[Jim G.]

-1: What do you mean by "more bugs"? Is there a glaring impedance mismatch between Mono and Objective-C?

[Amc_rtty]

Also worth considering is the fact that, although the license costs $400, there is also a maintenance subscription that you must renew (for obvious reasons) every year - $250. It's probably a fair price, but still worth taking into consideration.

[netshark1000]

"4 apps per month" - When quantity is more important like quality. MT is like McDonalds. But you get better food at XCode-Restaurant.

[Ian Vink]

The results though speak differently, Rdio and iCircuit are MT apps demoed by Steve Jobs. C# and MT gets rid of the plumbing work that obj-C forces you to do.

[oligofren]

Maybe update this post now that MonoTouch goes under a new name. And stuff has likely changed in four years ... xamarin.com/monotouch

[trampster]

You left out cross platform concerns, if you have existing .net code or also want to target android and windows phone then xamarin/monotouch is your best option.

[harsimranb]

Yes! Also, some of the new C# 5.0 features make coding all that more fun compared to objective-c.

[danfordham]

A quick update on my answer above. Since moving to a faster Mac I've found the build times to be a lot quicker, it's still not instant like XCode but it's fine.

[user430788]

You can also do cross development IOS/Android/PC/Mac/Linux with Mono which you can't with Objective-C

[Ian Vink]

You can use the same C# develppment tools to build Mac apps. In fact you can code share between iPhone C# and Mac C# apps. MonoTouch is now called Xamarin

[Phil Ryan]

What Rory wrote 6 years ago is still pretty much relevant today in 2015! Xamarin has done a fantastic job in that time with MonoTouch (and MonoAndroid). However, there is just more available sample code (and Apple help) using Objective-C (and now Swift) on the Apple side. And the MT-based apps are still way bigger than equivalent ObjC ones. That said, I'm exclusively a Xamarin dev. :-)