After spending three weeks learning Objective-C and Cocoa programming for my work, I\'ve been tasked with researching alternatives to it for iPhone development.
I kn
I would suggest looking at using a hybrid solution.
Because of Objective-c's flexibility, you can implement your interface in Objective-c and your data model in almost anything else. You can practically draw the interface using Interface Builder so your actual coding in Objective-c is minimal. The real challenging parts of most serious applications are in the data model and that is where you are most likely to have legacy code or code from other projects.
As noted here by others, there are many libraries that allow you to glue almost any major language/API into Objective-c.
I'd be pretty skeptical of non-ObjC languages on the iPhone. Not necessarily because there's some huge technical hurdle to be surmounted (you can compile pretty much whatever you want down to the iPhone, and even get it to run with some tweaking), but for two other important reasons:
You'll also have a lot more trouble with things like code signing/certificates, not to mention debugging (it struck me as strange that MonoTouch is advertising debugging as a feature, rather than something that's kind of taken for granted within the language).
All in all, I'd stick with ObjC if you can. It's generally just easier for all concerned.
Update: September 2010 New iOS terms of use embraces third party development, advertising platforms
Here's my answer as someone who bought MonoTouch and am using it as the basis for all of my iPhone apps.
There are no shortcuts. You need to know Objective-C and CocoaTouch before you even consider something else. You can't grab MonoTouch and start coding for the phone without any knowledge of the native stuff, it just isn't going to happen.
MonoTouch is easy enough to extend/alter as needed, if you already know CocoaTouch and ObjC well enough. So the idea that the native frameworks could change leaving you in the dust isn't that relevant.
I have found in my experience that MonoTouch apps are slower than their native counterparts, but not enough to matter. If it does matter, you can always write that part of the app with native code, and it's possible ObjC wouldn't be fast enough anyway and you'd want to drop to pure C even in a native app.
MonoTouch has netted me some serious productivity gains, from being able to use a far less terse and chatty language to being able to use libraries like Rhino Mocks and NUnit out of the box.
MonoDevelop is a great IDE in theory. It's also far superior to xcode, in theory. It's lightweight, simple, very easy to use, excellent intellisense and macros, and makes managing an iPhone project far easier than xcode. But ... it's really buggy. That is it's true downfall right now.
You will be losing out in several ways by not choosing Objective-C, seeing as how it is the only Apple supported environment.
All of Apple's docs, sample code, tool chain etc. assume you're using Objective-C. You won't really be able to use your code level support incidents. Any new framework will have to be wrapped for your environment, which also introduces a new source for bugs.
To me, using something other than Objective-C for the iPhone would be opening up a big bag of hurt.
Unity for iPhone is a good platform for non-ObjectiveC development.
http://unity3d.com/unity/features/iphone-publishing
It is for more than just games, and if you need .NET or other script language support this may be a good way to go.
IMHO: MonoTouch is more work than a good IB + ObjectiveC stack, even with some of the learning overhead of ObjectiveC.
MonoTouch looks good, but it's excruciatingly slow. I've been playing around with XCode on my last generation MacBook for a while (ca 2007) and it's quick and responsive. I downloaded MonoTouch last week as I'd like to convert an existing large Mono codebase to run on the iPhone and whilst it installs and runs fine, using it is painful in the extreme as everything in the IDE is sludgy and unresponsive.
YMMV if you've newer and more powerful kit, but it doesn't bode well.