4 ms·

Apparently nobody at Apple has the guts to tell Steve that Adobe will just modify their tool to emit Objective C code instead of ARM bytecode. Performance real

Apparently nobody at Apple has the guts to tell Steve that Adobe will just modify their tool to emit Objective C code instead of ARM bytecode. Performance really will suffer when they do that, and Apple won't be able to do anything about it because they won't be able to prove that the Objective C source was generated.

bbatsell 17y ago
Objective-C, when compiled down (with the Apple toolchain, at least), remains a very expressive language. It won't be all that difficult to programmatically detect signs of an Adobe library in the binary. It's how Apple presently checks for use of private APIs (and that has led to the sorts of false positives we've seen in that detection).
- CamperBob 17y ago
  It won't be all that difficult to programmatically detect signs of an Adobe library in the binary There doesn't have to be an Adobe library in the binary. To the extent Adobe would want or need to include standard library code as part of a Flash-generated iPhone app, they'd just compile it as C. Absolutely 100% of the binary code would come from Apple's compiler. There are a dozen trivial workarounds for 3.3.1, and the fact that Jobs apparently doesn't see that is unnerving. Somebody at Apple is feeding him BS.
reitzensteinm 17y ago
They absolutely will be able to tell. When you auto generate code it is going to have a very distinct signature, not to mention common runtime code. All they have to do is get a competent programmer to compile a Flash for iPhone app, disassemble it and build a program that looks for the signature that's run over submitted apps. A few days of work at most every time Adobe releases an update to their iPhone compiler.
- CamperBob 17y ago
  When you auto generate code it is going to have a very distinct signature, not to mention common runtime code A couple thousand Russian worm authors would beg to differ. This is a classic arms-versus-armor battle. Arms will always win.
  - reitzensteinm 17y ago
    I'm talking specifically about Flash generated iPhone apps above, and there is no way Adobe would win that war. Even if they spend millions of dollars changing the generators in an arms race, it'll cost Apple orders of magnitude less to dissect their updates and write a program to flag the apps. Don't forget that Apple has full access to the Flash IDE - they can generate as many Flash iPhone apps as they want, and test out their signature analysis programs until they fit - where as Adobe has absolutely no knowledge of what Apple is doing to detect their generator. Apple has every advantage here. Adobe could put their best guys on it and Apple could defeat them with a single (smart) intern. As for the long tail of code generators, which I wasn't talking about, I just don't think Apple will bother. They know they can't win there, but they don't need to. As soon as one of them gains any sort of popularity (like Unity), they'll cut them down, but until then, a few apps breaking the rules means nothing to them in the big picture.

bbatsell 17y ago

Objective-C, when compiled down (with the Apple toolchain, at least), remains a very expressive language. It won't be all that difficult to programmatically detect signs of an Adobe library in the binary. It's how Apple presently checks for use of private APIs (and that has led to the sorts of false positives we've seen in that detection).

CamperBob 17y ago
It won't be all that difficult to programmatically detect signs of an Adobe library in the binary There doesn't have to be an Adobe library in the binary. To the extent Adobe would want or need to include standard library code as part of a Flash-generated iPhone app, they'd just compile it as C. Absolutely 100% of the binary code would come from Apple's compiler. There are a dozen trivial workarounds for 3.3.1, and the fact that Jobs apparently doesn't see that is unnerving. Somebody at Apple is feeding him BS.

reitzensteinm 17y ago

They absolutely will be able to tell. When you auto generate code it is going to have a very distinct signature, not to mention common runtime code. All they have to do is get a competent programmer to compile a Flash for iPhone app, disassemble it and build a program that looks for the signature that's run over submitted apps. A few days of work at most every time Adobe releases an update to their iPhone compiler.

CamperBob 17y ago
When you auto generate code it is going to have a very distinct signature, not to mention common runtime code A couple thousand Russian worm authors would beg to differ. This is a classic arms-versus-armor battle. Arms will always win.
- reitzensteinm 17y ago
  I'm talking specifically about Flash generated iPhone apps above, and there is no way Adobe would win that war. Even if they spend millions of dollars changing the generators in an arms race, it'll cost Apple orders of magnitude less to dissect their updates and write a program to flag the apps. Don't forget that Apple has full access to the Flash IDE - they can generate as many Flash iPhone apps as they want, and test out their signature analysis programs until they fit - where as Adobe has absolutely no knowledge of what Apple is doing to detect their generator. Apple has every advantage here. Adobe could put their best guys on it and Apple could defeat them with a single (smart) intern. As for the long tail of code generators, which I wasn't talking about, I just don't think Apple will bother. They know they can't win there, but they don't need to. As soon as one of them gains any sort of popularity (like Unity), they'll cut them down, but until then, a few apps breaking the rules means nothing to them in the big picture.