4 ms·

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 l

by daeken 17y ago

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.

ubernostrum 17y ago
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.
- daeken 17y ago
  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.
deleted 17y ago
[deleted]
jsz0 17y ago
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?
- wmf 17y ago
  Aren't iPhone apps compiled to LLVM? No, they're compiled to ARM Mach-O binaries.
timdorr 17y ago
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.
- jfoutz 17y ago
  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.
- tlrobinson 17y ago
  AppleApologists.com would be a better name for that site.
tjogin 17y ago
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?
- daeken 17y ago
  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.
- ajg1977 17y ago
  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.
  - tjogin 17y ago
    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).

by daeken 17y ago

ubernostrum 17y ago

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.

daeken 17y ago
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.

deleted 17y ago

[deleted]

jsz0 17y ago

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?

wmf 17y ago
Aren't iPhone apps compiled to LLVM? No, they're compiled to ARM Mach-O binaries.

timdorr 17y ago

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.

jfoutz 17y ago
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.
tlrobinson 17y ago
AppleApologists.com would be a better name for that site.

tjogin 17y ago

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?

daeken 17y ago
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.
ajg1977 17y ago
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.
- tjogin 17y ago
  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).