My Thoughts On Section 3.3.1 of the iPhone OS 4.0 ToS

on April 23, 2010

There has been a lot of discussion about the changes that Apple made to the upcoming version of the iPhone OS 4.0 Terms of Service:

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

As both developers and consumers, CentreSource is affected by this decision in two ways.

While we’ve traditionally been a PHP shop, we have developers who are versed in JavaScript, ActionScript, Ruby, ASP .NET, Perl, and even a little Python.  When the iPhone Software Development Kit (SDK) was originally released two years ago, we played around with it, but the learning curve of teaching ourselves Objective C (the language required to use the SDK) ultimately led us to make the decision to explore utilizing a third party development tool called Titanium to create our iPhone apps.  Titanium is an application that allows you to write in a simpler/unified language, and then the tool recompiles the code to the Objective C required by Apple.

According to the new changes, applications like Titanium — or the about-to-be-released Adobe Flash to iPhone converter — are a no-no.  Why?  Commentators and speculators say it comes down to two main reasons:

1. Apple wants complete control.  In order to develop for the iPhone OS, you have to use Apple’s tools… On an Apple computer… With an Apple developer’s license…  Apple controls the entire development environment from the moment you start writing your code (on your Apple computer) to the point you start making money through releasing your app in the App Store.  Apple is able to dictate how, where, and when your app gets created and distributed.  While some see this as a monopolistic abuse of power, I see this as directly benefiting the fact that…

2. Apple has complete control.  By controlling the entire development environment, they are able to provide the tools and resources to allow app developers what they need to create applications that maximize the potential of the iPhone OS.  If they release a brand new set of features to their SDK (as they did last week), they are able to immediately integrate these features into their toolset for the developers to use.  When using tools like Titanium, developers are forced to wait until the 3rd party company changes their tools to be compatible with the new SDK before they can start using them.

Similarly, many argue that by “neutralizing” the tools used for creation, you’re not able to fully utilize the specific features for the end product. Think of any application that was created for a specific platform — Mac or Windows — and then think of applications that were “ported” to the other platform. No one will argue that Office on a Mac or Handbrake on Windows are anywhere close to the application on the platform it was originally written for.

From a development perspective, we’re not tremendously affected — primarily because we’re already fairly cross-versed in development languages. Adding Objective-C to our arsenal — while an inconvenience and time consuming — is by no means a deal breaker for us, especially given the benefits that Apple provides.  For most of us, we’d have to learn another language / SDK of some kind in order to develop iPhone OS apps — why not just go right to learning Objective-C.

From a consumer perspective, I believe this is great news. Imagine the scenario that Louis Gerbarg of /dev/why!?! presents:

Imagine if 10% of the apps on iPhone came from Flash. If that was the case, then ensuring Flash didn’t break release to release would be a big deal, much bigger than any other compatibility issues. Since Apple doesn’t have access to Flash CS5’s runtime library code or compiler frontend, they might be put in a position where they would need to coordinate with Adobe to resolve those issues. Shipping a new release where Apple breaks any specific application, even a top seller, is not an issue if the release is compelling, most apps work, and Apple has the option of working with the vendor to help them fix their app. Shipping a release where they break a large percentage of apps is not generally an option. Letting any of these secondary runtimes develop a significant base of applications in the store risks putting Apple in a position where the company that controls that runtime can cause delays in Apple’s release schedule, or worse, demand specific engineering decisions from Apple, under the threat of withholding the information necessary to keep their runtime working.

Clearly this is not an ideal scenario for Apple or for their consumers. Apple’s imposing restrictions are a protective move for themselves and their consumer — ensuring the high level of user experience that Apple has come to be known for, and not letting 3rd party vendors effect their reputation.

Is this bad news for Adobe? Youbetcha. They are increasingly grasping at straws to stay relevant in a marketplace that is leaning more towards HTML5, and turning “Flash” into a bad word. I agree with some of my colleagues that Flash still has an appropriate place on the web, and heavens knows how many ActionScript developers are bummed about this decision that effectively eliminates them from developing on a platform that accounts for 45% of mobile browsing.

At the end of the day, when the dust of iPhone OS 4.0 finally settles, there will still be a plethora of apps (good and bad) in the iTunes App Store. This decision will be long forgotten by all those involved (well, except maybe Adobe), and the consumers will remain happy and buying phones.

As for CentreSource? Bring on Objective-C!

** Note: my opinions may be a bit biased… This whole post was written on my Apple iPad — which is awesome by the way… But that will be a saved for a separate blog post!