Steve Jobs’ Response: A Brief Followup

The attention that yesterday’s post received is astounding, but unfortunately from the looks of it a lot of people seem to have a poor understanding of the situation. I feel compelled to address some of the sticking points.

On MonoTouch and other 3rd Party Tools

Some people appear to be under the mistaken impression that these changes are designed to prevent Java-like “non-native” UIs on the iPhone.

To be clear, the situation on the iPhone is completely different from that of the Mac. From the user’s perspective, you cannot tell the difference between an application written using MonoTouch or NimbleKit or Unity3D (non-Apple sanctioned tools that allow developers to code for the iPhone in non-C languages), and those written using Apple’s tools and Objective-C.

They look and feel exactly the same.

This is because they’re all using Apple’s UIKit to display the UI. In the case of Unity3D, which produces OpenGL games, you can’t tell whether the game was made using Unity3D or directly in Xcode, so it’s dubious that this is solely about “quality control” and keeping a uniform UI. If that was their sole motivation they could simply mandate that all non-OpenGL user interfaces make use of the native Cocoa frameworks and widgets.

Is it possible that these applications might be somehow better, perhaps faster, were they written directly with Apple’s tools? Maybe. Is that reason enough to outright ban them though? There are already hundreds of apps on the AppStore built using Unity3D, some of which are best-sellers.

There appear to be rumors online that even the Tap Tap Revenge game that Steve demoed during the iPhone 4.0 keynote is partially written in the Lua programming language. Oops.

It’s not surprising though (if true), because many popular games use a non-C scripting language for their game’s logic. It’s a versatile and common practice that gives developers (and even users) flexibility and creative freedom.

Whether Apple will remove these games I don’t know (I doubt it really). If they don’t, it’s hypocrisy because the wording of Section 3.3.1 clearly forbids it, and if they do then a bunch of great apps get pulled, a bunch of great developers get screwed, and a bunch of users are left disappointed. Even if they don’t pull these apps, Section 3.3.1, in its current state, is likely to deter future developers from taking advantage of these powerful techniques.

On Firefox

Many commenters seemed to be confused as to why I brought up Firefox. That discussion was tangential to the issues with Section 3.3.1. Steve referred to the “intermediate layers” that have existed on the Mac, suggesting that they all ultimately lead to sub-standard applications:

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

Though there is truth to that I feel it is only half the story.

The question isn’t whether you agree or disagree about the quality of cross-platform applications, but whether they should be allowed to exist on a platform at all (please don’t forget we’re still talking about the Mac, not the iPhone, where most, if not all, 3rd party toolkits produce native-looking applications).

As far as the Mac is concerned, I’m grateful for the existence of high quality cross-platform software such as Firefox. A lot of people were puzzled at why I chose Firefox as an example of high-quality cross-platform software, the reason is simple: it fulfills my needs for web browsing better than every other web browser.

Only because so many people brought it up, here’s a brief list of features that explains why I feel this way, and please note that I consider the availability and quality of plugins/add-ons as part of the browser’s whole:

  • The Firefox AwesomeBar is awesome. It’s like Spotlight for your web browser.
  • Firefox’s bookmarks allow both tags and descriptions, which I make heavy usage of.
  • I love Firefox’s find-as-you-type feature.
  • I can drag my Firefox data folder to any machine on just about any operating system and everything will just work there.
  • I’ve noticed that Firefox uses far less RAM than Safari on my MacBook Pro. Where Safari will use upwards of 1.5GB of RAM, Firefox will use only about 800MB for the same “level of browsing,” and it’s far better about clearing that out when you close windows. To those who claim the opposite to be true, I suggest you delete your Firefox application support folder and reinstall the latest version.
  • Firefox’s diverse and remarkably powerful addons are my #1 reason for using it. Many of the addons that I use have no equivalent on other browsers, and this simply seals the deal for me. Some of my personal favorites, in no particular order, include: Tab Mix Plus, ProxyButton, Session Manager, URL Link, WikiLook, Adblock Plus, BlockSite, DownloadHelper, Firebug, and Greasemonkey.

Why does Firefox have so many awesome add-ons while Safari and other browsers do not? Oh, that’s right, it’s because Firefox runs on just about every operating system, and the addons are cross-platform as well. Firefox’s users thereby reap the benefits that an open platform and an army of developers provides.

Sure, Firefox doesn’t integrate with OS X’s Services and other Cocoa-only things, but for me it more than makes up for those relatively benign flaws, and I’m grateful to have it prominently displayed in my Dock.

EDIT: It appears the latest versions of Firefox do integrate with OS X’s Services. Some minor Cocoa functionality still appears to be missing (like the Dictionary lookup shortcut, though there are add-ons for that), but this is certainly a pleasant surprise. I could only find this two year old article referencing the changes.

Conclusion

Don’t let the digression on Firefox fool you into thinking that I’m demanding Apple allow XUL apps like Firefox on the iPhone. That’s not what Section 3.3.1 is about.

Section 3.3.1 bans applications that look and behave like all the other “native” apps on the iPhone, but are “originally written” in languages other than C/C++/Objective-C. Details here and here, and there’s also this excellent 37signals post.

Update (4/12/10): Existing iPhone Apps Breaking the TOS

Update (9/10/10): Eventually, Apple updated and relaxed their terms.