True Native

Posted by on in Blogs
One would think the meaning of a simple term like 'native' with regard to software applications would be obvious. This term has had a specific meaning since the dawn of software development. Those of us who have been developing software for a while inherently understand this to mean compiled source code that produces a binary to run directly on the CPU; When the OS loads your app, there is nothing between your app and the machine. As such, there are well understood benefits from all software developers around native apps, namely the best performance possible on a device.

However, over the last year or so, I've been noticing the term 'native' thrown around much more loosely when describing all kinds of mobile apps. To some, an app has been described as native if it can simply be downloaded from an app store and launched with an app icon even it consists of just web content. To others, an app has been described as native if it binds a scripting language to some of the OS SDK APIs. I've even seen some describe an app as native if it only calls on the OS to render the user interface controls. While some of these features are characteristics of a native application they all fail to deliver on the true meaning of a native application - ultimate performance with nothing between your app and the device.

You will hear us talk about True Native in this XE4 release (and beyond) to remind software developers of the value of compiled code and to help them understand the real meaning of this term that has been grossly and disingenuously overloaded.  True Native re-captures the meaning of what 'Native' use to mean, compiling your code to a 'native' binary for that device. In comparison to other languages and solutions there is a clear difference. Scripting solutions, like those that use JavaScript, require a runtime language interpreter to convert the source code into machine code. Same goes for Virtual Machines (VM) like those that support the Java and/or C# languages.

The use of a scripting language or VM, in the simplest terms, introduce another layer of software to convert your sources into machine code (typically at runtime) and this presents several compromises for a developer. Some of these compromises include limited tunability and lack of predictability. This hurts your ability as a developer to have full control over the performance of your application and ultimately gets in the way of delivering the best user experience possible on the device. That user experience, judged by end users largely by the performance of the app, has become a paramount concern for most app developers because it is a critical to an app's success. We're not the only ones that believe this.

Facebook came to this conclusion several months back.

“The biggest mistake we made as a company was betting too much on HTML5 as opposed to native."
Mark Zuckerberg - Facebook CEO

"One of the biggest advantages we've gained from building on native iOS has been the ability to make the app fast.
Jonathan Dann – Facebook 2012

And the trend continues:

“The lesson we’ve learnt over the last 12 months has been that the cost in time, effort and testing to bring an HTML5 application to a native level of performance seems to be far greater than if the application was built with native technologies from the get-go.”
Matt Vickers - Xero

“In most cases you really do need a native experience. The feedback we've gotten is that customers want to enhance that (mobile) experience from a native perspective. Therefore, the company found it needed to invest more heavily in native apps, which could provide a better and richer user experience.”
Albert Lai – BrightCove

With RAD Studio XE4, developers can be sure they are getting the best performance possible to deliver the ultimate user experiences on iOS devices, PCs, and Macs, with True Native compiled code and as announced for later this year True Native for Android, too!

Gold User, Rank: 18, Points: 191


  • Page :
  • 1

Check out more tips and tricks in this development video: