Under the Bridge

The Great Section 3.3.1 Debate

So no doubt you’ve observed the great spectacle of frenzy over the infamous Section 3.3.1 (there’s a T-shirt in there somewhere, I know it) of the latest developer agreement:

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

… with reactions from the profane to the pedantic to the metaphysical to the insightful to the whoa, dude.

Rather than weigh in one way or the other on the emo angst surrounding the apparently imminent demise of not only Flash Packager but also Corona and iPhoneWax (Lua), MonoTouch (C#) and theoretically even scriptable engines like Unity, we’d like to draw your attention to the pretty much completely overlooked point of exactly what is explicitly allowed. Specifically, JavaScript.

First observation is that leaving that as an option means you can completely throw out every “it’s all about the money” or “Apple wants to stop cross-platform development” argument immediately. As we’ve mentioned before, HTML5 apps are completely cross-platform, you can avoid the App Store with them, and Apple has gone to a fair bit of trouble to make the offline HTML5 app experience pretty darn close to a native code application experience. So several whole classes of anti-Apple rant are rendered moot right there.

Explicitly blessing JavaScript in this section, though, that seems to imply that frameworks using HTML5 to deploy App Store versions of cross-platform apps is not only tolerated but specifically consecrated. (Given the … fervor … surrounding the issue, religious imagery seems appropriate.) At the very least, it certainly cements the resolve we’ve been mentioning here and there to get familiar with this alternative sooner rather than later. And despite what some commentators are saying, it appears that proudly cross-platform App Store-targeting JavaScript-based frameworks like Titanium and PhoneGap and NimbleKit and Rhomobile [EDIT: Oops, Rhomobile is actually Ruby, they might be out of luck] and other miscellaneous bits are not just allowed, they are actively encouraged.

Indeed, we have word that Apple sees it that way too, at least for PhoneGap:

[ Update:: April 13, 2010 ]

I have received word from Apple that the above is STILL true! If you were concerned by the recent changes to Apple’s iPhone developer agreement, this has ZERO impact on PhoneGap!

Apps built with PhoneGap will continue to be reviewed based on their own merits and NOT dismissed/rejected because they use PhoneGap.

So enough with the crazy speculative rumour mill. Let’s get back to making apps with HTML+CSS+JavaScript.

PhoneGap ftw!

So there you go. You want to develop cross-platform apps, you have one already sanctioned environment and others that look like they’ll probably be deemed equally acceptable to do that. You want to focus on the iPhone, far as I’m concerned Apple is actually doing you a favour by keeping all the Flash gits out of your way. Either way, there is no problem here.

And one last thought for those that are still upset:

If Flash is such a great platform -it’s actually not bad but not that good either- go ahead and develop these killer apps on Android or WinMo7 whenever that comes out. With killer apps being available on competing platforms making a huge difference Apple will simply change the clause and allow you in. They’re not stupid.

Indeed. If you’re absolutely, totally, convinced that this is a bad move on Apple’s part … well you go right ahead and prove that!

  • Pingback: iPhone Apps without Objective-C | akosma software()

  • Thomas

    “App Store-targeting JavaScript-based frameworks like Titanium and Rhomobile and PhoneGap and NimbleKit and other miscellaneous bits are not just allowed, they are actively encouraged.”

    Rhomobile is not a JavaScript-based framework, so they are probably out of luck.

  • http://www.alexcurylo.com Alex

    Ooops … yes, looking closer I see Rhomobile is actually Ruby. Thank you, I’d just lumped all “web-ish” frameworks together as being JavaScript. I’ll fix that.

  • Go screw yourself Apple

    Thankfully Adobe has every right to sue Apple over this. It’s an anti-competitive catch-all clause that can apply to just about any big software development company. Big companies like Electronic Arts / Lucas Arts /Activation have platform abstraction libraries that are made in house and are used for all of their titles. Unless Apple fairly applies this clause then Adobe has every right to sue them. I can’t wait for the blood bath. I hope Adobe bans Apple back 😛 No more Photoshop for OSX Apple! See how that feels! 😉

  • http://rhomobile.com Adam Blum

    Like the other frameworks that followed the Rhomobile Rhodes framework into the space, you can write Rhodes apps entirely in HTML/CSS/JavaScript if you wish. In effect you’d just be writing Views in Rhodes Model View Controller framework (the only MVC for smartphones). If you choose to write Ruby the entire app is translated into a native XCode project in Objective C so that should not be violating either.

  • bosco

    What happened to PhoneGap? Their site, as of this time, is a default GoDaddy parked page? Maybe they just changed hosts, and don’t have their site properly inflated yet…


  • Pingback: OpenAppMkt at Under The Bridge()

  • http://www.douban.com Justa Gordineer

    Throughout this grand pattern of things you secure an A+ just for effort and hard work. Where you confused everybody ended up being in all the facts. You know, they say, details make or break the argument.. And it couldn’t be more correct at this point. Having said that, permit me reveal to you just what exactly did deliver the results. The writing is actually pretty engaging and this is probably why I am taking the effort in order to opine. I do not really make it a regular habit of doing that. 2nd, while I can certainly notice the leaps in reasoning you come up with, I am not necessarily convinced of how you seem to unite your points which in turn produce the actual conclusion. For now I shall subscribe to your position but wish in the near future you actually link the facts much better.