How MonoTouch gets around Apple's VM restrictions

How MonoTouch gets around Apple's VM restrictions

Summary: 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 programs there. 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.

SHARE:

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.

Topics: iPhone, Apple, Mobility, Open Source, Software Development

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

10 comments
Log in or register to join the discussion
  • mono iPhone = icrap

    combine 2 proprietary technologies from monopolists like M$ & Apple and end up with a mess.
    Linux Geek
    • Your parents must have been monopolists

      on something, cause they produced you: a mess
      markbn
    • You're wrong on Mono

      Mono is open source, and is sponsored by Novell.
      nDuDut
      • Yup - it HAS to be licensed that way

        and written by those who truly believe that Microsoft's short-term limited covenant not to sue certain distributors means it is A-OK - IF you want to succeed at "poisoning the well" of free software, that is... J/K, Microsoft is all about giving competitors a leg up, and all about ameliorating any negative effect it's monopoly may have on the market...

        Go, team Miguel.
        imric_z
  • RE: How MonoTouch gets around Apple's VM restrictions

    I love what they're doing with mono, and this is the perfect
    approach - bring .NET to platforms that MS wouldn't even
    consider. This is a HUGE advantage to corporations that
    can make use of existing resources and code.

    With Win Phone 7 coming, which most likely will be
    (mostly?) developed in .NET, this will give a way to share
    development across many devices (considering mono is
    now coming to android as well!).
    curtis.wensley
    • Mono supports multi-task

      So how does it fit in a non-multitask iPhone?
      LBiege
      • Maybe you get multiple Mono tasks inside a single iPhone task?

        Is one way.
        Robert Carnegie 2009
      • The iPhone multitasks quite well.

        You can run as many threads on an iPhone application as the hardware can support. The multitasking restriction on the iPhone is related to outside events and applications.

        Apple does not want a large number of applications running in the background. This eats up batteries fast. Thus, when the phone rings or another event interrupts the game you are playing, your applications is suspended. When your phone call is over, the application is restored.

        Some Apple applications and processes are allowed to multitask. If you are playing a game or looking at a map, you phone can ring.

        Application designers can create simulated multitasking applications with notifications. Lets say one of the users of your weather program is about to be run over by a tornado. You send a trigger to Apples notification server. The server tells your users phone to wake up the weather program and post a message. The weather program tells your user to duck and cover.

        From the programmers perspective, the only limitation is that your program can't run when another program is running. From the users perspective, he does not lose the game because of an incoming phone call and his batteries last 10 times longer.
        Ralfthedog
      • Multiple threads in the foreground are ok

        Apple allows as many tasks (threads) in the foreground application as you want. In fact it's a necessity if your program is doing any network I/O or other long-running code so that your user interface doesn't get locked up.

        What they don't allow is programs running in the background. Unless you're a special blessed Apple-written app like the music player or phone, as another poster noted.

        Android allows background processing, but programmers have to be really careful not to overuse it, or it will drain the battery. That's why when the battery runs down and you get that "please charge your phone" message, there's a button at the bottom that will open up a list of the top applications that used the battery. If you spot a battery hog on the list you can uninstall that program and get another one that works better. Or not. It's entirely up to you.
        Ed Burnette
  • monotouch

    This database is compatible with monotouch:
    http://www.kellermansoftware.com/p-43-ninja-net-database-pro.aspx
    asavasamuel