7 ms·

"Luh was also formerly employed by Apple on the Final Cut Pro team. He said that because Adobe’s Flash Packager didn’t use Apple’s toolchain to create apps, the

"Luh was also formerly employed by Apple on the Final Cut Pro team. He said that because Adobe’s Flash Packager didn’t use Apple’s toolchain to create apps, the resulting code would not work well on an iPhone or iPad. A simple "Hello World" app created in Flash and compiled to work on the iPhone would take up 8 MB, he said, when it should be no longer than a few KB. (Wired.com verified this figure with two other developers who have tested the iPhone Packager tool in CS5.)" 8 MB for a simple binary? Really? That alone is almost enough justification for me. I frequently end up downloading apps directly via my iPhone - a massive increase in download time for no actual gain in value would hurt the experience.

windsurfer 16y ago
I would still rather have a large download than no download. Adding flash wouldn't hurt anything, it would simply enable some more developers into the iPhone space.
- steveklabnik 16y ago
  > Adding flash wouldn't hurt anything Remember that "software decoding + crash problems" bit? It certainly would cause harm. And Apple's not concerned about bringing more developers to the iPhone, they're concerned about bringing _great_ developers to the platform. It's never really been about numbers with Apple, anyway. EDIT: I'm also not saying that Flash developers are bad, and that they shouldn't make things for the iPhone. I'm just saying that Apple's not playing a numbers game, they're playing a quality game. I'm sure Apple would love for all Flash devs to start making apps with Objective C.
- butterfi 16y ago
  meh... I'd pick quality over quantity any day...
  - jarek 16y ago
    Unless you didn't have enough to choose from; that is, you were drastically deficient in quantity.
    - ptomato 16y ago
      That's one thing the iPhone App Store isn't.
- cubicle67 16y ago
  > Adding flash wouldn't hurt anything Not adding it doesn't hurt anything either
hakan 16y ago
That's weird - I see 3.6 MB, not 8 MB, when I click into the article (Apr 30, 3:24 EST): "A simple “Hello World” app created in Flash and compiled to work on the iPhone is substantially larger in file size, and it would take up 3.6 MB when it should be no larger than 400K when made with Xcode, according to James Eberhardt, a mobile developer who has tested iPhone Packager."
- stevenwei 16y ago
  Funny, they must have changed the quote in the past hour or so. 3.6 MB is still pretty bad though :)
Qz 16y ago
It's an edge case. No one is going to be deploying a Hello World App to the App Store. Try comparing code size for similar applications and then we might have something to talk about. Otherwise, this is poor argument.
- probablycorey 16y ago
  Are you saying that a typical Flash app would be smaller, or a typical iPhone app would be larger?
  - Qz 16y ago
    I don't know which would be larger/smaller -- I'm saying that the size of a Hello World App is irrelevant.
    - probablycorey 16y ago
      I think you can safely say any Flash iPhone app is going to be larger than the Hello World app. The only issue in question is how much larger.
      - Qz 16y ago
        Again, the Hello World App is entirely irrelevant -- the question is whether a real world Flash iPhone app will be substantially larger than a native iPhone app that does basically the same thing.
      - statictype 16y ago
        To clarify the point with an example, a one line hello world python script when compiled down to an executable on Windows takes about 7 mb of space because of the runtime payload. But, a more complex 1000 line script wouldn't take up much more space - maybe 7.2 mb
- ptomato 16y ago
  Well, here's a few examples from the apps on my iPhone: Tweetie 2 (very full featured twitter client): 2.8MB Things (todo list manager): 983KB Strategery (game, simple graphics): 6.3MB Canabalt (game, slightly fancier graphics): 8.8MB iOctocat (github browser): 749KB Prowl (internet notification client): 351KB Simplenote (Note taking, iPhone/iPad universal version): 853KB Edit: A cursory run-through of the flash apps listed by Adobe http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/ http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/ indicates that they're all approximately 10-11MB. MTV's South Park Avatar Creator is 9.3MB. Three other avatar creators that seemed similar in the appstore averaged about 6.5MB. Not a very scientific comparison, admittedly.
pavlov 16y ago
The Flash-compiled apps would not be nearly so big if Apple allowed shared libraries to be installed once and loaded dynamically, instead of forcing them to be statically linked into each and every app that uses them, thus bloating app size with redundant code. But that's crazy talk -- it's not like iPhone OS is an Unix with several[1][2][3] well-defined and proven extension mechanisms, or anything... [1] http://developer.apple.com/mac/library/documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html http://developer.apple.com/mac/library/documentation/Develop... [2] http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFBundleRef/Reference/reference.html http://developer.apple.com/mac/library/documentation/CoreFou... [3] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WhatAreFrameworks.html http://developer.apple.com/mac/library/documentation/MacOSX/...
- pederb72 16y ago
  Then Apple would have to trust that Adobe (or other 3rd party library developers) will never introduce regression bugs in their dynamic library, and never break the ABI, otherwise you risk that an update in a library will break lots of existing apps.
  - elai 16y ago
    That is what library versioning is for. One app uses X version, Y app uses another. The worst case scenario is that it would be just the same as the current static library memory usage we have now.
    - pederb72 16y ago
      All risk could be removed if an app could only use a specific version of a library I guess (even a bugfix micro release can introduce regressions). However, adding support for 3rd party libraries would add quite a bit of complexity to the app store, since each app would have to include information about which external libraries it uses, and when downloading an app, iPhone OS would also have to download all the external libraries, if not already installed.

windsurfer 16y ago

I would still rather have a large download than no download. Adding flash wouldn't hurt anything, it would simply enable some more developers into the iPhone space.

steveklabnik 16y ago
> Adding flash wouldn't hurt anything Remember that "software decoding + crash problems" bit? It certainly would cause harm. And Apple's not concerned about bringing more developers to the iPhone, they're concerned about bringing _great_ developers to the platform. It's never really been about numbers with Apple, anyway. EDIT: I'm also not saying that Flash developers are bad, and that they shouldn't make things for the iPhone. I'm just saying that Apple's not playing a numbers game, they're playing a quality game. I'm sure Apple would love for all Flash devs to start making apps with Objective C.
butterfi 16y ago
meh... I'd pick quality over quantity any day...
- jarek 16y ago
  Unless you didn't have enough to choose from; that is, you were drastically deficient in quantity.
  - ptomato 16y ago
    That's one thing the iPhone App Store isn't.
cubicle67 16y ago
> Adding flash wouldn't hurt anything Not adding it doesn't hurt anything either

hakan 16y ago

That's weird - I see 3.6 MB, not 8 MB, when I click into the article (Apr 30, 3:24 EST): "A simple “Hello World” app created in Flash and compiled to work on the iPhone is substantially larger in file size, and it would take up 3.6 MB when it should be no larger than 400K when made with Xcode, according to James Eberhardt, a mobile developer who has tested iPhone Packager."

stevenwei 16y ago
Funny, they must have changed the quote in the past hour or so. 3.6 MB is still pretty bad though :)

Qz 16y ago

It's an edge case. No one is going to be deploying a Hello World App to the App Store. Try comparing code size for similar applications and then we might have something to talk about. Otherwise, this is poor argument.

probablycorey 16y ago
Are you saying that a typical Flash app would be smaller, or a typical iPhone app would be larger?
- Qz 16y ago
  I don't know which would be larger/smaller -- I'm saying that the size of a Hello World App is irrelevant.
  - probablycorey 16y ago
    I think you can safely say any Flash iPhone app is going to be larger than the Hello World app. The only issue in question is how much larger.
    - Qz 16y ago
      Again, the Hello World App is entirely irrelevant -- the question is whether a real world Flash iPhone app will be substantially larger than a native iPhone app that does basically the same thing.
    - statictype 16y ago
      To clarify the point with an example, a one line hello world python script when compiled down to an executable on Windows takes about 7 mb of space because of the runtime payload. But, a more complex 1000 line script wouldn't take up much more space - maybe 7.2 mb
ptomato 16y ago
Well, here's a few examples from the apps on my iPhone: Tweetie 2 (very full featured twitter client): 2.8MB Things (todo list manager): 983KB Strategery (game, simple graphics): 6.3MB Canabalt (game, slightly fancier graphics): 8.8MB iOctocat (github browser): 749KB Prowl (internet notification client): 351KB Simplenote (Note taking, iPhone/iPad universal version): 853KB Edit: A cursory run-through of the flash apps listed by Adobe http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/ http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/ indicates that they're all approximately 10-11MB. MTV's South Park Avatar Creator is 9.3MB. Three other avatar creators that seemed similar in the appstore averaged about 6.5MB. Not a very scientific comparison, admittedly.

pavlov 16y ago

The Flash-compiled apps would not be nearly so big if Apple allowed shared libraries to be installed once and loaded dynamically, instead of forcing them to be statically linked into each and every app that uses them, thus bloating app size with redundant code. But that's crazy talk -- it's not like iPhone OS is an Unix with several[1][2][3] well-defined and proven extension mechanisms, or anything... [1] http://developer.apple.com/mac/library/documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html http://developer.apple.com/mac/library/documentation/Develop... [2] http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFBundleRef/Reference/reference.html http://developer.apple.com/mac/library/documentation/CoreFou... [3] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WhatAreFrameworks.html http://developer.apple.com/mac/library/documentation/MacOSX/...

pederb72 16y ago
Then Apple would have to trust that Adobe (or other 3rd party library developers) will never introduce regression bugs in their dynamic library, and never break the ABI, otherwise you risk that an update in a library will break lots of existing apps.
- elai 16y ago
  That is what library versioning is for. One app uses X version, Y app uses another. The worst case scenario is that it would be just the same as the current static library memory usage we have now.
  - pederb72 16y ago
    All risk could be removed if an app could only use a specific version of a library I guess (even a bugfix micro release can introduce regressions). However, adding support for 3rd party libraries would add quite a bit of complexity to the app store, since each app would have to include information about which external libraries it uses, and when downloading an app, iPhone OS would also have to download all the external libraries, if not already installed.