Apple puts legal knife into Adobe's CS5 - New iPhone Developer Agreement Bans the Use of Adobe’s Flash-to-iPhone Compile

[M A V I C]

deckeda wrote:
You're describing an alternative to what Cydia provides, because what you propose wouldn't see the light of day in the AppStore in the first place. Apple doesn't need to limit the dev tools someone uses in order to reject apps.

If that was the case, they wouldn't need to modify the EULA to restrict it.

[deckeda]

So, an app whose purpose is to be an AppStore alternative would not / could not be denied for only that reason, under the old agreement. Is that it?

[M A V I C]

deckeda wrote:
So, an app whose purpose is to be an AppStore alternative would not / could not be denied for only that reason, under the old agreement. Is that it?

It wouldn't have to be that app's only purpose, and it might not even be apparent when Apple reviews it. So it was more likely that someone could do it under the previous agreement, and get away with it. If a big enough company did it, they could have had a solid legal case against Apple. Now they don't.

[Tulrin]

M A V I C wrote:
[quote=deckeda]
[quote=M A V I C]
[quote=deckeda]
I still don't see how an app created from Flash origins, that necessarily passes through the AppStore like all the rest must, would "create a viable alternative to their AppStore."

It takes a bit of understanding of what all Flash can do and what an "interpretation layer" is.
I'm sorry, break down for me. I do something in Flash, use CS5 to turn it into an iPhone app, then what? The AppStore isn't needed? Bypassed? It's that in-between step I'm lacking here.
If it's not something that you understand, I'd have to give you a big education on how Flash works. I don't have time for that, sorry

silvarios wrote:
I agree with deckeda. You are still making apps for the app store. This has nothing to do with bypassing the app store. Bypassing Apple's absolute control of the development process perhaps, not the app store.

Let me put it this way: just because you can't see how it would work, doesn't mean it wouldn't work. It just means you can't see it. I can see it fairly clearly, but that's probably because I know Flash fairly well.

Research interpretation layers a bit more, and I think you may understand how it would work. All a dev would have to do is create one app (through the app store) that acts as a layer for other apps to run on the iPhone.
You are incorrect. Adobe is not using an interpeter for their iPhone/iPad packager so reading up on interpetation layers is pointless in regards to this subject.

The AIR runtime is created and then run through a packager for the iPhone which then converts it to native code. No interpeter is included... but don't take my word for it, look it up. The Adobe people cover it on several official blogs and on the site as well. Here is a link to Mark Doherty's blog which covers the topic: http://www.flashmobileblog.com/2010/04/0...-os-demos/ You can find others with a simple Google search.

If you were to create your own interpeter and include it in your app you would indeed be violating the EULA (As has been the case from day 1 which is why Java is not supported) however Adobe does not include an interpeter with their iPhone packager. If the Apple Developer EULA forbids any third party tools for app development then of course you would not be able to use Flash to create an app.

One other point, I have read a couple of posts on here in regards to Apple's claim that the Flash player is a memory hog and is inefficient. In recent benchmarks this claim was proven to be false. Apple's motives for not allowing Flash on the iPhone/iPod Touch/iPad have little or nothing to do with performance and have everything to do with their business model.

[Article Accelerator]

Tulrin wrote:
The AIR runtime is created and then run through a packager for the iPhone which then converts it to native code.

Yes--native code that does not exploit iPhone OS APIs. That's the primary problem.

If the Apple Developer EULA forbids any third party tools for app development...

I could be wrong, but it seems to me that the new EULA does exactly that.

One other point, I have read a couple of posts on here in regards to Apple's claim that the Flash player is a memory hog and is inefficient.

Actually, a CPU hog, and a source of reliability and security problems.

Apple's motives for not allowing Flash on the iPhone/iPod Touch/iPad have little or nothing to do with performance and have everything to do with their business model.

How so?

[Tulrin]

Article Accelerator wrote:
[quote=Tulrin]The AIR runtime is created and then run through a packager for the iPhone which then converts it to native code.

Yes--native code that does not exploit iPhone OS APIs. That's the primary problem.
That is neither here nor there in regards to efficiency and reliability. It is some people's opinion that it is however there is no real hard proof to support such a claim one way or another. There are some very effective and efficient applications that use translation layers. Mozilla Firefox is probably the most well-known.

It is a standard practice to decouple applications from APIs in order to reduce the risk of being tightly coupled to an API that is out of developer's control. Strictly speaking decoupling from an API is not the same as a translation layer however it is a similar concept.

Article Accelerator wrote:
[quote=Tulrin]If the Apple Developer EULA forbids any third party tools for app development...

I could be wrong, but it seems to me that the new EULA does exactly that.
It requires that the original code must be written using C, Objective C or C++. It does not forbid third-party tools per se... but that is my reading of it and I am hardly a lawyer.

Article Accelerator wrote:
[quote=Tulrin]One other point, I have read a couple of posts on here in regards to Apple's claim that the Flash player is a memory hog and is inefficient.

Actually, a CPU hog, and a source of reliability and security problems.
True but the CPU claim has also been effectively disproved. Reliability and security "problems" have also been exaggerated or dismissed by both sides with the majority of the discussion being anecdotal. Flash has its problems as does any plug-in and there are those that love it and those that hate it. In reality it is just another tool that makes sense in some situations and not so much in others. Personally I am at a loss as to why people tend to personalize technologies since in the end that only makes one have a more narrow mind. “The best tool for the job” should be the attitude of any developer worth their salt.

Article Accelerator wrote:
[quote=Tulrin]Apple's motives for not allowing Flash on the iPhone/iPod Touch/iPad have little or nothing to do with performance and have everything to do with their business model.

How so?
Apple does not want any other company to define the framework for native iPhone applications. By allowing third-party meta-frameworks Apple runs the risk of one of them becoming the de facto development standard... as would surely happen if Adobe Flash could compile iPhone apps ( There are 2 million plus Flash developers as opposed to 100k plus iPhone developers). Apple would lose control of their own platform. It makes perfect sense from a business perspective and is well within their rights. If developers don't like it they can vote with their feet.

Google's approach is the exact opposite of Apple's so it will be very interesting to see which was a better strategy.

The last time Apple tried a similar strategy it did not play out well for them and is considered one of the great blunders of the technology business world. Apple actively discouraged game developers from porting games to the Mac, a move they ultimately regretted. Perhaps it will work out differently for them this time around, only time will tell.

[Article Accelerator]

Tulrin wrote:
It is a standard practice to decouple applications from APIs in order to reduce the risk of being tightly coupled to an API that is out of developer's control.

And when developers use cross-compilers to do so, they help themselves by easing cross-platform development while harming platforms and platform users by creating sub-optimal applications.

As a user, I don't give a damn about making a developer's life easier if it means that his application will work poorly on my chosen platform.

...the CPU claim has also been effectively disproved. Reliability and security "problems" have also been exaggerated or dismissed by both sides with the majority of the discussion being anecdotal.

To use a favorite Internet retort, I've got your proof and your anecdote right here...

(And frankly my own experience is what I value.)

Apple does not want any other company to define the framework for native iPhone applications. By allowing third-party meta-frameworks Apple runs the risk of one of them becoming the de facto development standard...Apple would lose control of their own platform

Bingo--fscking right it doesn't! So we agree then.

[Tulrin]

Article Accelerator wrote:
[quote=Tulrin]
It is a standard practice to decouple applications from APIs in order to reduce the risk of being tightly coupled to an API that is out of developer's control.

And when developers use cross-compilers to do so, they help themselves by easing cross-platform development while harming platforms and platform users by creating sub-optimal applications.

As a user, I don't give a damn about making a developer's life easier if it means that his application will work poorly on my chosen platform.
Wow, been drinking some Koolaid? Do you drones just repeat whatever Steve Jobs says word for word without a shred of independent thought?

How exactly does a developer using cross-compilers harm a platform?

I am willing to bet there are all sorts of applications that have been created using cross-compilers that you love and have no idea... simple fact is that is the way of the future and as each year passes more and more applications are developed using some sort of translation layer. Get used to it, development any other way is just too cost prohibitive.

If you don't like an app don't use it, simple as that.

[Article Accelerator]

Tulrin wrote:
Wow, been drinking some Koolaid? Do you drones just repeat whatever Steve Jobs says word for word without a shred of independent thought? How exactly does a developer using cross-compilers harm a platform?

Wow--by watering it down at the user-facing level to lowest-common-denominator features, performance, and interface.

I would have thought that would be obvious but, apparently, not so...

Get used to it, development any other way is just too cost prohibitive.

And yet, over 100,000 developers for the touch platform have somehow found a way. Imagine that.

If you don't like an app don't use it, simple as that.

That has always been my policy, Tulrin. Thanks for the advice.

[silvarios]

Why does Adobe Photoshop fail as a Mac and a Windows app? The non native GUI hurts usability on both versions. The situation is even worse on the Mac as the refusal to use Cocoa actually degrades performance and feature integration because of Adobe's grand cross platform development scheme. Ever wonder why 64 bit PhotoShop came first to Windows. Sad really.

I think the concern on the iPhone OS is that Adobe's toolkit will always lag behind the native apps. I suppose Apple should ask Adobe to submit a CS5 compiled app and then run benchmarks against a similarly coded native app. I would be curious of the results.


Nathan