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:
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
- 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