3.3.1

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

The preceding is quoted from Daring Fireball presumably quoting Apple’s new licensing conditions verbatim (I actually haven’t read or signed off on the latest SDK license — I’ve been too busy).

I’m coming very late to this particular discussion, although I’ve commented a few times on Unity 3d’s enormously long forum thread on this same topic. Probably the single clearest explanation of WTF Apple is thinking is in this post (also thanks to Daring Fireball) from Jean-Louis Gassée, former head of Apple’s ATG, and founder of Be Inc.

Here’s my version: Flash, like all cross-platform development tools, is essentially about implementing a fixed feature set on a virtual platform that usually is itself based on a lowest common denominator of the platforms on which it runs. But, unlike Realbasic — which actually tries to find common features between platforms (scrollbars say), Flash is more like Java’s AWT and targets an absolute minimum of features (graphics and audio, say) and then builds out everything from scratch. This means that anything built using Flash adheres to no platform standards whatsoever. (E.g. on the Mac, Flash scrollbars ignore the mouse scroll wheel.)

It follows that cross-platform development tools are all about ignoring the advantages of individual platforms and all about turning hardware into a worthless commodity. Gee, I wonder why Apple might not like this?

But, it gets worse. Adobe, having started out as Apple’s partner has — to its own detriment — scorned the Mac platform and released a succession of inferior products on the Mac, notably Photoshop. (But remember that the as-yet-unreleased Flash 10.1 addresses most of the issues with Flash… in other words, in response to ten years of user complaints and three years of outright hostility from Apple, Adobe has finally fixed a few glaring issues with Flash.)

But, as you might infer from my reference to Unity at the top of this post, Adobe is far from the only (potential) victim of this latest exchange of fire. It would appear that technically, Unity might be affected by this changed clause. More importantly, any finesse which might enable Unity to avoid being so affected is equally open to Flash:

“Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine” — depending on how you read it, Unity or Flash themselves may have been “originally written” in Objective-C, C, or C++, but Unity and Flash apps themselves are written in something else entirely.

“only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs” — is a pretty odd clause because it appears to be unnecessary given the preceding clause — how can I compile and link against an API from a language I’m not allowed to use in the first place? And, in the absence of the previous clause it expressly prevents an app written in some other language from using iPhone OS’s differentiating features. In other words, an app written in C that gratuitously implements a substandard UI from scratch is OK but one written in Lisp or Go that contrives to use the native API to access platform-specific features is not. Why? And how does this benefit end-users or Apple?

Edit: actually, it’s possible that Apple’s real problem is the assumption by third-party tool builders that Apple is going to stick with the ARM platform — e.g. Adobe’s LLVM implementation emits ARM binary. Apple’s long-term commitment to ARM cores can hardly be taken for granted given its various acquisitions, including a PowerPC-oriented chip design company.

It seems to me that the way for Apple to achieve its objectives would be to ban apps that use non-standard UI (and other) widgets without good reason, which gratuitously implement widgets for which native widgets are available, which suffer from poor performance, memory footprint, or power usage for no good reason, and which fail to adhere to various platform standards (and let’s go crazy here and enumerate them). All of these things are actual end-user benefits rather than arbitrary technical or legal requirements.

This would kill Flash far more specifically than the existing legalese, and the way to address it would be to fix the problems in Flash (don’t hold your breath). A developer like Unity Technologies (which has been known to fix problems in sub-Geological timeframes) could address its non-compliance by improving its support for platform APIs and UI widgets. Simply allowing developers to incorporate NIB files and make direct API calls would probably solve 95% of issues and actually make developers’ lives easier too.

  • Andrew Barry

    I’m not sure that Unity is collateral damage here – and similarly if Realbasic was targeting the iPhone/iPod they would also be in Apple’s sights.

    My take is that Apple wants to kill any toolset that has “Compile for iP*” as one option amongst many. They basically want you to either only implement for their platform, or at least make it require a sufficient investment that you’ll be more inclined to take advantage of platform features.

    The linking clause is a bit weird, but I think it’s primarily designed to take out toolkits such as Cider. The language spec there is possibly designed to take out reflection-based bridging – by requiring “direct linking”.

    The whole “must be written in C / C++ / Objective-C originally” clause is rather strong, but presumably they’e taken the position that “nothing good was ever written in another language” and wanted to close the door thoroughly.

    As a tool vendor at heart this clause pretty well destroys any way of writing a development tool, though I can see where they are coming from.

    The unfortunate aspect is that a lot of the apps on the App Store that already comply with this provision are still utter crap.

  • On the whole, even given the interpretation by Gassée’s, this does seem more punitive than practical.

    Jobs seems to tout this clause as a way of reducing the number of “sub-standard apps.” This as a pretty mild hurdle for the writing of sub-standard apps. There are plenty of sub-standard apps out there now that would pass clause 3.3.1.

    http://www.tuaw.com/2010/04/11/steve-jobs-responds-on-iphone-sdks-new-section-3-3-1/

    When Jobs says “ultimately produces [sic] sub-standard apps and hinders the progress of the platform” he’s emphasising “the platform.” My tea-leaf reading is that they have a major system architecture/user interface revamp in the pipeline and have some metric that tells them they’re in trouble for a large population of apps if they don’t immediately clean house.

    Apple built a walled garden on a controlled platform in part so they don’t have to spend combinatorial levels of effort on supporting legacy application and peripheral populations like Microsoft.

    They don’t want to have to burden future iP*’s with legacy compatibility glue, and they need to force a change in app development if they want a future where old apps won’t break on new platforms and won’t require life support from Apple.

    In fact, given how blocky iPhone apps look on the iPad, and how highly valued aesthetic and upgrade experiences are at Apple, it wouldn’t surprise me if the driver for all this is partly Jobs wanting to stamp out this kind of ugly compromise in future platform releases.

    Apple style & UI usage policing would be far more Apple’s style and, like you say, would be a more direct route to the outcome Apple says it wants to achieve.

  • Andrew:

    While I agree Apple is against cross-platform tools in general, Flash is their big target. Unity (et al) aren’t exactly collateral damage, but they weren’t actively annoying Apple.

    Chris:

    My stance is that Apple should stipulate end-user benefits and not the path taken to get there, and that it would be pretty easy to make (most) Flash originated apps disappear with such clauses.

    If one of the end-user benefits is that Apple wants native apps and wants to be able to jump chip architectures whenever it wants to, then toolchains that demonstrate an ability to handle such issues shouldn’t be blocked. Adobe can’t even port its flagship apps to new OSes and architectures in a timely manner, nor have its development tools (all from Macromedia) a tradition of nimbleness to point to. (Realbasic isn’t in good shape here either.) But Unity turns on a dime.

    Bear in mind that PhoneGap has been cleared.

  • Andrew Barry

    I suppose it depends on how much credence you want to put into the supposed emails from Steve Jobs.

    http://www.taoeffect.com/blog/2010/04/steve-jobs-response-on-section-3-3-1/

    Completely different license changes would be directed towards doing anything ensuring chip portability or API changes.

    PhoneGap is a fairly interesting case – inasmuch you wouldn’t use PhoneGap unless you specifically wanted to use capabilities of the iPhone – which is I believe the basis under which it was allowed.

  • Those two emails are interesting but it’s possible that Gruber’s reasoning (linked by Jobs) is merely the overt reason.

    “Completely different license changes would be directed towards doing anything ensuring chip portability or API changes.”

    Prior to the OS X switch to Intel, Apple suggested everyone move to XCode without saying why. Apple may want to get an outcome without making it obvious.

    In the end, my issues with Apple’s changes are practical. There is simply no better way to get solid games up and running on the iPhone than Unity or something similar. Unity supports all the unique features of the iPhone that make sense (accelerometer, multitouch, etc.) — does Apple seriously expect every indie game developer to write their own network stack, 3d library, audio library?

    Apple may end up blessing Unity (and/or similar products) but there’s no way they are allowed under any reasonable reading of 3.3.1. And, in fact, the easiest way to make Unity compliant would be to remove support for iPhone/iPad features!

  • Raphael

    #andrew
    The linking restriction also targets tools like MonoTouch that generate ARM assembler source files (*.s) compiled with a thin obj-C wrapper in a XCode project to generate the final app.

    Apple probably also wants to “encourage” developers to use languages that are actually well suited to embedded application development, especially for iPhone OS 4 where RAM memory management will become much more important than currently thanks to multitasking: iPhones don’t have any swap, if your app is using most of the available memory, the OS will be forced to kill most or all “background” apps to free memory, including things like Skype or Pandora, and users will wonder why that damned phone will not let them recieve calls from Skype as advertised…

    It will reflect poorly on the iPhone if you can’t effectively multitask in OS 4 more than 2 – 3 apps due to large memory consumption from apps.

  • Andrew

    Raphael,

    that is a very good point with regard to minimizing memory usage – which basically throws any garbage collected language out of the ‘pool’. Will be interesting to see if the restrictions are eased as the memory pressures will presumably ease in the coming years.