Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Collateral Damage in 331

2010, crap, crappstore, iphone, mac

This post is not about whether banning Flash applications on the iPhone is desirable or ethical. As a long-term Objective-C developer, I have no issues with the lack of Flash (transliterated or otherwise) on the iPhone. However, as I noted yesterday the change in the terms is very concerning. As a reminder, the new clause states:

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

Like a chemotherapy, this targets far more than the cancer it is intended to take out and has wide-reaching implications, for iPhone development in general. For example, the statement “must be originally written in Objective-C, C, C++ or JavaScript” leads to many vague interpretations, the strictest of which prevents nearly all development. Quite apart from Objective-C++ being missed from that list (how else do you get C++ code onto an iPhone?), what does “originally written” actually mean? Does it imply that sketches on an iPhone or iPad sized notepaper disqualify an application? What about pseudocode written in python or ruby to test out a game’s AI before being written in Objective-C? The term “originally written” is so vague you could drive a bus through the loopholes this can cause.

The second part … “only code written in C, C++ and Objective-C may compile directly an link against the Documented APIs” seems entirely orthogonal to the next part “e.g. Applications that link to Documented APIs through an intermediary translation or compatibility layer to tool are prohibited”. As an additional example, is this covered by the legal agreement? Normally, the legalese is more strict than this (including, but not limited to…) when citing examplar information. Furthermore, the first part doesn’t prevent indirect linking, though the example stated clearly does desire indirect linking to be captured.

Here’s what would be outlawed for future iPhone development with this new SDK agreement in place:

  • TouchXML As a wrapper for XML processing, including NSXML-like functionality, which links to the Documented APIs. Any application using that is violating the example of “compatibility layer or tool”
  • Unity As a 3D tool, this is used on multiple platforms and can accelerate game development. However, this is a “compatibility layer or tool” which is verboten
  • XML or JSON Any code that uses either XML or JSON as an intermediate format is guilty of writing an application which is not “originally written in Objective-C, C, or C++” as all of these are not languages supported. One could argue the edge case of JSON being a subset of JavaScript (it is JavaScript Object Notation after all) – but you then fall foul of “as executed by the iPhone OS WebKit engine” which the majority of JSON replies don’t. Oh, and goodbye every Twitter, News reader, Buzz client out there.
  • 3D graphics tools Many graphics developers will use a 3rd party tool to do 3D graphics; in the open-source world, Blender is the tool of choice. You can even use Blender to export C code for the models – but goodbye being able to do that, as the generated code is not “originally written in” the specified languages; but rather generated by a “compatibility layer or tool
  • Parsers by Bison/Yacc Sometimes a custom DSL is used to represent state (though these days, mostly the JSON forms are used). However, this is a “compatibility layer or tool” and is verboten under the new guidelines. Goodbye DSLs.
  • Macros The Objective-C language syntax is described without reference to the pre-processor. Any program that uses Macros is going against the spirit of the Objective-C language, and is not found in any of the standard texts on the language. Does this mean macros are verboten too?

The ultimate irony, of course, is that Objective-C started life out as a set of pre-processor statements. The language was built around the concept of macros and macro expansion. That’s how DSLs grow – by exploiting the power of preprocessors to do things that the original language designer didn’t anticipate, including the growth of an entirely new language. If I use an entirely macro-based DSL to generate Objective-C code, am I still writing in Objective-C? Arguably, the compiler will see the same thing, regardless of whether I code it in full or code it with macro definitions. Yet, at some point, the balance of “originally written in” tips the other way.

Too much of this debate has centred around the extreme edge cases – from “Go screw yourself, Apple” to “And so, Adobe, through a mix of incompetence, belligerence and emotionalist hypocrisy…” without actually focussing on the real issue, which is how much of a negative impact of this will cause both from the PR and also the ramifications of the Enterprise aspect.

Although it’s been claimed that these apply to the Apple app store alone, no business in their right minds is going to agree to a set of terms “which Apple might not enforce against Enterprise users”. An agreement is an agreement, that both parties have to hold to. You can’t just ignore parts of it on a vague hope that they’re not going to be enforced. This is particularly true in the case of software licensing, where large fines have been levied on companies who use unlicensed software. Even if there are companies willing to abide by these terms and sell via the AppStore, the damage to the Enterprise market has already been done.

Update: see the follow up post for more insanity in 331