Is MonoTouch a viable platform for iPhone development? [closed]

Question

MonoTouch seems like a great platform for iPhone development, but I'm concerned about deploying it to the Apple Store. Are there any examples of applications built with it that are currently available on iTunes?

We're starting a new project for the iPhone, and keeping the entire stack in C# would be great, but we don't want to incur the risk of being turned down from the Apple store because of MonoTouch.

I've read about several games that currently use mono (not MonoTouch) for 3D graphics, but couldn't find anything about MonoTouch.

Answer 1

Tapping this out on my phone, so going to be a little terse - apologies for that. 

Anyway:

 - As said in a previous answer, there have been MonoTouch apps released to the App Store. Whether it's two or a bajillion doesn't matter so much. The difference between one and zero is infinite - the answer is unequivocally: Yes, Apple will approve MonoTouch apps.

 - MonoTouch plays by Apple's rules. It spits out native bits. There's no interpretation of code going on, nor is there any JITting. Your MonoTouch app is a bundle like any other, and it contains a native binary like any other.

 - MonoTouch apps are larger than they would be if they were written with Apple's stack. This is because your MonoTouch app relies on a subset of the Mono/.Net framework. In that respect, though, once you get down to what ships, there's nothing especially different about a MonoTouch app. I worked at a company where we built our apps (developed with Apple's stack) against our custom framework. It increased the size of our apps, but it also cut way down on production time (and that's always the trade-off, right?). Plus, the size of the app bundle just after compilation can be deceptive. Because bundles are zipped for the App Store, the size decreases dramatically - you can easily write a MonoTouch app that falls well within the acceptable size limit for apps delivered OTA (I bring this up because it's a question MT n0obs (rightly) tend to ask). So, Apple doesn't have any real reason to reject based on size.

 - Whether it's MonoTouch or a custom in-house framework like the one I used to work on/with, the MonoTouch stuff, when shipped with your app, is just another framework that could've been written in Objective-C.

 - If you're concerned about configuring your app for distribution using the entire MonoTouch stack and how that might affect your chances of approval, you can tell MonoDevelop (or the mtouch utility from the command-line) to output an Xcode project. You'll see that your code has been transformed - you'll be looking at native assembly (not some flavor of an IL). You can build and run your MonoTouch produced app from right within Xcode, by which time MonoTouch is basically out of the picture (except as a framework you're building against (like MapKit, for example)).

For some reason, all of this bothers a very small, but vocal, subset of iPhone devs who, for whatever reason, can't stand the idea of people they don't know using a different tool to build apps. But their hateage doesn't change the simple fact that Apple has accepted MonoTouch apps (and Unity apps long before that).

The biggest reason you're going to see for MT apps being rejected is that MT devs, in my experience (I've been talking to quite a few - after giving some talks, posting to forums, mailing lists, here...), is they they haven't yet learned how to develop an iPhone app. That's something iPhone devs must do regarldess of how they write their apps. MonoTouch isn't the obstacle - it's knowing, for example, that Apple wants your app to look a certain way and to work in a certain way - it should look and feel and behave like other (good) iPhone apps, and shouldn't be among the examples of attempts to write desktop apps for a phone (which is where your average dev makes his first mistake when transitioning to mobile development).

Ultimately, your tool of choice isn't going to matter as long as it creates bits that play by Apple's rules (like MonoTouch). The real obstacle is learning the iPhone Way of app design.

.Net application devs, whether on Windows, Windows Mobile, or wherever Mono (not MonoTouch) runs, are accustomed to developing apps according to their own tastes. That doesn't fly in the iPhone world.

You can safely go with MonoTouch. As has been shown, Apple will approve MT apps.

The thing you really need to do (again, regardless of which dev stack you choose) is read Apple's docs on iPhone app design and their guidelines. There's a huge crowd of devs out their attributing their app rejections to Apple being evil (or whatever - uninformed excuses, basically), when the truth is that their apps are garbage and it's clear the devs didn't play by the rules (or even bother to read the rules).

In the end, in many cases, you'll write far less code when using MonoTouch, and the cost for that is a larger app bundle (which, as I said, will come out very reasonably sized after it's been zipped for distribution).

That's not much of an issue. With 3g, users don't sweat downloading 2-3MB sized apps. If it's small enough to send OTA, everything's fine. And in cases where your app goes over the limit, it's likely embedded resources (media - images, videos, etc. - that's how bundles typically swell to wifi-only sizes), and that's something Objective-C devs have to deal with, too, so that's not a MonoTouch problem.

So, ignore the haters (who haven't even tried MonoTouch or bothered to learn how it works), and rest assured that, as long as your app conforms to Apple's guidelines, there's no reason for them to reject it. It doesn't mean your app is guaranteed acceptance as long as you design it correctly (plenty of apps get rejected for no apparent reason), but you can consider yourself, more or less, to be on equal footing with devs using Apple's tools. 

Hope this helps :)