I'm working with a small startup with the goal of creating an iPhone application. The programmers on our team all know both C and Java, but we've got no ObjC/C#/iPhone experience -- we'll be learning something no matter what. All the questions I've seen on this subject have been from the perspective of a C# programmer getting into iOS, so I don't have any information on the relative merits of learning one or the other.

So, what I want to know is the relative merits of C# and Objective-C for new programmers, with respect to these things:

Performance

Ease of use

Ease of learning

Reliability (i.e., will a new iOS version break a MonoTouch app?)

Also, would writing in MonoTouch have any benefits for cross-platform development with Android?

4 Answers
4

If the goal of your startup is to create an iPhone app, then obviously you should learn the language iOS applications are built with, Objective-C. Your team already has experience with C, so it should be very easy to get started. The Big Nerd Ranch books will get you up and running in a week or two (I'm not associated with Big Nerd Ranch, I just think they're awesome).

I don't understand why you bring up MonoTouch, considering your team doesn't have C#/.NET experience. There are tons of other frameworks like MonoTouch, including Titanium SDK (JavaScript), RubyMotion (Ruby), and so forth. All of these are great, but as I see it are primarily for those with experience with their respective languages. They allow you to write iOS applications using a language you're more familiar with, but have the following drawbacks:

Performance can be just as good, but usually a little (sometimes a lot) worse than an application written in Objective-C.

Resources for learning are not as plentiful as those for iOS SDK/Objective-C. There are tons of people who want to make iOS apps, and of those people some use these frameworks, and they are diluted amongst them. Only a small fraction of the resources available for iOS development will be devoted to any given framework.

These frameworks are based on the iOS SDK/Objective-C, so naturally development is always a step behind. If Apple rolls out radically new APIs in the next version of the iOS SDK, you'll have to wait for these frameworks to adapt (applications written in Objective-C might break, too, but it'll be easier to deal with based on point #2).

Most of these frameworks require a familiarity with the iOS SDK. You will still need to know that an application calls the - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions method on launch, but in addition you will need to remember how to translate that into the appropriate method for MonoTouch: public override bool FinishedLaunching (UIApplication app, NSDictionary options). The iOS SDK is massive, and most iOS developers rely on Apple's documentation for insight. So you will be looking at the API docs, written for Objective-C, and translating methods into the framework of your choice.

The Objective-C ecosystem is constantly evolving, with cool new projects like CocoaPods, bwoken, etc. These are primarily developed with Objective-C and Xcode in mind. Configuring them to work with your framework of choice will almost invariably cause you extra time and work.

The above points have generally kept me from delving too much into any of these other frameworks. They're all very cool, but their primary merit in adoption seems to be facilitating development for people with deep skill sets outside of Objective-C, or allowing cross-platform development for small teams lacking the resources to invest in Android and iOS (and Windows Phone) programmers. Hopefully the benefits outweigh the above costs for adopters.

Also, would writing in MonoTouch have any benefits for cross-platform development with Android?

I suppose it would. Indeed, the MonoTouch homepage touts that as a primary advantage of using the framework. I'm not so sure about view/controller classes, since those seem like they would be tied into UIKit, but the logic encapsulated in your models should be fairly easy to port.

Long story short, I think you and your team should stick with Objective-C for iOS development.

Agreed that generally the best bet is ObjC (and your reasons are excellent). I do have some real hope for RubyMotion given my investigations with MacRuby (which is actually quite good IMO). I have yet to see really good experiences out of the JavaScript answers, particularly Titanium. Using JavaScript means you're subject to all the headaches of UIWebView, and there are many. And Titanium I've personally found to be a royal headache. I would always recommend ObjC over JavaScript for iOS; it's faster to develop in ObjC by far. But I'm withholding judgement on RubyMotion; it might be quite good.
–
Rob NapierMay 13 '12 at 18:40

MacRuby is great (meanwhile I lament the sad state of PyObjC), and RubyMotion does seem very promising. It apparently has ctags support, which should help with autocompletion of API methods, and the ability to see UI updates in realtime could make developing UI components faster than ObjC in some cases. I'm planning on giving it a spin soon. Titanium certainly loses in the performance arena (although sometimes this can be mediated with specific tips/tricks), but JS-to-iOS and JS-to-Android is very, very appealing.
–
modocacheMay 13 '12 at 19:30

Why not list some well known drawbacks as well? 1) you have to manage memory on your own (MonoTouch has GC); 2) a new iOS releasee does break Objective C based apps too (so many apps crashed after upgrading my iPad to iOS 4 and 5); 3) Objective C is still a strange dialect of C/C++ family (no matter how many resources are there, you still need to fight to learn it); 4) if you need to communicate with external web services (except iCloud), you may have to rely on a not-from-Apple library (MonoTouch takes good care of that and many others, as that's an advantage of .NET/Mono).
–
Lex LiMay 15 '12 at 3:03

1) There's ARC now, but that does seems like a pretty powerful feature, so +1 for libraries with a successful implementation of GC. 2) See original answer. 3) OP said he'd be learning something either way. Why take the roundabout route and learn a language other than ObjC? 4) As in REST API's and the like? You don't need external libraries for that, but there are many available to choose from (AFNetworking, RestKit, etc). Sorry if I'm misunderstanding your point, but that hardly seems like a disadvantage.
–
modocacheMay 15 '12 at 8:07

1) ARC kicks GC butt. Sorry, but for ObjC GC is dead. That's a good thing 2) Many people do things wrong. IOS 4 to IOS 5 Apple fixed a lot of holes to prevent that. Don't rely on StackOverflow so much. Sometimes they repeat the same wrong info. 3) ObjC has been around for over two decades. It isn't hard to learn. But like any other language it takes time to get good 4) There are a lot of external libraries. Apple has a lot of source code they provide for free.
–
Feloneous CatDec 12 '12 at 13:48

If you're just building an iPhone app, then by all means choose Objective C. But if you want a mobile app — which may include android, windows phone, windows rt, blackberry, webos, or other options — you might want to take a close look at a few of the alternative platforms, of which MonoTouch is one prominent option.

Objective C is a strict superset of C, so if you understand the performance characteristics of compiled C code on ARM, you can just use that C subset with which you are familiar, except for the iOS UI.

There seem to exist reports that experienced C programmers start getting up to speed with writing iOS apps in Objective C in on the order of 2 weeks. But, of course, learning extensive frameworks and APIs in an ongoing learning process, whatever the language.

That said, take a look at doing this with HTML5. If you stick to accelerated transforms, HTML5 performance for an application front end is surprisingly good. It's also pretty easy to move your HTML5 app to Android.

The simple answer is Objective-C. It's not too hard to learn. If you're solid on C and solid on OOP, you'll be fine.

I'm not a fan of absolute statements without references. You say that "for performance, objective-C all the way." Who knows, you may be right, but pointing to a resource of actual measurements would take your statement out of the arbitrary opinion area that I like to downvote.
–
ctackeMay 15 '12 at 13:30

@ctacke It's based on 1) experience and 2) the intuitive understanding that the thinnest path is typically the quickest. There is some trickery to having things stay quick (e.g. use views with translation and transparency), but Apple has heavily optimized what they see as the target path. It shows. You may want to downvote (and feel free), but I'm not going to provide citations for a plainly obvious answer (echoed by others). The meat of my answer here is that HTML5 should be on his list, but between Mono Touch and Objective-C, I don't see much cause to stray outside of the garden.
–
chaboudMay 15 '12 at 14:14

2

@chaboud - that monotouch should be behind Html5 in terms of performance is laughable. You do need to provide citations if you want to make statements like that. Safari Js is way slower, especially for animation with JQuery. Maybe CSS3 is alot better, but doesnt sound like a great solution.
–
angel of codeJun 5 '12 at 18:01

@angelofcode - I never suggested that monotouch should be behind HTML5 in terms of performance. There were multiple criteria, like ease of use, ease of learning, reliability, and portability. I like monotouch, but HTML5 should be in the running for someone considering a new app, at least if the app is basic.
–
chaboudDec 11 '13 at 2:00