How to decide between MonoTouch and Objective-C?

I would invest the time in Objective-C mainly because of all the help you can get from sites like this. One of the strength's of Objective-C is that you can use C and C++ code, and there is a lot of projects out there that are **well tested**.

Another thing is that you're code (language of choice) will be supported by apple. What it iOS 5.x for instance removes the support for a third party solution like MonoTouch? What will you tell your customers then?

Maybe its better to use a platform independent solution like HTML5 if you're not entire ready to move to Objective-C?

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:

[To see links please register here]

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

I've been using MonoTouch for a few months now, I ported my half finished app from ObjectiveC so I could support Android at some point in the future.

Here's my experience:

Bad bits:

- Xamarin Studio. Indie developers such as myself are forced into using Xamarin Studio. It is getting better every week, the developers are very active on the forums identifying and fixing bugs, but it's still very slow, frequently hangs, has a lot of bugs and debugging is pretty slow also.

- Build times. Building my *large* (linked) app to debug on a device can take a few minutes, this is compared to XCode which deploys almost immediately. Building for the simulator (non-linked) is a bit quicker.

- MonoTouch issues. I've experienced memory leak issues caused by the event handling, and have had to put in some pretty ugly workarounds to prevent the leaks, such as attaching and detaching events when entering and leaving views. The Xamarin developers are actively looking into issues like this.

- 3rd party libraries. I've spent quite a time converting/binding ObjectiveC libraries to use in my app, although this is getting better with automated software such as Objective Sharpie.

- Larger binaries. This doesn't really bother me but thought I'd mention it. IMO a couple of extra Mb is nothing these days.


Good bits:

- Multi-platform. My friend is happily creating an Android version of my app from my core codebase, we're developing in parallel and are committing to a remote Git repository on Dropbox, it's going well.

- .Net. Working in C# .Net is much nicer than Objective C IMO.

- MonoTouch. Pretty much everything in iOS is mirrored in .Net and it's fairly straight forward to get things working.

- Xamarin. You can see that these guys are really working to improve everything, making development smoother and easier.


I definitely recommend Xamarin for cross platform development, especially if you have the money to use the Business or Enterprise editions that work with Visual Studio.

If you're solely creating an iPhone app that will never be needed on another platform, and you're an Indie developer, I'd stick with XCode and Objective C for now.

As someone with experience with both C# as well as Objective-C, I'd say for most people Xamarin will be well worth the money.

C# is a really good designed language and the C# API's are good designed as well. Of course the Cocoa Touch API's (including UIKit) have great design as well, yet the language could be improved in several ways. When writing in C# you will likely be more productive compared to writing the same code in Objective-C. This is due to several reasons, but some reasons would be:

- C# has [type inference][0]. Type inference makes writing code quicker, since you don't have to "know" the type on the left-hand side of an assignment. It also makes refactoring easier and more saver.

- C# has [generics][1], which will reduce errors compared to equivalent Objective-C code (though there are some work-arounds in Objective-C, in most situations developers will avoid them).
- Recently Xamarin added support for [Async / Await][2], which makes writing asynchronous code very easy.

- [You'll be able to reuse part of the code base on iOS, Android and Windows Phone.][3]

- MonoTouch largely implements the CocoaTouch API's in a very straightforward way. E.g.: if you've got experience with CocoaTouch, you'll know where to find classes for controls in MonoTouch (MonoTouch.UIKit contains classes for UIButton, UIView, UINavigationController, etc..., likewise MonoTouch.Foundation got classes for NSString, NSData, etc...).

- Xamarin will give users a native experience, unlike solutions like PhoneGap or Titanium.

Now Objective-C has some advantages over C#, but in most situations writing apps in C# will generally result in less develop time and cleaner code and less work to port the same app to other platforms. One notable exception might be high-performance games that rely on OpenGL.

[0]:

[To see links please register here]

[1]:

[To see links please register here]

[2]:

[To see links please register here]

[3]:

[To see links please register here]

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.

EDIT: I never meant to imply anything negative about .NET I happen to be a big fan of it. My point is that adding more layers of complexity just because you aren't yet comfortable with the quirky objc bracket notation doesn't really make much sense to me.

2019 update: It's 7 years later. I still feel the same way if not more so. Sure, 'domain specific language' may have been the wrong term to use, but I still believe it's much better to write directly for the platform you are working with and avoid compatibility layers and abstractions as much as possible. If you are worried about code reuse and re-work, generally speaking any functionality your cross platform app needs to perform can probably be accomplished with modern web technologies.