Tao Effect

Wow. It looks like someone made a Google Docs spreadsheet of existing iPhone applications breaking the TOS.

Some of these “sub-standard” applications appear to include:

• The popular Rolando 2 for breaking 3.3.1 and 3.3.2 (Lua interpreter)
• Zombieville, #1 in all Games for a while, a Unity3D game (breaking 3.3.1)
• Ravensword: The Fallen King, #1 in Role-Playing at one point, also a Unity3D game.
• Broken Sword, a top-selling RPG game, for apparently using the SCUMM scripting language
• And yes, it turns out that Tap Tap Revenge does indeed violate both 3.3.1 and 3.3.2 for using Lua
• Command & Conquer Red Alert and Star Wars The Force Unleashed both seem to interpret proprietary scripts, violating 3.3.2.

It will be interesting to see how Apple responds to this. If they ignore it, is that essentially a green light to break their TOS, so long as you’re not on their shitlist and your name doesn’t begin with an ‘A’ and end in ‘dobe’?

This type of selective enforcement and hypocrisy does not breed developer loyalty and trust, rather, it fosters animosity and FUD.

Just in case the Google Docs link goes down here’s a mirror: (PDF | XLS).

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.

After posting my reaction to clause 3.3.1 of the iPhone SDK terms I decided to write Steve Jobs the following email:

Hi Steve,

Lots of people are pissed off at Apple’s mandate that applications be “originally written” in C/C++/Objective-C. If you go, for example, to the Hacker News homepage right now:

<http://news.ycombinator.com/>

You’ll see that most of the front page stories about this new restriction, with #1 being: “Steve Jobs Has Just Gone Mad” with (currently) 243 upvotes. The top 5 stories are all negative reactions to the TOS, and there are several others below them as well. Not a single positive reaction, even from John Gruber, your biggest fan.

I love your product, but your SDK TOS are growing on it like an invisible cancer.

Sincerely,
Greg

His response:

We think John Gruber’s post is very insightful and not negative:

http://daringfireball.net/2010/04/why_apple_changed_section_331

Steve

Of course he was right, I had somehow missed that post by Gruber, having only read the original. Gruber’s second post, which Jobs appears to be endorsing here, is indeed, very insightful, and may explain Apple’s motivations for the updates to section 3.3.1.

That said, I did not, and still don’t, consider those reasons to be very good, so I sent a reply in kind:

Sorry. I didn’t catch that post, but I finished it just now.

I still think it undermines Apple. You didn’t need this clause to get to where you are now with the iPhone’s market share, adding it just makes people lose respect for you and run for the hills, as a commenter to that article stated:

“So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage.”

And that makes Apple evil. At least, it does in the sense that Google uses the term in “don’t be evil” – I believe pg translated “evil” as something along the lines of “trying to compete by means other than making the best product and marketing it honestly”.

From a developer’s point of view, you’re limiting creativity itself. Gruber is wrong, there are plenty of [applications] written using cross-platform frameworks that are amazing, that he himself has praised. Mozilla’s Firefox just being one of them.

I don’t think Apple has much to gain with 3.3.1, quite the opposite actually.

Sincerely,
Greg

Within about 3 minutes a second reply graced my inbox:

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.

With replies this short (understandably, of course) I can only guess at his meaning. Perhaps he’s referring to the days when some applications were being written with CodeWarrior and various other build systems. Or maybe he’s referring to the transition from Carbon-based applications to fully Cocoa applications (like Apple’s own Finder), or applications that were written using Macromedia’s Shockwave, or applications written in pure Java or those written in the now-defunct Java-Cocoa bridge. Perhaps it’s a bit of all of these.

Sure, many of the apps written using these systems aren’t very pretty, but can you imagine a Mac without Mozilla’s Firefox? Or a Mac that couldn’t run applications written in Python, Ruby, Java or a myriad of other languages? You would probably consider such a Mac severly handicapped. I don’t believe the existence of these in any way hampers Apple’s ability to progress the Mac platform, to the contrary, they enhance it. The existence of some sub-standard applications should not remove our ability to use those works of art that just so happen to be written without the aid of Apple’s tools.

I have nothing against Apple’s desire to enforce “quality applications”, but there are far better ways of going about it. Mandating that applications be “originally written” using Xcode and the C-based languages is just foolish as it does not magically create quality. What it does do, as I explained previously, is send developers running for the hills, or more specifically, to competing platforms where they have more creative freedom.

Does Section 3.3.1 help Apple in any way?

Gruber makes several claims:

So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage. If, say, a mobile Flash software platform — which encompassed multiple lower-level platforms, running on iPhone, Android, Windows Phone 7, and BlackBerry — were established, that app market would not give people a reason to prefer the iPhone.

And, obviously, such a meta-platform would be out of Apple’s control. Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.

There is truth to this, but I think it’s absurd to think that a third-party toolkit that failed to keep up with Apple’s APIs and produced poor quality apps would ever be popular. Why would users and/or developers willingly choose to use an inferior product? And if they do, so what? No one is forcing you to use them. Further, the vast majority of applications written for the iPhone *have* been written using Apple’s tools, before these changes were made to Section 3.3.1.

Are these imagined advantages worth the consequences?

Many (if not most) developers do not view a company that is blatantly trying to “lock them in” favorably. It is not a virtue that people respect. If I were to write an app for the iPhone, I would choose the tools that I deemed “the best”, voluntarily, and that probably means I’ll use Objective-C and Xcode. But the notion that those are the only tools that I’m allowed to use scares me, and it seems, many others.

The iPhone is the #1 smartphone because people *like it*. They chose it based on the quality of the product itself, and developers flocked to it because of its popularity and its amazing tools. There was no need to lock anyone in, Apple got to where it is on merit, and that’s respectable. Trying to forcibly lock users and developers into the platform is a sign of insecurity.

Everyone fears The Ignorant Boss

For developers, this is the person who knows nothing about programming yet insists that you use X tool and write it in Y language. Now, suddenly, it is as if the formerly independent iPhone developers all have such a boss, and the worst part is that they can’t even communicate with this one. He lives several thousand miles away in Cupertino and isn’t even aware of their existence or anything related to their project.

Gruber goes on to discuss the impact Section 3.3.1 has on the user’s point of view:

I can see two arguments here. On the one side, this rule should be good for quality. Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms.

Ignoring the fact that Gruber is making objective that which is totally subjective, this is just plainly untrue.

One of my favorite applications on the Mac is Mozilla’s Firefox, and certainly my favorite web browser. I think it beats the pants off Safari. As this is not a review of Firefox I won’t get into the details, but I will point out that Firefox is written using a cross-platform software toolkit.

A friend of mine is a musician who thinks the world of Ableton Live (also written using a cross-platform software toolkit), while deriding Apple’s Logic Pro as “lackluster.”

Without question these are all examples of “top-notch” software written using cross-platform toolkits. There are hundreds of others. Much of the software that’s hidden from view and supports the foundations of Mac OS X itself is software that is written using cross-platform toolkits, and all of these are “native” in the sense that they run just as fast as software using the Cocoa frameworks. Some might have widgets that look different, but so do most iPhone games written in accordance to Apple’s rules, should we ban them because of it? That would be absurd and tantamount to software-racism!

I sent a final response to this effect:

The Mac has only been helped by the fact that Firefox, Ableton Live, and hundreds of other high-quality applications can run on it thanks to the fact that developers have a choice as to what tools they can use on it.

Crappy developers will make crappy apps regardless of how many layers there are, and it doesn’t make sense to limit source-to-source conversion tools like Unity3D and others. They’re all building apps through the iPhone developer tools in the end so the situation isn’t even comparable to the Mac where applications can completely avoid using Apple’s frameworks by replacing them with others.

In my opinion, 3.3.1 only serves to make the platform less attractive to legitimate developers, giving them reason to write their software for competing platforms instead.

Thanks for considering this.

Sincerely,
Greg

Apple is free to write whatever absurd rules they want for their SDK, but in doing so, I think the “creative company” is undermining creativity itself, and at its own expense.

The full text of this exchange with headers (sans the final reply), is right here.

Update (4/11/10): Steve Jobs’ Response: A Brief Followup

Update (9/10/10): A few months after this posting, Apple updated and relaxed their terms.

Outrage over this little clause in the new iPhone developer SDK terms is erupting all over the internet:

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

And rightly so.

On our About page we explain why we develop software for the Mac:

We believe that Apple has created an environment where great software can really thrive.

I still feel this way about the Mac, but I no longer consider the iPhone or the iPad worthy of such sentiment because of the draconian terms under which one must operate to develop for those platforms.

What Apple’s engineers have done with the iPhone is amazing. They’ve simply outdone themselves when it comes to the quality of both the software and the hardware. However, I no longer think Apple can continue to honestly claim that they have the best phone around. Steve Jobs and Apple’s legal department have taken a figurative dump on their hard work with these insane restrictions, and that creates an foul odor that stains the product as a whole.

Missing Applications

The new rules, interpreted as written, ban all kinds of applications written by great folks who have put in countless hours of work developing for this platform.

Games developed using the great Unity3D engine are not “originally written” in Objective-C, C, or C++.

The incredible work that James Long put into creating what is probably the first-ever OpenGL game written in Scheme on the App Store, is now thrown into question.

With these terms, Apple is going against its own Think Different model, destroying creativity itself through the enforcement of a monoculture of developer tools. They are effectively saying that you can be creative, so long as you’re creative our way, an absurdity known in psychology as a double bind.

Developers Running Away

The SDK terms are not just insulting, they’re bad business. Great developers like Tim Bray are forsaking the iPhone platform out of disgust and running to Google’s Android platform. Dan Grigsby of Mobile Orchard just announced they’re abandoning iPhone development because of these restrictions.

Despite my familiarity with Apple’s tools and the language Apple insists developers use, at the present time I can’t envision myself writing an app for the App Store, because in clicking that Agree button on the license terms I suddenly find myself feeling like an infant, as though I can no longer be trusted to make basic decisions and must therefore be locked in a crib surrounded by child-proof toys and bars.

For companies like Google, all of this should be good news, because despite its shortcomings, Android’s relatively open platform is starting to look far more inviting.