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.
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.
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.
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.
Posted on 28 Apr 2010