How good is Mono Touch in comparison to the IPhone SDK?

+2 A:

I would say no, because the biggest thing to learn about the iPhone SDK is not Objective-C, but the APIs instead. Even if you used Mono Touch, you would have to learn the API for the iPhone.

It never hurts to learn a new programming language.

(However, don't listen to me, because I am using Lua to write my iPhone applications...)

Tuomas Pelkonen 2010-03-26 14:01:32

One thing that I believe we got right with MonoTouch is that all of the Objective-C APIs became strongly typed. This means that the IDE can provide intellisense for all kinds of objects and parameters without having to look up the docs (What is inside this NSArray? What do I have to pass in this NSObject?)

miguel.de.icaza 2010-03-27 16:28:15

True, you need to learn the APIs, but with MonoTouch you also have the whole .NET framework to build on, which makes development considerably easier, especially if you're already familiar with it.

NeilDurant 2010-07-23 18:33:15

+2 A:

Great podcast on this week's dotnetrocks about this.

One HUGE factor that would sway me is the fact that they are currently working on Monodroid and I guess that WinMo 7 will probably be supported through some moonlight magic.

Imagine targetting the top 3 mobile platforms with one language? Sweet....

Alex DeLarge 2010-03-26 14:04:45

Very useful podcast indeed, especially since I am going to build almost exactly what those guys are discussing - A thin mobile device client around a web service. Thanks a lot for the link!

Adrian Grigore 2010-03-26 17:33:02

+3 A:

I've been using MonoTouch for 5 months, and really like it.

Take a look at my answer to a similar question here: http://stackoverflow.com/questions/2509759/monotouch-has-anyone-used-this/2515734#2515734

Eduardo Scoz 2010-03-26 14:30:21

+3 A:

I am an iPhone developer, I have tried mono touch, but for me I would say NO, it's not worth the extra 400.

First of all several free frameworks exist that allow you to target multiple platforms at once using different (usually high level) languages, such as PhoneGap, there's even a Flex framework somewhere, without counting Unity3D which actually uses C# and even allows you to deploy on iPhone and Nintendo Wii.

Some of the Cons of using this third party frameworks are:

1- Extra software layer, which obviously increases the possibility of failure. Last year it happened with Unity3D. Somehow the applications developed with it started being rejected by Apple (official Unity announcement here) , Unity guys responded fast, and I think they fixed the issue with Apple in 3 days. But what if 3 days is too much for you, or even worse, what if the external framework that you are using to develop doesn't have that quality of support and the 3 days end up being weeks?... what if your applications got broken with an OS update ?

2- You totally loose Xcode debugging chances (loose the symbols), and you are kinda reduced to printf debug. Of course you can debug in the Mono IDE, but still, Xcode is a powerful beast and all the SDK Betas are delivered to the developers to be used with particular Xcode versions.

3- Binary size tends to be bigger in comparison to native Objective-C applications. ( 6 to 7Mb larger in average ), and remember that if your application is above 20 Mb it can't be downloaded from an iPhone using 3G or Edge, ( which is the most popular way to install apps ). So if that matters to you, it's another issue.

In conclusion:

If you want to use MonoTouch because you don't know Objective-C, go for it, but still I would really recommend you to take a bit of time to learn the Objective-C language and the official Apple API's. Here's a great point of view about this.

Mr.Gando 2010-03-26 14:40:14

Good explanation, although I disagree with some of it. Yeah, its another layer, but there are several reasons why it actually decreases the possibility of failure, not increase. If you're developing a game, you'll probably be using libraries anyway, and those could be rejected, right? 2-x-code debugging is not available because you don't use x-code. Kinda obvious. Other tools replace that. 3-Limit is 20, not 10Mb, but yeah, its a valid point.

Eduardo Scoz 2010-03-26 17:28:00

@Eduardo: 1-In the case of developing a game, or a lot of other utilities, you use libraries. But libraries in general is not what I'm warning Alex about. The problem comes when for example you get an ARM binary that links to the Cocoa-Touch API and in your back could call private API's for example, you don't control that part, the Company that develops your library does. 2- It's not obvious, if you build a library from scratch in an Xcode project, you can do it in a smart way and still retain ALL the symbols for debug.3- Yeah, don't know why I said 10 Mb, edited my answer accordingly.

Mr.Gando 2010-03-26 17:49:24

1- Yeah, but the libraries you use could also be using those private APIs without you knowing. There's no reason to single out one vendor for a problem that can happen to anybody. 2- MonoTouch uses a different platform for development, so it makes no sense to generate x-code symbols. Debugging on MT is much easier than in x-code, btw.. You can do it even over wireless, if you want. :)

Eduardo Scoz 2010-03-26 21:28:03

Game libraries are generally much lower level, and do not make use of the API's at all. Wrapper GUI libraries that make many calls into the system are far more likely to be actually trigger some kind of API issue. Also "other tools replace that" (debugging} totally overlooks a very power suite of instrumentation tools available to XCode developers.

Kendall Helmstetter Gelner 2010-03-27 00:33:17

While it can be more likely, it simply doesn't happen anymore. Because it happened one time, to one vendor, at a time when Apple changed the rules (it started automatically checking for non-api calls) doesn't mean that its likely to happen again. That's not really a point, honestly. And you can use Instruments and Shark with MonoTouch; you can't use its debugger, because its a different platform.

Eduardo Scoz 2010-03-27 15:44:20

+5 A:

I just posted about this at www.zouak.com, but in short for me it was a case of divide and conquer. I have years of .NET experience and honestly found learning Objective-C frustrating. Having a new language plus a new set of tools reduced my productivity significantly, also having to deal with manual memory management after years of not (prior to 2001 when I started with .NET I was a Java guy since its inception, so it's been a while) was an extra layer of "been there, don't want to go back."

I've found the MonoTouch toolkit to be very worthwhile, and while I understand some of the objections and concerns, I'm someone for whom leveraging what I know (C#) allowed me to focus on what I didn't know (Interface Builder, the API, etc.). At this point now that I've built up a significant amount of familiarity with the Apple tools I'm nearing a point where if I wanted I could look at taking on Objective-C as a new language, given that I am a lot more comfortable, but for me learning a new language isn't as rewarding an accomplishment for me at this point in my career compared with learning a platform and getting quality applications out the door is. For other folks I know they enjoy delivering "as Apple intended", and I fully respect that. Also, if Apple had a Java toolkit, I would be all over that. But the conceptual distance between C# and Objective-C is more than I'm willing to invest at this point.

That's my 2 cents,

Driss.

Driss Zouak 2010-03-26 22:22:04

A:

I've read a lot about monotouch and I mostly concerned about application speed and performance. Any stats about this ?

Thank You !

arachdi 2010-03-31 17:13:47

ansaurus

tags:

views:

answers:

How good is Mono Touch in comparison to the IPhone SDK?

related questions