[Salty]

With all the bitching Adobe's making why not make an App that's basically the standard webkit browser, but with a flash plugin. People won't by default use it, but if need be could switch to it. It wouldn't come bundled with the iPhone but could be downloaded from the App store.

It would be cumbersome enough to still make people not want to design flash for the iPhone, but usable enough that anyone who truly wants that could browse with Adobe's browser, and could see their battery life plummet. It would also ensure that the blame for all crashes and what not rested solely on Adobe.

[nonhuman]

Because Apple would need to approve it.

[Big Mac]

Adobe wanted to "make an app for that," but Apple would have nothing of it.

[Andy8]

Saw this on Engadget, quite a long interview, but interesting none the less.

Adobe CTO Kevin Lynch: the full interview

[TheoCryst]

The big problem is that Apple doesn't allow apps that execute or interpret external code, and a Flash app would definitely fall into this category. That's also why any third-party web browsers have either (A) used webkit behind the scenes, or (B) done server-side rendering, a la Opera Mini.

[Salty]

Does this mean Microsoft couldn't make an MS word app that could read .doc files? I don't see how it's much different.

[nonhuman]

Originally Posted by Salty 

Does this mean Microsoft couldn't make an MS word app that could read .doc files? I don't see how it's much different.

Code and data are different. Unless we're talking about Lisp...

[FireWire]

I don't get it.. what exactly is "external code"? It seems to me that every app is made of "external", proprietary code? Couldn't Adobe write the code in pure Objective-C? You can't use regular code in iPhone apps? I don't see the difference in the Word exemple.. Microsoft could write an app in iPhone code to interpret Word data, so why couldn't Adobe write an app in iPhone code to interpret Flash data?

[TheoCryst]

The exact text of the agreement:

Originally Posted by iPhone Developer Program License Agreement

An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. 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).

Generally speaking, there is a thin and fuzzy line drawn between executable code and data. Python is executable code, XML is data. Javascript is executable code, HTML is data. But you're right, the distinction is ridiculously subtle. Example: a Word document should be okay, but executing a VBA macro contained therein would not be cool.

I believe Flash falls on the "code" side of this line, because ActionScript (the language used to create Flash content) is interpreted into real, executable code. Meanwhile, a PDF would not violate this, as its markup "language" is only converted to display information that is read by the code included in the app. No new code is created, thus all code being executed is code that shipped with the app.

I'm not arguing that it's fair, but that's the distinction.

[Uncle Skeleton]

Originally Posted by FireWire 

I don't get it.. what exactly is "external code"?

I think a good rule of thumb is that if the "data" is interactive with the user, then it's "code." If you only want flash to play movies (like youtube), then it's "data," but if you want the user to interact with the flash thing (like a game), then it's "code."

Originally Posted by FireWire 

I don't get it.. what exactly is "external code"?

A bit simplistic but basically:

Data tells the device what to do.
Code tells the device how to do it.

So an app can have native objective-C code, to tell the device what to do with data, but it can't have objective-C code to interpret another format of code, that tells the objective-C code what to do with the data.

Clear as mud?