How MonoTouch gets around Apple's VM restrictions

You've probably heard that Apple does not allow any interpreted or run-time compiled programs on the iPhone. That's why you don't see Flash, C#, or Java used on the iPhone. Now, companies like Adobe and Novell are trying to do something about that. In a ZDNet Q&A, Joseph Hill, product manager for Mono at Novell explains their approach with MonoTouch.

The MonoTouch project lets you run Mono programs on the iPhone. Mono is an open source implementation of Microsoft's .NET platform sponsored by Novell. Normally, .NET code written, for example, in C# runs inside of a virtual machine. The VM takes an intermediate form of the code called bytecode (or in the case of .NET, MSIL) and either interprets it or does a Just-In-Time compilation to native code as needed. Apple doesn't allow that, so as Joseph Hill explains, Novell had to take a different tack.

Ed: Why does Apple allow .NET development with MonoTouch when they don't allow Java development on the iPhone/iPad? Joseph: Java (and other runtimes) are restricted from being deployed to the iPhone because an application cannot execute writable memory. Virtual machines like Java and .NET generate native code from bytecode at runtime, and then execute this code; however, for various reasons, the iPhone kernel will not allow this code to be executed. Mono's Ahead-Of-Time (AOT) feature avoids this issue by generating all native code that the application could generate at runtime ahead-of-time, so the application deployed to the iPhone is a 100% native application.

Ed: Does Ahead-Of-Time compilation make some features of .NET unavailable? Joseph: The primary feature that is lost to AOT compilation is Reflection.Emit. (Since this would generate code that could not be executed.) Normal reflection is okay.

Next: Do I still need a Mac? >

Ed: What tools does the developer use for MonoTouch development?

Joseph: While the MonoTouch SDK includes all the tools needed to build applications from the command-line, the primary development environment used by most MonoTouch users is MonoDevelop.

MonoDevelop is an open-source IDE for Windows, Linux, and Mac; however, MonoTouch depends on Apple's SDK for the iPhone Simulator, Interface Builder, and to sign applications for deployment, so MonoTouch is only available on Mac OS X.

Ed: So you still need a Mac to do iPhone development? Joseph: MonoTouch does require a Mac. Some of our users prefer to use Visual Studio for editing their code; however, the tools to build with MonoTouch only run on the Mac.

Ed: How do you debug MonoTouch code?

Joseph: MonoTouch uses a soft-debugger engine which allows MonoDevelop to debug applications in the simulator, or on device over the WiFi connection. More details can be found here.

Ed: How do you profile it? I assume the Apple tools won't work. Joseph: The Apple tools are the only option at this point, but admittedly, this is a weak spot in our story, as most MonoTouch users will not be comfortable with this. We are investigating options to improve this, but actually have not heard much noise about this from users (yet). We suspect most developers just resort to measuring with Console.WriteLine() mechanisms.

Ed: Are all native iPhone libraries available to your .NET program? Joseph: Most iPhone libraries are available, with the notable exception of CoreData. APIs that have been left out have been dropped because alternative APIs exist in Mono that .NET developers will prefer using.

We do include the btouch tool to enable users to bind Objective-C themselves if they feel they need something we've omitted, or want to bind their own Objective-C libraries.

Ed: What does a call to a native C or Objective C function look like in C# source code? Joseph: Invoking native C libraries uses P/Invoke. We have a set of attributes for binding to Objective-C selectors that is outlined here. The btouch tool can generate a lot of these bindings for developers.

Next: Why should I care about C#? >

Ed: As a developer, why would I want to program in C# rather than in Objective C? Joseph: One of the primary advantages of using C# is automatic memory management. Objective-C does not include garbage collection on the iPhone, whereas MonoTouch does. C# also type-safety, which can prevent a significant number of runtime errors by catching them at compile time.

Beyond this, C# is less verbose, so fewer lines of code are generally needed, and MonoDevelop's integration to Interface Builder reduces this further.

Another advantage C# brings is access to the .NET framework class libraries, including access to Web Services, System.Xml, System.Threading, and others. It also has a growing number of 3rd party and open source .NET libraries that MonoTouch compatible.

Ed: What is limiting Mono adoption right now and what is being done to address it? Joseph: There is a lot of speculation on this topic, but I think that, to date, the biggest things holding back adoption of Mono have been:

1. Awareness - Mono is relatively well known to Linux developers, but, until recently, was not been very visible to Windows developers.
2. Perception - Many of the .NET developers that are aware of Mono looked at it several years ago, and are under the impression that Mono is far less complete than it is.
3. Approachability - For developers accustomed to only developing in Windows, asking developers to learn Linux, and to move out of their comfort zone can be a bit much. The perceived challenges might have seemed greater than the reward.

With product offerings like MonoTouch, and particularly with the Mono Tools for Visual Studio add-in that we launched last fall, we've been putting considerable effort in making sure that we make Mono as approachable as possible, and are really trying to make it as easy as possible for developers with little-to-no experience developing non-Windows applications to quickly become productive with Mono. The excitement around MonoTouch has made a lot of .NET developers more interested in Mono, MonoDevelop, and cross-platform development in general.

Ed: Do you have any plans to bring Mono to Android as well? Joseph: We're very interested in this, but have no specific plans to announce yet.

Conclusion:

Last year, Adobe developed a similar system that allows you to run compiled Flash code on the iPhone. Several programs currently in the App Store use this technique, including Boost Your Brain, Red Hood, and South Park. The idea behind these .NET and Flash compilers is to let developers leverage the knowledge and code they already have to port their apps to new platforms.

If you ask Apple why they have these restrictions, they say it's because they want the best experience for their users. The real reason probably has more to do with control than altruism. Android, Windows Mobile, and Symbian, for example, didn't feel the need to impose such a restriction.

Hopefully someday we'll see more workarounds like this for languages such as Java and Lua, or perhaps Apple will simply succumb to pressure and lift the restrictions. Programmers should be able to pick the best tools for the job, based on their own needs and experience rather than some arbitrary rules cooked up in Cupertino.