What is "Native"?

What is "Native"?

April 25, 2013

As most of you know, I use Appcelerator's Titanium product - a lot. I like it, hell I've written one book and co-authored another on the subject, but I've also tried and developed with various other platforms and languages including Objective-C, jQuery Mobile, Phonegap, Xamarin and Sencha. I was a .NET developer for 10 years, working on everything from software for gym entry systems to banking applications and everything in between. I can write JavaScript, C#, VB.NET, PHP and a bunch of other stuff to varying degrees. I think that I have the kind of experience to weigh in on this "native" vs "non-native" debate that is raging around the mobile developer world.

First of all, let's define just what is "native code":
Native code is code that is executed directly by the machine (CPU).

That's seems to be a pretty clear cut definition, but it doesn't really tell the whole story. Most development these days (and for the 15+ years) has not, strictly, been native code. Instead the predominately common method of creating software is to write applications that compile down to Bytecode. Java compiles down to Bytecode, so does Microsoft .NET (C# and VB.NET languages). Those are probably the two most well known examples, but many other languages, such as Lua and ActionScript, do exactly the same thing. Bytecode can either be translated directly at runtime (often referred to as "JIT" or "Just In Time" compilation) or alternatively can be compiled into native machine code for, and on, specific hardware.

There are very, very good reasons for doing this and those reasons are becoming even more legitimate with the rise in portal computing such as tablets and smartphones. The entire purpose of languages that compile down to Bytecode as so that you, as a developer, only have to write your code once. You do not have to worry about the compilation process for every specific processor your code is going to be executed on. This is a good thing. Can you imagine having to compile code separately for every single Android handset ever released, just because they happen to run slightly different hardware?

And so we move on to mobile development. Below is a list of the major languages / platforms that, as far as I understand by reading their documentation, compile down Bytecode. If I'm wrong on any of them, please feel free to correct me.

  • Java (Android, etc)
  • Microsoft .NET (Windows Phone)
  • Appcelerator Titanium (Android, iOS)
  • Xamarin (Android, iOS)
  • Rubymotion (iOS)
  • Objective-C*(iOS)

The only exception to this list as far as I know, is Objective-C, which can be compiled using either GCC (machine level) or LVVM (bytecode), so it can essentially do both. Apple can get away with this because they control both the software and hardware their platform runs upon. Google's Android platform, on the other hand, does not control the hardware it runs upon hence the reason they predominately run applications built with Java. All of the platforms/languages above are capable of directly accessing the platform specific API's produced for that vendor's operation system. By pure computer science definitions, are they native? Perhaps not, but they are near enough to native that it makes little difference.

Below are a list of platforms that are definitely not native. They compile down to neither Bytecode or machine code (or perhaps some do, partially), but rather there is always an "engine" in-between your app and the CPU. In all common cases, this engine is the web browser and also in the majority of cases, they are paired to a solution such as Phonegap in order to access device hardware.

  • Sencha
  • Kendo UI
  • jQuery Mobile
  • Phonegap

HTML based apps have received a bad rap recently, most notably by Facebook who claimed that HTML5 wasn't ready yet. This has been countered by companies such as Sencha, who say that the reason Facebook failed with HTML5 had little to do with the technology and everything to do with their implementation. The truth as always lies somewhere in-between, and the fault doesn't specifically lie with HTML5 but rather the poor internal browser (called a Webview) implementation by Android and Apple. To be clear, the Internet browser on your phone and the internal Webview browser used for HTML5-based mobile apps is not the same thing.

The waters get muddied even further when you start thinking about new mobile platforms due for release in the near future, such as Firefox OS. Apps for FFOS can only be written in HTML5 / CSS, in principle exactly the same way that WebOS was designed. Does that mean then that any apps written for FFOS will never be native? I don't think so, considering that's the way Mozilla has designed the platform. Does it mean that apps written in Objective-C, as opposed to Rubymotion or Titanium, will always be better? No. Does it mean that apps written with Sencha or Phonegap are going to be worse than their native counterparts? No, not really - but it is more difficult to produce apps on HTML based platforms that feel as fast and capable as other mechanisms. Does an Objective-C app that uses a Webview to display some HTML content mean it's now technically not native, but rather Hybrid - even though 99% of the rest of the code is pure Objective-C? Does it matter?

Perhaps then we need to stop worrying about whether something is technically "native" or not and concentrate on just building good stuff, in the languages and platforms you know best. If you like writing Ruby code, then use Rubymotion. If you like and are willing to properly understand JavaScript, then use Titanium. If you want to write your apps twice (or more) with vendor specific languages and IDE's then go for it. If you think you can wrench the performance and portability required from tools such as Phonegap and HTML5 then use it.

Just build good things.