Speed definitely still matters for everyday apps on mobile devices, because their processors are so much slower than actively-cooled desktops and laptops, and because touchscreens demand a more responsive UI. JIT runtimes have gotten faster, but statically compiling to machine code (especially when link-time optimization is used) cannot be beat for things like application launch performance. And the machine code that Objective-C compiles down to is definitely more native than bytecode for a JIT VM.
Could we start to come to an agreement that maybe "Native" might be a bit of a marketing term? For example a browser rendering HTML and CSS is probably native under the current term. It is not until you get to JavaScript that things need the JIT VM.
There's still objective meaning to the term, even if opinions may differ on what threshold to use for "native". HTML and CSS aren't used to do computation, bytecode and machine code are. So it doesn't make sense to talk about whether HTML and CSS are native or not, only whether the rendering engine is. JITs produce native code, but a lower quality in almost all cases when compared with ahead-of-time optimization, so there's still good reason to make a distinction.
"Native" is not a marketing term, and we shouldn't pretend that it is.
It has a very specific definition in this context, and this definition requires that the application be represented in a form that's directly executable on whatever CPU is being used by the computer executing the application.
Anything that doesn't match that very simple criteria is obviously not a "native" app.
Maybe a new term is needed for describing this type of situation involving Firefox OS. I don't know what that would be, but I do know that we shouldn't go ruining an existing technical term.
Right. If there's bytecode of any sort that needs to be converted to machine code on the fly, then we aren't dealing with a native app.
We wouldn't consider a Java app running on HotSpot on a desktop or server Linux system to be considered a "native app". Thus we shouldn't consider a Java app running on Dalvik on a mobile Linux system to be considered a "native app" either.
Maybe that will change in the Android case if ART and its AOT compilation approach is more widely adopted. But that'll still be some time in the future, if ever at all.
You can actual write in assembler on iOS and use that (sparingly) in your programs, which means there are optionally no layers between you and the CPU.
For almost all apps, that's unnecessary, but it's there as an option if you really need it.
You see a bit of this in game development. At my old job, our engine was written in C++, however we had two copies of our matrix library: one written in C for desktop etc. and one written in ARM NEON asm, for building on iOS or with the Android NDK.
That argument would have more weight if you iPhone apps were distributed as Objective C source code.
They're distributed as ARM binaries. I think the standard definition of "native" is "binary". I would argue that Firefox OS apps are not native, and neither are Android's Java based apps.
That said, I don't think the distinction necessarily matters in practice. I'm excited by Firefox OS--Mozilla tends to do cool stuff.
There might be more layers on Firefox OS than iOS, but I'd take more abstraction layer than write speedy "native" code any day.