Apple's prohibition of Flash-built apps in iPhone 4.0 related to multitasking | Hacker News Reader

Apple's prohibition of Flash-built apps in iPhone 4.0 related to multitasking

appleinsider.com

77 pointsswombat20 comments

Bullshit. Any software running on the iPhone has to be running in the same way that 'native' apps are, whether or not they're running through an intermediary layer; they interact with the system in the exact same way.

If iPhone applications ran on a layer like the Dalvik VM or .NET, allowing reflection to do things like suspend and restore applications automagickly, this argument could hold water, but we're talking about unmanaged code with no real metadata (outside of the obj-c interface metadata) to speak of. This argument is completely and utterly nonsensical.

If iPhone applications ran on a layer like the Dalvik VM or .NET, allowing reflection to do things like suspend and restore applications automagickly

While I'm not a professional Objective-C developer, I do know enough about the language to know that there's a whole lot of capability in there for reflection and dynamic tricks, which all depends on the Objective-C runtime. Figuring out how to introspect and dynamically freeze/restore a bunch of stuff that's just ARM machine code could well be a bit of a nightmare.

Not nearly enough metadata to do so at runtime reliably, not to mention that they allow C and C++ code which lacks any of this metadata. There is no way in which this makes sense.

I'm not a developer but I have some casual interest in the topic. Aren't iPhone apps compiled to LLVM? Doesn't LLVM include some of these things you mention? or am I way off base?

Aren't iPhone apps compiled to LLVM?

No, they're compiled to ARM Mach-O binaries.

This is an Apple Insider article. They are wrong so often that I get the sense they might just turn into an Apple-focused version of The Onion at some point.

Just without the humor.

i dunno... "The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app."

is pretty darn funny.

AppleApologists.com would be a better name for that site.

I'm not saying the article is right, it's clearly not written by somebody particularly technically savvy.

But, if the code produced by Adobe CS5 and the Apple sanctioned means of developing yields the same result, how could Apple possibly even detect that an app was developed using CS5, Unity3D or some other now forbidden "intermediary" tool?

Strings in the resulting binary, library names in the app package, and other such things. It's very much possible to make it difficult to detect, but with current tools it's trivial.

All of these apps will contain identical portions of code that are either included as a result of, or generated by, those tools. They're effectively like inadvertent watermarks. Once you identify these it's trivial to automatically scan executables and look for those signs.

For something like a flash framework it may not even be necessary to look at the code. Just look at the data files for something that either has a flash header, or a header that's common to that framework.

That sounds very reasonable — with third party development environment like that of CS5, that would be expected.

But how could it detect, say, various libraries that would pre-compile to C/Objective-C — not using a third party development environment with separate libraries like CS5, just direct other language-to-Apple's-environment compilers, like that of Apple's own MacRuby (sort of).

I think what Apple want is for us to use their environment, their libraries, Cocoa Touch and all that. They don't want cross-platform "shovelware" they want apps to be uniquely designed for the iPhone. That's the key. I don't think they really care if the code was written in, say, Ruby or Clojure, using a compiler designed specifically to target Apple's specific libraries. Could they even detect something like that?

I even expect Apple to try to get MacRuby, and similar tools for other languages, working with Mac and iPhone development. It's the generality of cross-compiled generic shovelware they don't like. Not "other" languages.

Think about it: which do you think Apple likes more: cross-platform apps developed "originally" in C using Eclipse (no Apple-libraries) and released for every mobile platform under the sun. Or, apps uniquely designed and developed for iPhone using MacRuby with Cocoa Touch (whenever that's technically possible).

"The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app"

Wow...that is incorrect on so many levels... starting with the fact that it's not possible for Flash authored iPhone apps to run inside a "runtime". The whole trick in CS5 is to compile actionscript and FLA projects into native iPhone apps... The author is little drunk on the koolaid I suspect.

Between that and the several mysterious unattributed appeals to authority, followed by a big apple marketing pitch... is this from a gossip column or something?

> Between that and the several mysterious unattributed appeals to authority, followed by a big apple marketing pitch... is this from a gossip column or something?

We are talking about AppleInsider here...

If this were true, then there would be no problem with languages that compile to C or Obj-C or whatever, which were then properly compiled by Apple's tools. There would be no call for the "Original Language" wording, it could simply say "all apps must be compiled from X" and that would be that.

OMG. The stupid hurts.

Sorry in advance for the meta comment.

I read the article, saved the text "...cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app." to my paste buffer, and came here to rip that argument to shreds.

Two comments, with a combined total of 85 points, already did this. Thank you, HN, for saving me some time :)

The article's reasoning is obviously nonsense. But...

I wonder if there are technical concerns? If AI got this from a real source and just botched his explanation, there could be something there. I'm trying to imagine would it could be...

Perhaps there is a compiler you will be required to use because it structures code in a specific way?

Daniel Eran Dilger always seems to be reaching quite a bit with his Apple conclusions...

I'll believe it when the agreement instead says that developers must, ya know, "conform to the ABI" rather than hocus-pocus language.

Reply on news.ycombinator.com