Question

It strikes me as a good idea for Apple to negotiate with Novell and bundle the Mono Touch runtime (only the runtime of course) into every iPhone and iPod Touch. Perhaps even make it a "one time install" that automatically gets downloaded from the App Store the first time one downloads an app build with Mono Touch, making every subsequent Mono Touch app much lighter to download (without the runtime).

Doing so would be similar in a way to adding Bootcamp to OS X: it would make it easier for C# developers to join the party, but that wouldn't mean these developers will all stick to C#... What convinced me to buy a Mac is Bootcamp - I figured I could always install Windows if I didn't like OS X (and I liked the hardware, so no problem there). 6 months later, I'm using OS X full time...

Would there be any technical issues in doing so? I see only advantages for all parties, not one disadvantage to anyone (except maybe for the few unfortunate Apple employees who would have to test the crap out of the Mono Touch runtime before bundling it):

  • Novell wins because Mono Touch becomes much more viable (Mono Touch apps become much lighter all of the sudden)
  • Developers win because now there's one more tool in the tool belt
  • Many C# Developers would be very interested by this
  • Apple wins because that would bring even more attention to the platform, more revenue in developer fees, more potential great apps, etc
  • Users win because less space is used by different Apps having copies of the same runtime accumulating on their devices

Would there be a major technical obstacle in bundling Mono Touch to iPhone OS?

Edit: Changed the title from "Should" to "Will Apple bundle the runtime?", I think the consensus on predicting that means a lot to those considering going with Mono Touch.

Was it helpful?

Solution

No, but no compelling reason for Apple to do so either. The iPhone isn't exactly hurting for apps, there are much bigger problems with the development process than lack of Mono (e.g., overworked app reviewers giving bizarre rejections), and there are other alternative languages that Apple would be more likely to care about first, such as MacRuby and Python. Apple supports both of those languages for writing Cocoa apps on the Mac, so I would expect them to be supported on the iPhone before an out-of-left-field language like C#.

(Note that I'm not exactly answering the question of whether Apple should bundle MonoTouch, which is a bit subjective. I'm just explaining the forces pulling on Apple that would affect whether or not they do so.)

OTHER TIPS

  1. My understanding of the mono runtime on iphone (which may be incorrect) is that it really isn't a runtime in the same way it is on other platforms - all code (including mono) is compiled to static code.
  2. It's a version 1.0 and hasn't proved its worth yet. There are probably going to be lots of versions and having all predownloaded would be a hassle.
  3. It increases the cost to developers from $99 to at least $498 so uptake may be limited.
  4. They make a perfectly good development envrionment and set of libraries available already.
  5. Java and Flash aren't available - why would they focus on something far less established.

I hope it does well, but to make downloads slightly smaller for significantly less than 1% of applications it really isn't worth Apple thinking about.

There's a very good reason for not doing so, because it would fragment developers. Some would learn Objective-C, some would learn Mono and if Apple supported Mono they would have to support both.

If Apple were going to do anything they would add garbage collection support to iPhone Objective-C, which already exists on the desktop - but they consider the device performance constraints tight enough to not have that overhead.

I am a great believer in using the framework that philosophically matches the platform you are on. It's cool that Mono works, and as a game scripting language in something like Unity I think it's a fantastic idea - but if you are doing iPhone application development you should learn Objective-C to understand how the platform really is.

According to the iPhone Developer Program License Agreement for the upcoming iPhone OS 4 SDK, MonoTouch will actually be in violation and will not be permissible:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Since C# is not one of those languages then it will not be allowed.

Bundling a framework with the OS has major implications. Doing so would put the responsibility of keeping Mono Touch secure and up-to-date squarely on Apple's shoulders. I.e., any problems with Mono Touch would reflect much more poorly on Apple than on Novell, and any framework updates would require significant testing to ensure existing Mono Touch apps don't break. I'm sure that's a responsibility Apple doesn't want or need.

More importantly, Apple doesn't appear to be having any trouble attracting developers to the iPhone platform. And it helps bring developers on to the OS X platform, which is huge. I can't imagine Apple wants to change a thing right now.

On top of what Chuck said, Apple would have to verify that everything in MonoTouch works and won't cause crashes that would make Apple look bad. That would mean Apple would have to rigorously test and QA not only MonoTouch now, but each MonoTouch subsequent release.

Even if it's trivial to add MonoTouch support, it's not trivial to do it right.

BootCamp was probably also a gigantic engineering effort to develop and QA for Apple, but it was worth it to lure Windows users (a gigantic market) to Macs.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top