Mono's de Icaza: Novell MonoTouch to forge ahead on iPhone OS despite 3.3.1

An amendment to the terms of Apple's iPhone OS Developers' Agreement, called Section 3.3.1, uncovered last week, would expressly prohibit developers from building apps for iPhone, iPod Touch, or iPad that were not created exclusively for that platform, using Apple's tools, and linking to no other APIs except Apple's. That "clarification" threatens the existence of cross-platform support for the iPhone platform, not only from Adobe Flash (whose apps can be devised to run on iPhone), and Oracle Java (same story), but also from development tools whose apps don't have to be jerry-rigged to run on iPhone.

Those include Unity3D, the 3D gaming platform originally for Mac OS that dropped Java in 2008 for Novell's Mono; and MonoTouch, Novell's extension of its .NET Framework-compatible platform for iPhone OS. In a notice on MonoTouch's home page, the development team expressed optimism that Apple would find MonoTouch to be in compliance with the company's new terms.

"If Apple's motives are technical, or are intended to ensure the use of the Apple toolchain, MonoTouch should have little difficulty staying compliant with the terms of the SDK. MonoTouch runs only on Mac OS X, and integrates tightly with XCode and the iPhone SDK," the notice reads. "Applications built with MonoTouch are native applications indistinguishable from native applications, only expose Apple's documented APIs and uses a rigorous test suite to ensure that we conform to the iPhoneOS ABIs and APIs."

But that optimism is based on hope that Apple will write a note back to the Mono team, which it evidently has not done yet.

Even if MonoTouch ends up being in compliance with Apple's terms from a legal standpoint, it's probably stands in defiance with the spirit of Apple's motives. In an e-mail message to a popular Mac tools developer whose work may be affected by the new rule, Apple CEO Steve Jobs made it clear he believes intermediate software (presumably including runtimes such as Java and Mono) create one more layer of headaches for developers, separating them from the ability to properly use the hardware as its architects intended.

Betanews asked the Mono team's leader, Miguel de Icaza (also the co-developer of the GNOME graphical environment for Linux), whether he felt Apple could interpret the continuation of MonoTouch as a defiance of Apple's intentions.
"We believe that there might be some valid concerns from a UI perspective in some cases if you use cross-platform tools that isolate the developer from the underlying platform," de Icaza told Betanews. "It seems that Steve Jobs alluded to that in an alleged e-mail exchange that is making the rounds around the net.

"From that perspective, MonoTouch is in compliance: MonoTouch is not really a cross-platform tool in that it does not try to offer a layer on top of Apple APIs, so developers get full direct access, without a middleman to the native APIs. This has the unfortunate effect that code written for MonoTouch cannot be ported to other platforms, but it delivers native UI experiences which is what iPhone and iPad users have come to expect."

In other words, as de Icaza sees it, the extra steps that a developer must take to make an app built with MonoTouch, or ported to MonoTouch from .NET, work with iPhone, may only be taken by individuals who intentionally write an app for iPhone. That should be the modicum of respect paid to the platform that Jobs is looking for.

A January 2009 Ars Technica article by Ryan Paul explains how Mono had been getting past Apple's rules and regulations up to now: For iPhone, it uses a concept called ahead-of-time compilation, which involves pre-compiling the assemblies in such a way that the Mono platform can convert them into native code, before a JIT compiler would have done the equivalent.

As the Mono Project explains, "AOT compilation works in two stages. The first stage consists of precompiling the assemblies. As of Mono 1.2, this is a manual process that individual deployments must do. The second stage is automatic, the Mono runtime will automatically load any precompiled code that you have generated."

Early in MonoTouch's history, Novell representatives stated their intention was to bring mainstream developers who already work in C# (created by Microsoft), and who never would work in Objective-C (Apple's object-oriented counterpart), into the iPhone development field. Training developers on a new language, they said, was an expensive process that could be avoided altogether through the use of what they have characterized as a cross-platform tool.

But Jobs' motivation here is clearly to capitalize on the iPhone's platform's size and traffic level, by forcing developers to pay attention to it directly if they are to play ball with Apple at all. Doesn't that motivation clearly exclude MonoTouch by definition?

"Our intention is to work with apple to get a clear understanding of their concerns, and we continue to believe that MonoTouch provides significant value to iPhone developers by liberating developers from manual memory management, but also liberating them from a whole class of bugs and problems that are endemic to C/C++/Objective-C programming and allow them to focus on innovating and building more powerful applications," the Mono Project's Miguel de Icaza told us.

"There is a downside to this approach: It means that developers who want to target Windows 7 or Android with our upcoming MonoDroid have to rewrite all of their UI, and all of their native integration with the platform as we strive to provide C# access to whatever the underlying platform offers, and we do not abstract that code. As I said at my presentation at MIX, this means that developers would have to split their code in 'Engine/Core' and 'UI' code if they ever want to reuse any of their code across phones."