Linked by Thom Holwerda on Mon 3rd May 2010 23:17 UTC, submitted by PLan
Apple Well, this is interesting, and, I must say, rather surprising: the New York Post is reporting that the US Department of Justice and the Federal Trade Commission are looking into launching an antitrust probe into Apple's policies. You'd expect this to be about iTunes, but that's just the thing: it's about the Adobe-Apple spat. Update: Since I'm not familiar with the entire US media landscape, I was unaware the New York Post is considered less than reputable. Still, Reuters has confirmed the Post's report, so maybe it's true after all.
Thread beginning with comment 422618
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Apple and the rovolution
by clhodapp on Tue 4th May 2010 12:36 UTC in reply to "RE[2]: Apple and the rovolution"
clhodapp
Member since:
2009-12-04

Applications must be originally written in Objective-C, C, C++, or JavaScript
This is a direct targeted attack on all of their competitors. You cannot, with this phrase in the dev agreement, use a flash or c# to iPhone compiler even if the code that it makes uses only Apple-documented APIs to the system.

Edited 2010-05-04 12:37 UTC

Reply Parent Score: 1

cranfordio Member since:
2005-11-10

Actually, that is not correct either. Suppose you write an application that can access the maps API to find addresses, pinpoint your location, etc., what Apple wants is for that program to access those APIs directly, not through some compatibility layer. Basically to get from point A to point B you shouldn't have to go through point C.
Adobe and Mono could write a developer program that makes development easy, that also contains cross platform compilers, but when you compile for the iPhone it accesses the APIs directly and creates the appropriate code that could be edited manually if desired.
The problem is right now if you develop a program using Adobe Flash for the iPhone, you call Flash's instructions from your program, which then calls the Apple API. Apple wants to avoid this. If for some reason they need to change that specific API they could just tell developers to change the affected code and recompile. If developers were using a product like Flash to develop they would have to wait for Adobe to release an update which could be the next day, the next month, or even the next year. Apple doesn't want to be held to another companies update schedule to keep progressing.

Reply Parent Score: 1

Panajev Member since:
2008-01-09

Actually, that is not correct either. Suppose you write an application that can access the maps API to find addresses, pinpoint your location, etc., what Apple wants is for that program to access those APIs directly, not through some compatibility layer. Basically to get from point A to point B you shouldn't have to go through point C.
Adobe and Mono could write a developer program that makes development easy, that also contains cross platform compilers, but when you compile for the iPhone it accesses the APIs directly and creates the appropriate code that could be edited manually if desired.
The problem is right now if you develop a program using Adobe Flash for the iPhone, you call Flash's instructions from your program, which then calls the Apple API. Apple wants to avoid this. If for some reason they need to change that specific API they could just tell developers to change the affected code and recompile. If developers were using a product like Flash to develop they would have to wait for Adobe to release an update which could be the next day, the next month, or even the next year. Apple doesn't want to be held to another companies update schedule to keep progressing.


The problem is that such statement by Apple is too broad.

What if I wrote my OWN portable scripting tool, your step C, and I developed my applications with that tool as I optimized it for multiple platforms?

By those licensing terms my apps built with my own scripting tool would not be allowed.

You say... you cannot use a "step C" to go from A to B... Apple could change its public API's... I think you see the flaw in your reasoning now...

Since I developed "step C" it is fair to give me the burden of updating it to reflect Apple's changes. Even without using my fictitious scripting language I would have to update my app if Apple changed the SDK anyways.

Also, you said:

"Apple doesn't want to be held to another companies update schedule to keep progressing."

Why would they be slowed down by other companies' update schedules? Because of developers' backlash?

The irony here is almost delicious... so, Apple keeps on upsetting developers to avoid upsetting them if they change the SDK and the middleware provider does not update its middleware fast enough?

Even if that were true, and it is not IMHO, it sounds so paternalistic and patronizing to make it quite upsetting.

If a middleware provider does not react to Apple's changes the developers using that provider will bitch and moan to such provider and not Apple.... and such provider will lose its userbase, not Apple.

Also, I am afraid that people are letting their negative feelings for Adobe and their development practices (and the pace they update the Flash player at) into this... this is not just an Apple vs Adobe thing... not unless Apple changing the clause to mention Adobe specifically.

Edited 2010-05-04 14:06 UTC

Reply Parent Score: 1