And for those scoring at home, linking against undocumented APIs was already a huge no-no...
So what does this mean? Well, since Adobe has released an "export to iPhone" feature for CS5, our office has been attempting to port our Flex and AIR concepts over to the iPhone and more recently the iPad. Gruber points out that these apps will be prohibited under the new agreement because they weren't originally written under one of the now blessed Apple languages. Essentially Apple is saying that if you didn't compile using either their chosen framework (Xcode) or a technology so transparent nobody cares (WebKit) ... you can take your ball and go home.
This is moderately huge for Adobe, which has made a large push in having CS5 be iPhone ready. Many in the development community saw this as a kind of compromise - Apple wasn't going to give in when it came to embedded Flash in WebKit (which they would have no control over) but Flash developers could still submit apps in for review and have them posted on the App Store like other apps.
Gruber puts it in more sanguine terms:
On purely technical terms, I can think of one and only one reasonable explanation for this move. I'm a bit rusty on Apple's inner workings, but I believe when an Xcode compiled app is bundled up to Apple for review - Apple can examine the source code. Some developers who have attempted to bury features within their application to avoid review have discovered it isn't quite so simple. A CS5 compiled application may circumvent all of that as the code never existed in a known Apple framework like Cocoa (Obj-C) or Carbon (C/C++). Since WebKit tech isn't compiled, it gets a free pass as well.
Of course - it would seem like allowing developers to submit source code might be a more rational route than simply giving Adobe the one finger salute.
If we look at it from non-technical terms, things get even murkier. Gruber suggests this isn't singling out Adobe, but is creating a boundary specifically at Apple's own framework and hence also exiling MonoTouch and the like. A way to paraphase this angle is that Apple doesn't want to devalue the Cocoa application framework by having other frameworks sail in the same harbor.
I think it is overly kind to suggest that Adobe isn't the main ship down the irons of Apple's cannons, though.
From my perspective - I think Flex and AIR are very capable development frameworks which bridge the gap for many coders between the worlds of native and web applications. AIR, for the record, has many of the same restrictions that a normal web application would have - it just offers decent hooks into certain native level pieces of functionality like notifications, limited file support, and an integrated database. What I think really sucks is that both Adobe and Apple are looking specifically at Flash ... and as I've said many times: Flex is not Flash. AIR is not Flash. They compile to Flash, sure, but they're very different beasts. The iPhone and the iPad could benefit greatly by these technologies by lowering the barrier of entry to creating iPhone apps. The suggestion has been made many times that Apple's main concern with Flash is a potential competitor to iTunes for music and video consumption. OK, fine - but does that mean there is no review process which could allow someone to write a decent data driven app?
If AIR were a viable development option for the iPad, it would give developers a logical three stepped option for coding: purely native in Cocoa/Carbon, compiled web technology with native hooks a la AIR and uncompiled web technology via WebKit.
The kicker is that Apple's actions will only drive more developers to the latter. Which offers a great deal of functionality with HTML5 - but would still lack key integration with components like the iPhone's camera (AIR could provide that with the VM).
Anyway, I think the short, short version is that this sucks. I rather like Objective-C and iPhone development in general, but this feels like a scorched earth policy to maintain a tight grip rather than a positive for anyone but Apple.