Too bad it isn't used more in the real world - it really is a fantastic prototyping tool.
I forgot about that. Does anyone have any info about this? I didn't pay much attention at the time, but in retrospect it seems like it was one of the main reasons everyone stopped using flash.
Did Adobe try to get Steve to pay a licensing fee, or was he just inherently against implementing flash?
The excuse Steve made at the time was that it was too CPU intensive to run flash. I'm not sure how true this was, except for the earliest iPhone models. I've always wondered what the real reasons were.
It was certainly a good decision in retrospect, but it's an interesting bit of history.
That was almost two years after the opening of the app store, and almost three years after the release of the iphone. I'm unsure whether they really had a fully thought out app store strategy initially, or whether they stumbled into it sort of by accident. Even if an app store was planned, I'm not sure they really knew what to expect. I seem to recall them initially saying you didn't need native apps, and then finally realizing the demand was so great (and performance too poor with Safari) that they needed to open one so scrambled to do so. That may just be a narrative I latched onto and remember though...
I wish I saved the pamphlet that Apple sent to developers during the iPhone 1 era. It was hilarious. It was all about how to use Safari to write webapps. They even highlighted how you could save a bookmark as an icon on your home screen so that your webapp launched like a native app. But of course it was just Safari.
I'm only going to discuss interpreted code. The operating system prevents the execution of any object code that isn't signed by the App Store. The only exceptions are system processes, like JavaScript just-in-time compilation performed by WebKit.
Let me go through the changes in section 3.3.2 of the Apple Developer Program License Agreement. I'm going to skip over some things, because I can't find copies of the very earliest agreements, and I haven't read every single one since.
iPhone SDK Agreement, revised 2008-10-20:
3.3.2 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 and used in an Application except for
code that is interpreted and run by Apple's Published APIs and built-in
interpreter(s).
In 2009-03-17, it was changed to this:
3.3.2 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).
The iPhone Developer Program License Agreement, revised in 2010-06-07, says:
3.3.2 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.
Unless otherwise approved by Apple in writing, 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).
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.
A year later, iOS Developer Program License Agreement (2011-06-06):
3.3.2 An Application may not download or install executable code.
Interpreted code may only be used in an Application if all scripts, code
and interpreters are packaged in the Application and not downloaded. The
only exception to the foregoing is scripts and code downloaded and run by
Apple's built-in WebKit framework.
On June 5th of this year, the Apple Developer Program License Agreement (which applies to both the iOS and Mac App Stores) was revised to:
3.3.2 Except as set forth in the next paragraph, an Application may not
download or install executable code. Interpreted code may be downloaded to
an Application but only so long as such code: (a) does not change the
primary purpose of the Application by providing features or functionality
that are inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store, (b) does not create a store or
storefront for other code or applications, and (c) does not bypass signing,
sandbox, or other security features of the OS.
An Application that is a programming environment intended for use in
learning how to program may download and run executable code so long as the
following requirements are met: (i) no more than 80 percent of the
Application’s viewing area or screen may be taken over with executable code,
except as otherwise permitted in the Documentation, (ii) the Application
must present a reasonably conspicuous indicator to the user within the
Application to indicate that the user is in a programming environment, (iii)
the Application must not create a store or storefront for other code or
applications, and (iv) the source code provided by the Application must be
completely viewable and editable by the user (e.g., no pre-compiled
libraries or frameworks may be included with the code downloaded).
It's funny, but no one has seemed to notice this except for The Register.
https://www.theregister.co.uk/2017/06/07/apple_relaxes_devel...
Even today the best apps are still native.
I'm sure the unstated reasons included that it generally made for poor UX across the web.
Aside from security issues others have mentioned, Early iPhones employed HTML5 as the only 3rd party app API: no flash, no java, not even native Objective C apps. The only reason Apple opened up the Cocoa API to 3rd party developers was because HTML at that time was insufficient for powerful offline experiences (only recently has tools like services workers made deploying offline apps via browser HTML possible). Many would argue Apple's exclusive embrace of modern HTML on its phone was pretty helpful in ensuring HTML5's success accross all platforms.
It was like when the Mac eliminated the floppy drive. Seen as gutsy (or arrogant) at the time, but no one really doubted that's where we were headed.
Had Adobe shown even the slightest sign of responsibility it might have been a different call but at any point after maybe 2002 it was pretty obvious that you shouldn't depend on Flash because Adobe was just milking the customers.
I'm not going to defend the quality of the flashplayer architecture and implementation (due to it's crapness) but it was perfectly fine performance wise - it was a 'resource hog' because of the terrible, terrible code that people wrote for punch the monkey flash apps.
Similarly, the fact that Flash was competitive with IE5 is the problem: browser vendors invested heavily in making that platform faster and richer. Adobe executives thought they had a monopoly and did not.
1. Apple couldn't improve the Flash player like they could with WebKit and Nitro to make Flash content run well on their phones.
2. Most of the complex content on the web was in Flash, by not supporting it the web was fast and light weight for a very low powered mobile device.
If you try and load a JS heavy website on an original iPhone now days it will likely crash.