Even so, there's a difference between disallowing frameworks and disallowing bindings to other languages. Bindings are relatively simple to keep up to date.
I find it difficult to believe Apple would add a language feature to C/Objective-C/C++ that wouldn't essentially already exist in Java/Python/Haskell/etc. Not because Apple wouldn't be willing to do it, but because there aren't any game-changing language features waiting to be incorporated into modern programming languages. Blocks already exist in most languages as (more powerful) closures.
It's an interesting thing to consider. Take the case of multitasking, where you end up passing a block to be executed as a background task.
I wonder how well that will translate to other languages, which as you say, have similar constructs but perhaps varied differences in scoping rules, memory handling, etc?
Bindings in themselves might be relatively simple to keep up to date, but binding documentation, error handling, etc, are not. Take a look at the Python bindings for Clutter (C graphics library w/Linux roots). Clutter is sponsored by Intel and well-maintained, and yet the Python bindings are several versions behind and the documentation is a mess. In a consistently evolving language and/or framework, every linkage creates delays.
Changes to the iPhone SDK happen around yearly at best. Even vendors such as Adobe can manage a yearly release cycle. Beyond that, why does this need to be in the ToS of the SDK at all? If they only want applications that do a good job of supporting their APIs, then when a new app is submitted for inclusion in the App Store they can say "Hey, your app sucks for multitasking." The concern should be quality of application, not the toolchain used to develop the application.
I suspect that many Flash-to-iPhone conversions would be rejected from a performance, stability, or other perspective, but there are better frameworks (such as Titanium) that play extremely nicely in the ecosystem and can be used to build real, performant applications.
This argument only really flies in my mind if you implicitly accept that Apple is the Font of All Features, and there are No Features but Apple's. If I have an iPhone problem best solved by Erlang, I'm going to be twiddling my fingers for a very long time; there's nothing like it when you need it, and it will be a very long time before they offer anything remotely resembling it if we have to wait for an Apple-Blessed version of the features. (Remember, Erlang is way more than just "green threads", there's a lot of library support, cross-process communication, OTP, etc. Nothing I know truly matches it, few things (but not zero) come close.)
After all, the entire reason that someone wants to use these other languages or frameworks is that they offer features Apple doesn't.
It's still naked self-interest by Apple at the expense of its developers. Which they are welcome to. Frankly, if you knew the history of Apple the company you shouldn't be surprised when they choose to do something in their interest at your active expense; they have a long history of this.
Job's point may be correct, but it is fairly obvious to even a casual observer this is not the real motivation for Apple's actions. From the get-go, Apple has done whatever it can to prevent Flash from getting on the iPhone. The purpose, of course, is to keep development and apps locked into that platform, giving Apple a major competitive advantage.
I don't see much use in all this over-analytical second guessing.
I think the reason there has been so much analysis is that not having Flash on the iPhone affects the end user dramatically, and Apple is all about user experience. If Apple wanted to "keep development and apps locked in that platform", they could do so with their app store and still show Flash content on the browser, in theory, to keep the end user happy. The meta-argument here is twofold, really: 1) Does Apple have the "right", as a business, to ban cross-compilers, which can be very efficient for developers and not necessary lower coding standards, and 2) Does this represent a reckoning for Flash, which has always been CPU-intensive at its own peril, when the GPU was the proper place for its vector calculations, and will Flash/Adobe lose marketshare and CS5 purchases as a result?
"Vendors with slow release cycles (I’m looking at you Adobe) end up creating an additional delay before developers on their platform can take advantage of the latest and greatest features from Apple. This is no good if Apple wants to be on the cutting edge."
The author makes the common mistake of assuming a static market, in which developers on the intermediary platform are permanently fixed to that platform. In a fluid app market, what is the likelihood that those intermediary developers will stay loyal to their platform while developers on Apple's platform eat their lunch?
Even if Apple didn't have a vendetta against Adobe, they would have a strong interest in preventing a flood of ported apps that, regardless of the quality, they simply aren't equipped to deal with given the current App Store workflow.
"The author makes the common mistake of assuming a static market, in which developers on the intermediary platform are permanently fixed to that platform. In a fluid app market, what is the likelihood that those intermediary developers will stay loyal to their platform while developers on Apple's platform eat their lunch?"
I would say it's pretty high, because if they wanted to learn Objective-C and get on the iPhone platform, they already could have. The exact reason so many Flash developers are pissed about this is because they want to use their existing skillsets on the iPhone platform, but can't.
10 comments
[ 7.5 ms ] story [ 35.9 ms ] threadI find it difficult to believe Apple would add a language feature to C/Objective-C/C++ that wouldn't essentially already exist in Java/Python/Haskell/etc. Not because Apple wouldn't be willing to do it, but because there aren't any game-changing language features waiting to be incorporated into modern programming languages. Blocks already exist in most languages as (more powerful) closures.
I wonder how well that will translate to other languages, which as you say, have similar constructs but perhaps varied differences in scoping rules, memory handling, etc?
I suspect that many Flash-to-iPhone conversions would be rejected from a performance, stability, or other perspective, but there are better frameworks (such as Titanium) that play extremely nicely in the ecosystem and can be used to build real, performant applications.
After all, the entire reason that someone wants to use these other languages or frameworks is that they offer features Apple doesn't.
It's still naked self-interest by Apple at the expense of its developers. Which they are welcome to. Frankly, if you knew the history of Apple the company you shouldn't be surprised when they choose to do something in their interest at your active expense; they have a long history of this.
I don't see much use in all this over-analytical second guessing.
"Vendors with slow release cycles (I’m looking at you Adobe) end up creating an additional delay before developers on their platform can take advantage of the latest and greatest features from Apple. This is no good if Apple wants to be on the cutting edge."
The author makes the common mistake of assuming a static market, in which developers on the intermediary platform are permanently fixed to that platform. In a fluid app market, what is the likelihood that those intermediary developers will stay loyal to their platform while developers on Apple's platform eat their lunch?
Even if Apple didn't have a vendetta against Adobe, they would have a strong interest in preventing a flood of ported apps that, regardless of the quality, they simply aren't equipped to deal with given the current App Store workflow.
I would say it's pretty high, because if they wanted to learn Objective-C and get on the iPhone platform, they already could have. The exact reason so many Flash developers are pissed about this is because they want to use their existing skillsets on the iPhone platform, but can't.