5 ms·

Flash is a security nightmare. It's a 3rd party application that opens up the device up directly into the OS if compromised. Jobs blocked it because it would

Flash is a security nightmare. It's a 3rd party application that opens up the device up directly into the OS if compromised. Jobs blocked it because it would make iPhone vulnerable to attacks they couldn't control. I don't blame him for blocking it honestly, even though it meant we had totally change tech stacks.

dingo_bat 9y ago
Also, Jobs probably realized flash apps could circumvent his app store model.
- kbenson 9y ago
  The app store wasn't opened until just over a year after the original iphone release (a day before the 3GS was available). Initially, you were supposed to build "web 2.0" apps using the safari engine. Flash didn't work then either.
  - eli 9y ago
    Yeah but certainly they were planning to launch an app store when Jobs penned his open letter on flash. My understanding is they just didn't have the app store and the sdk ready in time.
    - kbenson 9y ago
      > Yeah but certainly they were planning to launch an app store when Jobs penned his open letter on flash. 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...
      - sillysaurus3 9y ago
        This is correct. People were clamoring to write native apps, but Steve tried to deflect them by saying it'd introduce too many security problems. Carmack blasted him publicly, saying that if Apple can't figure out how to secure a unix-based OS then they were incompetent. 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.
        kbenson 9y ago
        I remember a while back (6 months? A year? two?) there was an interesting submission (well explained blog rant) about how saving webapps to the desktop/phone as apps was basically broken, and regressing, IIRC (I apparently didn't favorite it, and I can't seem to find the magic words for search to bring it up), Apple was a primary offender, but Google wasn't perfect either. If I'm remembering correctly, that's a big about face from their stated original intent.
- cakedoggie 9y ago
  This is just silly, jobs allowed and even pushed web apps. You can just as easily circumvent the app store with web apps.
  - code_duck 9y ago
    They forbid language runtimes. Sure, web apps are allowed, but nothing else is if it's freely programmable, including other browser engines.
    - DerekL 9y ago
      That was once true but no longer. Apps in the store can now run interpreted code from anywhere, downloaded, typed in, or bundled with the app. However, they can't implement their own app store outside of Apple's. 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). This bans web browsers with custom engines that run JavaScript, Flash, or Java applets, and it also keeps out alternative app stores. You can display web pages that contain JavaScript, but they have to run inside of the WebKit framework. It seems to allow bundled scripts running on a custom interpreter. 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). Now it says “downloaded OR used”, not AND. So this is even stronger, and prevents an app from containing any amount of interpreted code. It seems to ban lots of games that run an embedded scripting engine. 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. Okay, so game scripts are now legal again, with permission. 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. So now you don't have to ask permission to use bundled scripts. Also, they mention the WebKit framework specifically. Sometime later, iOS exposed JavaScriptCore and made it possible to run downloaded scripts that aren't embedded in a web page. 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). So now downloaded scripts don't have to be JavaScript and don't have to run inside of Apple's interpreter. (The second paragraph doesn't even apply to iOS, because it's not even possible to execute unsigned code.) So now Google and Mozilla can rewrite their iOS web browsers to use their own Blink and Gecko engines, instead of merely wrapping WebKit, though the system will still prevent them from doing JIT compilation. Hell, they could even support Flash if they wanted to. 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_developer_rules/ https://www.theregister.co.uk/2017/06/07/apple_relaxes_devel...
- robmcm 9y ago
  This was such a poor go to argument from Flash developers (I was/am one of them). However in reality this wasn't just about revenue as many assumed (it's a tiny tiny tiny percentage of Apples turn over). The better argument was that Flash, even wrapped in a native container (cordova etc) was insecure, slower and out of their control. Forcing developers to use native toolkits and frameworks produced far better applications as a result. Even today the best apps are still native.

dingo_bat 9y ago

Also, Jobs probably realized flash apps could circumvent his app store model.

kbenson 9y ago
The app store wasn't opened until just over a year after the original iphone release (a day before the 3GS was available). Initially, you were supposed to build "web 2.0" apps using the safari engine. Flash didn't work then either.
- eli 9y ago
  Yeah but certainly they were planning to launch an app store when Jobs penned his open letter on flash. My understanding is they just didn't have the app store and the sdk ready in time.
  - kbenson 9y ago
    > Yeah but certainly they were planning to launch an app store when Jobs penned his open letter on flash. 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...
    - sillysaurus3 9y ago
      This is correct. People were clamoring to write native apps, but Steve tried to deflect them by saying it'd introduce too many security problems. Carmack blasted him publicly, saying that if Apple can't figure out how to secure a unix-based OS then they were incompetent. 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.
      - kbenson 9y ago
        I remember a while back (6 months? A year? two?) there was an interesting submission (well explained blog rant) about how saving webapps to the desktop/phone as apps was basically broken, and regressing, IIRC (I apparently didn't favorite it, and I can't seem to find the magic words for search to bring it up), Apple was a primary offender, but Google wasn't perfect either. If I'm remembering correctly, that's a big about face from their stated original intent.
cakedoggie 9y ago
This is just silly, jobs allowed and even pushed web apps. You can just as easily circumvent the app store with web apps.
- code_duck 9y ago
  They forbid language runtimes. Sure, web apps are allowed, but nothing else is if it's freely programmable, including other browser engines.
  - DerekL 9y ago
    That was once true but no longer. Apps in the store can now run interpreted code from anywhere, downloaded, typed in, or bundled with the app. However, they can't implement their own app store outside of Apple's. 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). This bans web browsers with custom engines that run JavaScript, Flash, or Java applets, and it also keeps out alternative app stores. You can display web pages that contain JavaScript, but they have to run inside of the WebKit framework. It seems to allow bundled scripts running on a custom interpreter. 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). Now it says “downloaded OR used”, not AND. So this is even stronger, and prevents an app from containing any amount of interpreted code. It seems to ban lots of games that run an embedded scripting engine. 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. Okay, so game scripts are now legal again, with permission. 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. So now you don't have to ask permission to use bundled scripts. Also, they mention the WebKit framework specifically. Sometime later, iOS exposed JavaScriptCore and made it possible to run downloaded scripts that aren't embedded in a web page. 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). So now downloaded scripts don't have to be JavaScript and don't have to run inside of Apple's interpreter. (The second paragraph doesn't even apply to iOS, because it's not even possible to execute unsigned code.) So now Google and Mozilla can rewrite their iOS web browsers to use their own Blink and Gecko engines, instead of merely wrapping WebKit, though the system will still prevent them from doing JIT compilation. Hell, they could even support Flash if they wanted to. 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_developer_rules/ https://www.theregister.co.uk/2017/06/07/apple_relaxes_devel...
robmcm 9y ago
This was such a poor go to argument from Flash developers (I was/am one of them). However in reality this wasn't just about revenue as many assumed (it's a tiny tiny tiny percentage of Apples turn over). The better argument was that Flash, even wrapped in a native container (cordova etc) was insecure, slower and out of their control. Forcing developers to use native toolkits and frameworks produced far better applications as a result. Even today the best apps are still native.