Apple relaxes iOS SDK to allow Lua but block Flash
Apple's iOS SDK rules for iPhone developers have relaxed the restriction of section 3.3.2 pertaining to interpreted code, enabling Apple to forbid Flash and other middleware platforms while still enabling popular game engines and libraries.
When the 3.3.2 rules were first published, the restriction stated that iOS apps must be originally written in Objective-C, C, C++ or JavaScript, and that "no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple?s Documented APIs and built-in interpreter(s)."
Apple's goal seemed to be limited to stopping third parties from shifting iPhone developers from using Apple's own Xcode development tools and instead making them dependent upon their own middleware meta-platforms.
The most obvious example of this was Adobe's efforts to turn its Flash Professional CS5 application into a product that could export iPhone apps, facilitating cross platform development centered on Flash as a platform rather than Apple's own Cocoa Touch.
Apple's 3.3.2 restriction made it clear the company would refuse to sell such apps in its iTunes Store, an insistence the company's chief executive Steve Jobs later explained as an effort to avoid third party middleware from coming between Apple and its developers and slowing down the pace of the iPhone platform's ongoing development.
What about Lua?
However, the wording of the restriction appeared to also target any iOS apps that might include any interpreted code, including a large number of games that make use of general purpose, reusable code engines or libraries to expedite development.
Adobe latched onto this idea to spread fears that any iOS restrictions on development with its Flash tools would also halt the use of popular game engines or libraries such as Unity 3D and Lua. Such a situation would imperil many popular iPhone games that Apple has already approved (and often singled out for targeted promotion), including Tap Tap Revenge and Rolando.
The latest modifications to the 3.3.2 section indicate Apple won't be forced to dump popular, existing titles just to block middleware meta-platforms as a threat to iOS development. The most recent wording of the iOS SDK, published by Matt Drance of Apple Outsider, articulates an additional option Apple can invoke when choosing to approve apps:
"Notwithstanding the foregoing, with Apple?s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application."
Drance notes, "these new terms seem to acknowledge that there?s a difference between an app that happens to have non-compiled code, and a meta-platform."
When the 3.3.2 rules were first published, the restriction stated that iOS apps must be originally written in Objective-C, C, C++ or JavaScript, and that "no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple?s Documented APIs and built-in interpreter(s)."
Apple's goal seemed to be limited to stopping third parties from shifting iPhone developers from using Apple's own Xcode development tools and instead making them dependent upon their own middleware meta-platforms.
The most obvious example of this was Adobe's efforts to turn its Flash Professional CS5 application into a product that could export iPhone apps, facilitating cross platform development centered on Flash as a platform rather than Apple's own Cocoa Touch.
Apple's 3.3.2 restriction made it clear the company would refuse to sell such apps in its iTunes Store, an insistence the company's chief executive Steve Jobs later explained as an effort to avoid third party middleware from coming between Apple and its developers and slowing down the pace of the iPhone platform's ongoing development.
What about Lua?
However, the wording of the restriction appeared to also target any iOS apps that might include any interpreted code, including a large number of games that make use of general purpose, reusable code engines or libraries to expedite development.
Adobe latched onto this idea to spread fears that any iOS restrictions on development with its Flash tools would also halt the use of popular game engines or libraries such as Unity 3D and Lua. Such a situation would imperil many popular iPhone games that Apple has already approved (and often singled out for targeted promotion), including Tap Tap Revenge and Rolando.
The latest modifications to the 3.3.2 section indicate Apple won't be forced to dump popular, existing titles just to block middleware meta-platforms as a threat to iOS development. The most recent wording of the iOS SDK, published by Matt Drance of Apple Outsider, articulates an additional option Apple can invoke when choosing to approve apps:
"Notwithstanding the foregoing, with Apple?s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application."
Drance notes, "these new terms seem to acknowledge that there?s a difference between an app that happens to have non-compiled code, and a meta-platform."
Comments
But the DOJ has a machete.
This is just a natural extension.
Apple has balls.
But the DOJ has a machete.
I'll be surprised if this one resolves against Apple.
But I imagine constant investigations won't trend positive.
Apple does indeed have balls, and loves to walk the line.
Apple has balls.
But the DOJ has a machete.
Maybe the DOJ should use that machete on others. BP comes to mind!
Apple has balls.
But the DOJ has a machete.
Let's hope they ( the DOJ ) know when to use it because this isn't one of those times.
After looking at Flash 10.1 I understand what Jobs has been saying all along about Adobe developers. There's many missing features as compared to Windows. Feature parity (including hardware acceleration) should have been the priority. Keep them out until they understand their responsibilites I say.
Keep in mind the reason for that is because Microsoft has openly worked with Adobe to get Flash to run correctly in Windows. It's not that flash just magically runs better in Windows for no reason. My guess is Apple doesn't want to give Adobe access to the innards of OSX the same way MS did with Windows.
Keep in mind the reason for that is because Microsoft has openly worked with Adobe to get Flash to run correctly in Windows. It's not that flash just magically runs better in Windows for no reason. My guess is Apple doesn't want to give Adobe access to the innards of OSX the same way MS did with Windows.
There's no need to guess. The recent API addition for H.264 encoding is something Adobe has said they have wanted for awhile, but previously they didn't just ask for an API to effect those changes, they wanted direct kernel access, which Apple has refused to provide for good reason. Mac Flash is an extremely poor pile of code compared to the Windows version.
Keep in mind the reason for that is because Microsoft has openly worked with Adobe to get Flash to run correctly in Windows. It's not that flash just magically runs better in Windows for no reason. My guess is Apple doesn't want to give Adobe access to the innards of OSX the same way MS did with Windows.
So because no one at Linux work closely with Adobe, and Adobe doesn't have access to the innards of Linux that's why their Linux port is borderline crap?
Keep in mind the reason for that is because Microsoft has openly worked with Adobe to get Flash to run correctly in Windows. It's not that flash just magically runs better in Windows for no reason. My guess is Apple doesn't want to give Adobe access to the innards of OSX the same way MS did with Windows.
Hogwash, Windows is roughly 90% and MacOS is 10% of the desktop market. So 90% of Adobe's efforts goes into spear heading the Windows version of Flash and 10% of their effort goes into a delayed MacOS version of Flash. Now with the sudden growth of the Apple dominated smartphone/slate mobile market, Adobe finds itself with 90% of their head up Microsoft's sunless cavern. In Adobe's defense though, John Sculley's putrid mutilation of Apple in the 90's left Adobe with no choice but to cater to Microsoft. But I digress.
Hogwash, Windows is roughly 90% and MacOS is 10% of the desktop market. So 90% of Adobe's efforts goes into spear heading the Windows version of Flash and 10% of their effort goes into a delayed MacOS version of Flash.
Yep and they haven't hidden that Flash for Mac is just the windows version in a Mac 'coat'. just like they were trying to do with the iOS apps
Yep and they haven't hidden that Flash for Mac is just the windows version in a Mac 'coat'. just like they were trying to do with the iOS apps
Pretty poor commitment to Apples platforms. A look at the facts leaves no room for doubt of why Apple is done with Adobe, flash in particular.
So because no one at Linux work closely with Adobe, and Adobe doesn't have access to the innards of Linux that's why their Linux port is borderline crap?
Excellent point. If it's just about having access to the kernel then Flash for Linux should be stellar.
Excellent point. If it's just about having access to the kernel then Flash for Linux should be stellar.
I don't think anything can be distilled to that level. I'm sure Adobe cares more about DirectFB on Linux then X Windows.
I like this clarification from Apple. I've always thought that is the way things should be. It is good that they are putting their foot down as far as the applications primary runtime goes. If they didn't do this there may be compatibility problems in the future. Probably something similar to what Apple currently faces with their two runtimes: Carbon and Objective-C. Not to mention that I doubt Adobe cares about things like battery life. Running a different runtime will just slow down app startup that much more too. Running multi-platform UI code is ghetto anyway.
I don't think anything can be distilled to that level. I'm sure Adobe cares more about DirectFB on Linux then X Windows.
I like this clarification from Apple. I've always thought that is the way things should be. It is good that they are putting their foot down as far as the applications primary runtime goes. If they didn't do this there may be compatibility problems in the future. Probably something similar to what Apple currently faces with their two runtimes: Carbon and Objective-C. Not to mention that I doubt Adobe cares about things like battery life. Running a different runtime will just slow down app startup that much more too.
No they would not care about DirectFB on Linux. That's old tech. X is moving far beyond that already.
No they would not care about DirectFB on Linux. That's old tech. X is moving far beyond that already.
DirectFB was never meant to be advanced. I mentioned DirectFB because I know some other smartphones like Nokia use it. I don't think any smartphones run on X Windows because they don't need much of a window server, but I may be wrong.
DirectFB was never meant to be advanced. I mentioned DirectFB because I know some other smartphones like Nokia use it. I don't think any smartphones run on X Windows because they don't need much of a window server, but I may be wrong.
http://wiki.maemo.org/Qt4_Hildon
http://qt.nokia.com/products/platform/maemo
So because no one at Linux work closely with Adobe, and Adobe doesn't have access to the innards of Linux that's why their Linux port is borderline crap?
Borderline?
There's no need to guess. The recent API addition for H.264 encoding is something Adobe has said they have wanted for awhile, but previously they didn't just ask for an API to effect those changes, they wanted direct kernel access, which Apple has refused to provide for good reason. Mac Flash is an extremely poor pile of code compared to the Windows version.
Sounds like you are the one guessing. I'm pretty sure they didn't ask for kernel access. All Adobe was asking for was the same capability as the Quicktime internet plugin, which has hardware accelerated decoding.
Sounds like you are the one guessing. I'm pretty sure they didn't ask for kernel access. All Adobe was asking for was the same capability as the Quicktime internet plugin, which has hardware accelerated decoding.
Adobe was asking for direct access to the hardware - which Apple doesn't allow for anyone else.
No one else seems to have any trouble using the Core functions Apple provides. Why is Adobe the only one too incompetent to program decent apps?