I'd say those apps are hardly native, now, are they? There are several layers between the code you write, and the actual ARM(in most cases) machine code.
I'd say those apps are hardly native, now, are they? There are several layers between the code you write, and the actual ARM(in most cases) machine code.
"Native apps" are ones that have been compiled down to machine code that's directly executable on whatever CPU or CPUs might be provided by the device in question. Ahead-of-time compilation is thus required.
As such, "native apps" cannot be represented solely in a higher-level code that is interpreted, regardless of how its interpreter may be implemented (this includes direct interpretation, JIT compilation, and so on).
Apps built using interpreted JavaScript clearly are not "native" apps, unless we're dealing with hardware that directly executes JavaScript code. The ARM CPUs typically found in smartphones today don't do that.
What you're describing is independent from the concept of "native apps". It's more about platform restrictions than it is about their capabilities. If an operating system like Firefox OS goes out of its way to not support real native apps, that doesn't mean that what it does support are "native" in any way.
I don't know if there's a good term to use instead, but it surely does not involve the word "native" in any way, given that that term already has very specific and existing meaning.
Native apps are often used to describe apps using the platforms own UI toolkit, widgets and API libraries (that is, they look and feel like platform apps and they integrate into the platforms services/notifications/...)
So for FirefoxOS, HTML apps could be considered "native" by this definition.
There might be more layers on Firefox OS than iOS, but I'd take more abstraction layer than write speedy "native" code any day.
For almost all apps, that's unnecessary, but it's there as an option if you really need it.
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.
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.
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.