Before April 8th, developers targeting the iPhone had to deal with this section:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

The above is a pretty reasonable requirement as it gives Apple the chance to not have to maintain and support internal APIs, temporary APIs or APIs that have not fully matured.

When iPhoneOS 4.0 was announced, the wording was changed to:

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).

This spelled disaster for many developers that had chosen to use other programming languages like C#, Delphi, Lua, Python, Javascript, Java, Scheme, ActionScript and a handful of others. It also put a stop to porting efforts for languages like Eiffel and other industrial languages that can be used on the iPhoneOS and the iPad.

Much of the discussion for the rationale of these changes on the blogosphere has centered around personal language preferences. They amount to little more than the usual discussions of Mac vs PC or Emacs vs VI.

When Greg from Tao Effect discussed this with Steve Jobs his reply shed light into the reason. There is a business reason, and possibly a UI reason. Here are my theories.

Theory #1: The Business Case

With the iPhone Apple revolutionized the phone market in a way that nobody had planned for. Microsoft, Nokia, RIM, HTC and everyone else was left to catch up with the user experience and the operating system. One year after the iPhone took the world by surprise, Apple opened up the developer stack, launched the AppStore and leapfrogged every competitor in the field.

Apple had the first mover advantage in a space that they created: the high-end smart phone market.

The problem that Apple faces is that now every competitor has a blueprint of what they need to aim for. Competitors now know what the minimum required user experience and features required are. And they all likely have plans on how they can differentiate themselves and add features that Apple does not have.

And this is where Adobe enters the picture.

Flash and Flex have a huge user base of developers that have been building web and desktop applications for the past few years.

Although Flash applications on the iPhone do not look and act like native iPhone applications they are useful for a certain class of development. It would very likely attract Flash developers to the iPhone, but also Objective-C developers to Flash. Developers that probably are not interested in creating UITableViews or using the low-level APIs, but wanted to focus more on the interactive content creation or exploring new UI ideas or games.

Flash's killer feature would be that the same code that ran on the iPhone would run on many devices with minimal changes. The applications do look alien on every platform, but not every application needs to use native controls. Games, storyboards, marketing tie-ins and a whole new class of ideas do not need a native UI.

Flash would erode some of Apple's first mover advantage in the market they created. So section 3.3.1 was added to protect Apple's shareholder's interests.

Apple being the #1 platform for mobile applications and being the largest distribution channel for those applications probably felt that it would be ok to do.

Eventually, Android, Windows Mobile 7 and Nokia will catch up in terms of UI with Apple. It might take a few years before there is a marketplace as large as Apple's AppStore and a few years before these phones catch up to Apple's dominance in the space.

My prediction is: When those platforms do catch up to Apple in terms of market share and applications Apple will lift the restrictions on section 3.3.1. Apple at that point will have nothing left to lose and everything to gain. Adobe will also bring Flash back to the iPhone as it will be a nice bump in revenues.

Theory #2: The UI

As I mentioned before, using cross-platform solutions like Flash or Silverlight would make every application look alien. But also like Steve Jobs alluded to, developers would not have access to new features on the iPhoneOS if they had chosen a technology that did not expose it.

For example, when Apple introduced in iPhoneOS 3.2 the new split views that the iPad uses extensively when rotating your screen, that functionality would have taken too long to bring in a satisfactory way to say Silverlight on iPhone or Flash on iPhone. Or when Apple introduced the UIView that can be used to render maps, it would also have been challenging to embed this control. Or when Apple introduced GameKit, an API to connect iPhones and exchange messages between them.

As a developer, I feel that I should be responsible for my technological choices. If I pick a cross-platform toolkit that looks horrible on the iPhone, it will just leave the space open for a competitor to do a better job. Or if my application does not take advantage of a new API in iPhoneOS, I am also leaving a flank open for a competitor to take over. Apple does not need to intervene with guidelines as the application quality, the AppStore, magazines, reviews and word of mouth are creating the conditions for an all-out darwinian survival of the fittest.

Why MonoTouch has been misrepresented

MonoTouch has been misrepresented, initially by Gruber and by most people covering the debate over section 3.3.1. Probably because few of them have actually used MonoTouch or because they are not familiar with .NET. Probably folks think that MonoTouch is .NET, and .NET is Microsoft's Java and draw their own conclusions.

MonoTouch brings the C# language and the core of .NET to the iPhone, but does nothing to provide a cross-platform UI experience or for that matter any sort of mobile device cross-platform APIs.

We bring the C# language, garbage collection, a type safe system that help reduce errors, make programmers happier and more productive on the iPhone while getting access to every single iPhoneOS API that they want to.

We have also been able to expose new APIs that Apple has exposed in record time thanks to the fact that we are not really an abstraction layer over the iPhoneOS, but merely a compiler that talks to the native APIs.

We released the iPad support 24 hours after Apple released the SDK. We released the iPhoneOS 4.0 support within days of the release (mostly because every one of us was pretty bummed out). Our APIs are a 1:1 mapping to the iPhone APIs.

Just like C and C++, if developers want to reuse code between MonoTouch, Windows 7 or MonoDroid, they will have to split their UI and device-specific code from their business logic. MonoTouch does not provide such an abstraction layer.

The "core of .NET" that I refer to previously means: garbage collection, type safety, the platform-invoke bridge, file and networked streaming APIs (contrast with the iPhone ones), XML and Json libraries, Language Integrated Query, access to web services and the ability to reuse hundreds of GUI-less libraries that have been created for .NET.

We believe that MonoTouch does not erode Apple's first mover advange and nourishes the iPhone ecosystem by giving developers and users the native iPhoneOS experience.

The Mono team is proud to bring you a preview of C# 5.0 a few years before our friends in Building 41 do.

A snapshot of the code is available in the demo-repl.zip file. This contains the csharp.exe C# REPL shell and the Mono.CSharp.dll compiler-as-a-service assembly.

With Today's code drop all those scenarios now work:

• Run Mono's C# compiler on .NET
• Embed Mono's Evaluator in your C# app.
• Use Mono's REPL with the .NET framework runtime.

Update April 28th: I have now uploaded a new version that fixes the bug that people were getting when importing other libraries. Thanks to Marek for the rapid fix.

Background

Although we have had a compiler-as-a-service framework since September of 2008 it has been so far limited to Mono users, which effectively means only Linux and OSX users could use our C# REPL and the compiler as a service.

The reason is that the Mono's C# compiler uses System.Reflection.Emit as its code generation backend. This API was fine for implementing C# 1.0 but required a few changes to support compiling its own core library (mscorlib, the equivalent of libc in C or rt in Java).

When we started to work on our C# 2.0 support, we were working on our compiler as the language was being standardized at ECMA. Our compiler evolved faster than the underlying support for Reflection and Reflection.Emit did and this lead to more Mono-specific extensions being added to our Reflection and Reflection.Emit code. The more extensions that we depended on, the fewer chances we had of running with Microsoft's runtime.

As time went by, Microsoft did improve their System.Reflection.Emit, but at that point, it was too late for us to go back to it.

This had the unfortunate side effects that our compiler could not run on the Microsoft runtime. Now, this per se is not a major problem since Windows users likely use Microsoft's CSC compiler.

But this also meant that our awesome compiler as a service could not be used by .NET developers and it also meant that our REPL shell could not be used with .NET and most importantly, neither one would run on Silverlight.

Our compiler also relied heavily on our extended System.Reflection and System.Type as its own type system. And we could not just change our APIs for Microsoft's APIs to run on the Microsoft runtime.

Today's commit at the coref replaces our dependency on System.Type and introduced our own Mono.CSharp.TypeSpec which lifts many of the restrictions that we had on System.Type. All of the hard computations that we had to do for inflating generics types are done here now and we can query the types without the backward Reflection limitations.

With today's changes, not only we became more portable, but the move from System.Type to TypeSpec and MemberCache improved the compiler performance by 30% and fixes dozens of bugs that were very hard to fix with the previous compiler architecture.

REPL Love

We have a small guide on using the C# REPL on Linux.

Caveat: both the Microsoft and the Mono C# compilers loads libraries from their "base directory", never from the Global Assembly Cache.

In Mono, the csharp command happens to be in the same directory as the rest of Mono, so loading implicit libraries just works (Loading System.Core for example). But when running our csharp command on Windows, unless you put the binary in the same location as csc.exe the REPL wont be able to load libraries using their short names.

This is particularly obnoxious because to use LINQ you need to use the full assembly name, or copy csharp.exe to the directory that contains System.Core so you can just do:

	csharp> using System.Linq;
	csharp> from x in "Foo" select x;
	

Future work

Public API: There is still some work left to do: we need to turn 99% of the public API in that assembly into a private API, the only class you should care about is the Mono.CSharp.Evaluator class, the rest you should consider internal.

The Evaluator API needs to evolve, right now it is a big singleton that exposes all of the variables defined as global variables. They really should be tied to some kind of context so we can support multiple and independent execution contexts on the same address space.

Chances are that we want to expose some of the internals of the compiler to the world, but we first need to figure out what makes sense.

Now that the code runs on .NET, hopefully those of you that wanted to embed it can provide us some feedback on how you would like to see this API change or even better, provide patches for it.

C# as a DLR language: Someone had suggested to also provide a hook into the DLR, so you can instantiate C# eval engines with the same API that you instantiate IronPython and IronRuby eval engines.

Silverlight support: in theory this works out of the box, but we have not tested it yet.

Contributions: Yes, we are accepting contributions to this awesome compiler.

Keybindings: Currently the csharp command line repl uses Emacs keybindings as part of my fabulous getline.cs command line editor. We are aware that developers of different faiths might find other keybindings more appropriate. We are taking patches.

Add support for IKVM Reflection: Jeroen has written a drop-in replacement for System.Reflection[.Emit] that will allow us to decouple the compile from the profile that it compiles code for (Monoistas are familiar with dmcs, smcs, gmcs and mcs; We will be able to have a single compiler).

Source Code and Hacking

The source code for Mono's C# compiler, the Compiler as a Service and the interactive REPL are all available from SVN, do a checkout from our subversion repository for the module "mcs".

Download from GitHub the "mono" module

Then open the VS2008 solution in mcs/tools/csharp. This will build the Mono.CSharp compiler as a service library and the csharp tool.

We do not typically provide VS Solution files for most of Mono, but we are making an exception for the compiler as a service to encourage .NET developers to play with it.

Update: Our compiler is MIT X11 licensed, so even developers at Microsoft can download this code and look at it. It is all kosher guys!

Today we released MonoMac, a new foundation for building Cocoa applications on OSX using Mono.

MonoMac is the result of years of experimentation in blending .NET with Objective-C and is inspired by the same design principles that we used for MonoTouch.

It is also the result of weekend hacking as our day to day work revolves around Mono's efforts on Linux servers, Linux desktops, Visual Studio integration and our mobile efforts. Luckily, it shares some components with MonoTouch.

To get MonoMac, you need to get two modules from GitHub: monomac and maccore.

Background

Many years ago Geoff Norton produced CocoaSharp, the first set of .NET bindings to the Cocoa API. CocoaSharp was a fine first binding at the time and it was a good place to start learning about the challenges of binding Objective-C APIs to be consumed by .NET clients.

Over the years three other frameworks were created to integrate the Objective-C world and the Objective-C APIs with C# and other .NET languages. Each one of these new frameworks had its pros and cons, and a year ago we made a call for all three competing frameworks to be merged, but sadly nothing came out of it.

When we created MonoTouch, we wanted a binding for the Cocoa APIs that would fit the patterns and idioms used in the C# and .NET worlds, that would comply with the .NET Framework Design Guidelines and would allow give developers all the tools required to build full Cocoa applications.

We had two main requirements: the binding should just work and the code should be MIT X11 licensed. For the binding to just work, we turned to the .NET Framework Design Guidelines book as it captures years of design decisions, programming idioms and advise that would help C# and .NET developers. By following the Design Guidelines we:

• Avoid surprises
• Blend with other C# and .NET libraries
• Reduce the room for errors
• Increase developer joy
• Minimizes time for the developer to be productive
• Every bit of existing .NET knowledge translates

Luckily for us, .NET was designed from the start to be an interoperability framework. A framework that supports the most advanced requirements to make multiple runtimes and frameworks to communicate seamlessly with each other. We used these features to create our bindings.

The above goals turned into the following technical requirements:

• Developers should be able to consume Cocoa APIs as C# APIs
• Allow developers to subclass Objective-C classes
  • Subclass should work with C# standard constructs
  • Derive from an existing class
  • Call base constructor
  • Overriding methods should be done with C#'s override system
  • Do not expose developers to Objective-C selectors
• Provide a mechanism to call arbitrary Objective-C libraries
• Make common Objective-C tasks easy, and hard Objective-C tasks possible
• Expose Objective-C properties as C# properties
• Expose a strongly typed API, for example instead of exposing the generic-container NSArray or individual NSObjects. This means that developers get a few benefits:
  • MonoDevelop can flag errors as you write the code
  • MonoDevelop can present documentation popups on types, methods, properties and parameters as you type them.
  • Minimize runtime errors by catching invalid casts at compile time.
  • Encourage in-IDE API exploration without rebuilding, and without having to look up the types in the documentation.
• Turn int and uint parameters that should have been enums as C# enumerations and C# enumerations with [Flags] attributes
• Expose the basic Foundation as C# native types:
  • NSString becomes string
  • NSArray becomes strongly-typed array
• Events and notifications, give users a choice between:
  • Support the Objective-C delegate pattern:
    • Strongly typed version is the default
    • Weakly typed version for advance use cases
  • C# event system
• Class libraries should be MIT X11 licensed, like the rest of Mono's class libraries.
• Expose C# delegates (lambdas, anonymous methods and System.Delegate) to Objective-C APIs as "blocks".
• Curated APIs: there is no point in binding every UNIX or CoreFoundation C API available, as those are not very useful in practice. Bind only those that are required to build applications or get access to mandatory functionality.

More information about our API can be found here: http://monotouch.net/Documentation/API_Design

Binding Cocoa

Cocoa consists of two sets of APIs, one set is an object oriented C-callable API and another one is the Objective-C based API.

C-based APIs were bound using a traditional P/Invoke approach where the C-based API is wrapped in a C# class. This includes APIs like AudioToolbx, CoreGraphics, CoreFoundation and CoreText. There is very little magic in these bindings, they are straight forward bindings, similar in spirit to what you would do if you wrapped those APIs for C++ use. I am in particular very proud of the much simpler AudioToolbox API.

The Objective-C APIs is where the UI heavy lifting takes place and where most of the high-level functionality is found, and this includes APIs like Foundation and AppKit. The Objective-C APIs are bound using a new binding engine (MonoMac.ObjCRuntime) and the btouch binding generator.

The btouch binding generator consumes an API contract in the form of a C# source file and generates a binding that matches the specified contract., for example, this is the API definition for the NSActionCell:

	[BaseType (typeof (NSCell))]
	interface NSActionCell {
		[Export ("initTextCell:")]
		IntPtr Constructor (string aString);
	
		[Export ("initImageCell:")]
		IntPtr Constructor (NSImage  image);
	
		[Export ("target")]
		NSObject Target  { get; set; }
	
		[Export ("action")]
		Selector Action  { get; set; }
	
		[Export ("tag")]
		int Tag  { get; set; }
	
	}
	

We produced a comprehensive guide to binding Objective-C APIs with MonoTouch that applies directly to MonoMac.

Since a lot of the work of binding an Objective-C API is very repetitive, we have also included a header parser that does most of the heavy lifting in producing the above API from the Objective-C header file. The parser output then needs to be then massaged a bit to produce a binding that satisfies our design requirements. For example, NSArray arguments and return types must be looked up on the documentation and the proper strong typed inserted.

Status

Unlike MonoTouch, MonoMac is not a complete binding for all of the Cocoa APIs at this point. This has been a weekend effort for Geoff and myself but it has reached the point where it can be used for building applications and it has reached the point where we can start taking contributions to the effort.

Currently MonoMac binds:

• CoreFoundation (the parts that are needed, see the design principles)
• CoreText (done)
• CoreGraphics (done)
• Foundation (the parts that are needed, and helper tools to support the rest)
• AppKit (About 30% left to be done)

If you are interested in advancing the state of MonoMac, we are currently looking for contributors to help us bind the other Objective-C frameworks and help us complete AppKit.

Where we are going

MonoMac is merely the library that gives C# developers access to the underlying APIs on OSX, it does not include the tooling necessary to create a full application bundle.

Luckily, MonoDevelop has already most of the code needed in the form of the MonoTouch plugin. We will update this plugin to also support creating full application bundles for OSX.

A new feature that developers will be interested in is the new "Mono bundler" tool that we are hoping we can include in Mono 2.8. This bundler examines your .NET application and generates an application bundle that contains both your application code and any dependencies that it needs from Mono in a self-contained package.

This is the technology being used by Banshee on OSX today. The tool constructs a self-contained application based on your system installed Mono that you can distribute to your users, without requirement them to install Mono in the first place.

But we need your help. There are many small and medium tasks that developers can help us with that will free our already busy weekends and will allow us to have a full MonoMac experience done in a shorter period of time.

The more help we get, the sooner this will be done.

We need contributors in the following areas:

• API binding for the rest of the Frameworks
• We need samples to be written
• We need tutorials to be written (like the ones we did for MonoTouch)
• We need to port existing Cocoa samples to C#:
  • To exercise the binding
  • To serve as reference for new developers
  • To identify missing frameworks
  • To prioritize bindings
• We need to alter MonoDevelop's plugin to produce OSX Application bundles.

Please join us on the mono-osx mailing list to discuss the future of MonoMac.

Update Currently this requires a preview Mono to work from http://mono.ximian.com/monobuild/preview/download-preview/

We have just released MonoTouch 3.0.0 with support for iPhoneOS 4.0's new APIs. To try it out, you need to have Apple's iPhone 4.0 SDK installed otherwise MonoTouch 2.0 wont let you download the new toolkit (since it is Apple confidential at this point).

This release is a preview, the final release will be some sort of 3.0.XX number.

This release includes API support for the features that Apple announced last week, in broad terms:

• Background application support
• iAd support
• Local notifications
• Game Center support
• Support for enterprise data protection

We also sneaked in some new work that is not bound to the iPhoneOS 4.0 API and can be used when building for iPhoneOS 3.1.x and 3.2.x:

• Size reductions:
  • Linker updates to reduce executable size
  • More fat trimmed from the final executable.
  • "Hello world" is 500k slimmer now
• Native support for Objective-C blocks on the binding generator:
  • Exposed as C# delegates
  • Both lambdas and anonymous methods can be used as blocks
  • Standard C# semantics for variable capturing

We have released a big update to Moonlight on Linux, our Moonlight 3, Preview 6.

New in this release:

• Chrome support and chrome packages
• Many performance improvements
• Most Silverlight 3 features are in now, including taking apps out-of-browser
• Hundreds of bug fixes and improvements our Silverlight 3 compatibility story

Remember to file bug reports. If you do not file a bug report, we have no way of knowing that something is not working.

The ECMA working group that drives the Common Language Infrastructure standard (ECMA 335) has published the working draft for the 2010 edition of the standard.

These are the work-in-progress documents that the team is working on.

In addition to the Novell mirror copy above, you can get the standard from the following sites:

• Eiffel Software (http://www.dotnetexperts.com/ecma/)
• Microsoft Corporation (http://msdn.microsoft.com/en-us/netframework/aa569283.aspx)
• Novell Corporation (http://mono-project.com/ECMA-335-CLI-Public-Draft)
• Kahu Research (http://kahu.zoot.net.nz/ecma/index.html)
• Twin Roots (http://twinroots.com/ecma/index.html).

This year, Michael Hutchinson is the administrator for Mono's involvement in the Google Summer of Code.

We are looking for motivated students that would like to either work on one of the ideas that we listed in our Student Projects page like work on MonoDevelop's IDE, Mono's runtime, Mono's class libraries and in Mono-based applications.

Additionally, if you are a student and you have been thinking "The Mono guys really should do...", do not hesitate and propose your idea. Perhaps you get to implement your idea, get paid to do so, and be mentored by our group of awesome C and C# hackers.

If you are a student, you can apply here and Google has a convenient list of frequently asked questions about the program.

Remember: There are only 3 days left.

We just released our updated version of MonoTools for Visual Studio:

A tool that helps Windows/.NET developers target Linux systems directly from Visual Studio, this release is still intended to be used with Visual Studio 2008 and includes some important improvements:

• Smarter Remote File Copying
• Automatically Detect Future Updates
• Preview of Visual Studio 2010 Support
• Easier Packaging of Precompiled Web Applications

We are hard at work on our 2.0 release that will include soft-debugging support, MacOS support and will also run with Visual Studio 2010.

From Steve Jobs 1997 presentation when he announced his partnership with Microsoft:

Where we are right now is, we are shepherding some of the greatest assets in the computer industry.

If we want to move forward, seeing Apple helping an prospering again.

We have to let go of this notion that for Apple to win, Microsoft has to lose. We have to embrace the notion that for Apple to win, Apple has to do a really good job. And if others are going to help us, that's great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else's fault, it is our fault.

So I think that is a very important discussion.

If we want Microsoft office on the Mac, we better treat the company that puts it out with a little bit of gratitude. We like their software.

So the era of setting this up as a competition between Apple and Microsoft is over as far as I am concerned. This is about getting Apple healthy and this is about Apple being able to make incredibly great contributions to the industry and get healthy and prosper again.

I feel exactly this way about open source. For open source to win, we do not need Microsoft, Apple or proprietary software to lose. The industry is not a zero-sum game, not only we enrich each other's platforms by exploring different ideas, but it is also incredibly healthy for the industry to have a blend of different approaches to computing.

Open source software leads in some areas in the industry and we as a community are very proud of its success. But when it comes to the areas where open source has not delivered a full solution like our proprietary competitors have, we resort to finger pointing and blaming others.

Some in the open source movement would like all the software in the industry to be open source/free software. Desktops, servers, games, embedded systems and everything that every human touches.

Although it is a noble goal, it has set people up for suffering by making the goal unachievable. It has been 15 years since the rise of the first large open source companies and by now we should know that our dream of a pure open source stack ruling the world is not going to happen any decade now.

Luckily, today, we have a much better understanding of where open source works and where it does not.

It would do us good to ponder Steve's 1997 message:

And if others are going to help us, that's great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else's fault, it is our fault.

Once again, I want to recommend Ben Zander's The Art of Possibility book, a book with various recipes on how to look at the world through new eyes.