Is MonoTouch worth the cost or should I just learn 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?

Answer 1

If this is the only iPhone app you will ever develop, and you also have zero interest in developing Mac applications, ever, then MonoTouch is probably worth the cost.

If you think you'll ever develop more iPhone apps, or will ever want to do some Mac native development, it's probably worth it to learn Objective-C and the associated frameworks. Plus, if you're the type of programmer that enjoys learning new things, it's a fun new paradigm to study.

Answer 2

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?

---

Answer 3

Personally I think you'll have a better time just learning Objective-C.

In short:

• "Learning Objective-C" is not a daunting as you might think, you may even enjoy it after just the first few weeks
• You are already familiar with the "C style" syntax with lots of *&(){}; everywhere
• Apple has done a very good job of documenting things
• You'll be interacting with the iPhone the way Apple intended, which means you'll get the benefits directly from the source not through some filter.

I have found that the projects like Unity and MonoTouch are supposed to "save you time" but ultimately you'll need to learn their domain specific language anyway and will have to side-step things at times. All that is probably going to take you just as long as it would to learn the language you were trying to avoid learning (in calendar time). In the end you didn't save any time and you are tightly coupled to some product.

Answer 4

To add to what others have already said (well!): my feeling is that you're basically doubling the number of bugs you have to worry about, adding the ones in MonoTouch to the ones already in iPhone OS. Updating for new OS versions will be even more painful than normal. Yuck, all around.

The only compelling case I can see for MonoTouch is organizations that have lots and lots of C# programmers and C# code lying around that they must leverage on iPhone. (The sort of shop that won't even blink at $3500.)

But for anyone starting out from scratch, I really can't see it as worthwhile or wise.

Answer 5

The cost of the MonoTouch library is entirely beside the point. The reason you shouldn't use Mono for your iPhone apps, is that it is a crutch. If you can't be bothered to learn the native tools, then I have no reason to believe that your product is worth downloading.

Edit: 4/14/2010 Applications written with MonoTouch aren't eligible for the iTunes Store. This is as it should be. Apple saw plenty of shallow ports on the Mac, using cross-platform toolkits like Qt, or Adobe's own partial re-implementation of the System 7 toolbox, and the long and short of it is they're just not good enough.

Answer 6

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://monotouch.info

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

Answer 7

I think mono-touch would have become the defacto standard if it was free and open source. As it is, you have to pay for it. To me that means it will always remain a niche product, and niche products are not worth investing time or money in if there is a more popular alternative.

Answer 8

Three words: Linq to SQL

Yes it is well worth the $.

Answer 9

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.

Answer 10

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 :)

Answer 11

Something I'd like to add, even though there's an accepted answer - who is to say that Apple won't just reject apps that have signs of being built with Mono Touch?

Answer 12

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.

Answer 13

MonoTouch is dead (will be prohibited on iPhone)

Answer 14

I m not sure you will be able to use monotouch with 4.0 SDK here is why.

Answer 15

@tom greene's brief comment that "MT is dead" because it is prohibited did not provide any references that tended to prove the point, but another question on SO does:

http://stackoverflow.com/questions/2604033/is-monotouch-now-banned-on-the-iphone

In specific, the point is that if it wasn't developed originally using ObjC etc, it is not allowed. @Rory has made the correct point that there are lots of apps which were written using other APIs and they're still there, which is of course true, but he states further that it there are no requirements that Apple-approved tools be used in orginal development, but @Rory I am sad to chave to contradict you, that the TOS or whatever its called, does prohibit them. Granted that currently Apple isn't casting out apps developed using unapproved means, they could start doing so anytime they wanted. This tends to make me, for example, hesitant to dev using anything other than ObjC etc. And I would prefer MT and C#.

Check out this Wired article on the matter:

http://www.wired.com/gadgetlab/2010/04/iphone-developer-policy/?