This news is really just hitting, so there may be many slings and arrows of facts and opinions going around, but it seems like John Gruber's popular Mac blog Daring Fireball picked up on the fact that the new iPhone developer agreement insists that "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". (Daring Fireball / iPhone Developer Program License Agreement).
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?
Honestly, I think both Adobe and Apple are getting it wrong by focusing on Flash over AIR. AIR is far more akin to WebKit development than Flash development. Basically compiled web technology, AIR uses XML and ActionScript instead of HTML and JavaScript. The advantage is that AIR provides a robust component library and the previously mentioned hooks into the native OS (via the VM). Flex is AIR without those hooks, running in an embedded instance.
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.
Posts
4 comments:
It's John Gruber, actually, not James.
Apple can't examine the source, but there are indications in the binary. Actionscript bytecode files that are compiled this way are linked against a whole bunch of Adobe libraries, and there are Flash library strings scattered throughout the file.
If I understand it correctly, and if this is enforced uniformly (not a given), the dev agreement also kills Unity3D on the iPhone. Which is kind of a serious dick move.
I think it's kind of funny that this kills MonoTouch and any other languages that can compile to ARM against the APIs, personally: they've made such a big deal about how much this is for security reasons, and then they're forcing people to use either unmanaged code or JavaScript. Yeah, that's safe. Enjoy those buffer overflows, guys.
Doh, thx - corrected.
Also for consideration is Garage Game's Torque, which I think compiles directly to an iPhone binary.
But right, I don't buy the review excuse, or the security excuse. I don't see how this is anything but herding developers into their ranch. And yup, I'm a big fan of HTML5 development - but there's no way it reaches the same level of stability or security.
Having the App Store as the gateway into the iPhone is one thing - having Cocoa and Carbon as the sole roadway is taking it a bit far.
Huh, some interestingly point out this might pull the Unreal engine onto the chopping block as well. Epic *just* announced Unreal for iPhone at GDC '10. And even more fascinating:
"It helps that Epic has a unique relationship with Apple that allowed the developer access to the core processes of the iPhone, thus enabling use of key element Unreal Script. "
Did Apple just help Epic develop UnrealScript for the iPhone only to go tell them to go f* themselves?
And if not - can they legally stand on such a double standard? UnrealScript is most certainly not Cocoa or Carbon.
Thanks for the article about iphone application. it very nice. I think apple iphone is reaching very quickly in the people.iPhone Website Development
Post a Comment