Straight talking – Issue 60

by Tim Anderson

Everybody wants it, but what is native code? Tim Anderson gets to the bottom of this latest trend.

HardCopy Issue: 60 | Published: May 1, 2013

Native code is better. That is a proposition I hear frequently, often from vendors or proponents of particular mobile development tools. I also heard it as justification for a drift away from .NET in the Windows 8 ‘modern’ environment.

Most recently, an Embarcadero marketing person treated me to a lengthy discourse on why the newly released RAD Studio XE4 is the only true native cross-platform development tool for Windows, Mac, iOS and Android. RAD Studio XE4, following less than a year after the release of XE3 in September 2012, is the first release to include Embarcadero’s new ARM compiler, enabling support for iOS. Android support is not ready yet, but it is promised later this year, using the NDK (Native Development Kit) of course.

Funnily enough, Appcelerator also advertises “rich native apps” on its home page, thanks to its Titanium product. Xamarin, offering mobile development in C# for iOS and Android, claims, “Native UI, native performance.” RemObjects, with its Oxygene Delphi-like product, says I can build “awesome native apps for all platforms.”

If you are a developer convinced that native is the way to go, who do you believe?

Time to take a step back. What is native code? Go back 20 years and that was an easy question to answer. There was interpreted code, where a runtime like Visual Basic would execute your code line by line; and there was native code, where a compiler converts your code into a set of CPU instructions called machine code before it is executed.

That simple distinction soon became blurred. Visual Basic 5, in 1997, offered an option to compile to native code, made necessary perhaps by competition from native code Delphi, although the resulting executables still required a runtime which suggested that not everything had gone native. Java and Microsoft .NET came with ‘just-in-time’ compilers, where the runtime compiles the code just before it runs. A hybrid approach is now commonplace, which is why in some cases managed languages perform just as well – or even slightly better, thanks to optimisation – as compiled languages like C++ (though overall performance still tends to be slower).

The same is true of tools like Xamarin and Titanium. The deployment model for mobile platforms is different to that of the desktop since you generally can’t install runtimes other than by compiling any necessary dependencies into the executable – especially on iOS where Apple forbids deployment of a runtime.

Instead what you can do is create a thin native wrapper around the mobile Web browser, in effect using the JavaScript and HTML runtime that comes for free, which is the approach taken by PhoneGap and its open source cousin Apache Cordova. Even there, you can add native code plugins to handle performance-critical code or to access native APIs.

PhoneGap/Cordova don’t claim to be native code. Instead the pitch is that for cross-platform the universality of HTML, CSS and JavaScript – a combination which can be used for Web apps as well as for mobile apps – is unbeatable.

Users rarely ask whether an app is native code. What they care about is performance and usability. Here, though, is another aspect of native code. Never mind the compiler, does the app look and behave like an app that is native to the platform? This is a finely nuanced issue. If it is a game, for example, users will expect a highly customised user interface. Provided it is entertaining and attractive, they will not mind. They may be less tolerant of a forms-based app. It is not only a matter of appearance, but the way the app works: its workflow.

In order to preserve a true native look and feel on all platforms, Xamarin decided that it would not attempt to create a cross-platform framework for the user interface, but only for non-visual code. The trade-off is that you can share less code between platforms, but that each platform gets its own user interface design using true native controls.

Embarcadero, on the other hand, does include a cross-platform user interface framework as part of FireMonkey in RAD Studio. This means you can share much more code between platforms. The trade-off is that while the binary code may be native, the user experience is compromised. A FireMonkey radio button, for example, works fine on Windows, Mac and iOS. That is great, except that on iOS there is no native radio button: instead you are meant to use a picker or a Segmented Control. How do you do a Segmented Control in FireMonkey? An Embarcadero tutorial explains how you can bodge it with a collection of buttons and a special visual style; but while it looks right, it might not work quite the same. Further, once you have done that, it will look odd on other platforms that don’t have a Segmented Control. Should those users put up with an iOS-like user interface, or do you write conditional code or a separate project so they get what they expect, so veering towards the Xamarin approach?

Intel's XDK screenshot

Intel’s free HTML5 developer tool, the XDK (Cross-Development Kit).

In the end, you cannot have a cross-platform toolkit without compromises, especially if you attempt to abstract the GUI – and developers will recall the Java debates about heavyweight versus lightweight controls.

With its new ARM compiler for Delphi and C++Builder, Embarcadero has a good claim to “true native” in respect of the executable code, but not so much when it comes to user interface or user experience.

None of the above is intended to mean that RAD Studio XE4 is a bad choice for mobile development. It has only just arrived on my desk, and while I have not used it long enough to recommend it, I have successfully run up a ‘Hello world’ iOS app, complete with radio button, so it does work; and the fact that developers familiar with Delphi can now build apps for iOS and OS X using a tool they already know is a considerable achievement. Cross-platform never comes for free though; and RAD Studio is no exception.


Intel backs HTML5

Earlier this year, Intel acquired a number of HTML5 developer tools and libraries from appMobi, which it is now promoting as the Intel XDK. There is now an Intel HTML5 developer centre along with free tools and services, including a wizard for getting started with an app, a JavaScript library formerly called jqMobi and now renamed the Intel App Framework, a desktop mobile emulator which runs in Google’s Chrome browser, and a cloud-based build service which lets you wrap your HTML5 code as a mobile app for a variety of platforms, including iOS, Android, Amazon, Nook, Windows 8 and Windows Phone 8. You can also build conventional Web apps that run in the browser.

The XDK emulator supports a range of device sizes, with the most common devices pre-configured. It also emulates the accelerometer, a data connection at various speeds, and location. A button lets you toggle between emulator and editor modes, with the editor providing syntax highlighting. You can also use it in conjunction with your existing preferred editor.

At its recent Software Conference in Paris, Intel’s Thomas Zipplies explained the reason for the initiative: “Intel has high interest in making HTML5 better. We think it is important not to give in to proprietary implementations or extensions of the HTML5 language which prevent HTML5 from running on all sorts of systems.”

That does not sound like a complete answer. Why is Intel, whose software tools mainly cover highly optimised native code for x86 platforms, now becoming an HTML5 advocate?

The answer is probably to do with the industry trend towards mobile devices. PC sales are in decline, which means that the traditional x86 platform (though still large and important) is no longer a growth area. The majority of mobile devices run on ARM processors, which means they are excluded from Intel’s tools.

Intel is determined to increase its presence in the mobile space. New SoC (System on a Chip) products include the 32nm Clover Trail+, with a dual-core CPU and hyper-threading support, providing up to four threads in total; and the 22nm SoC called Merrifield which is aimed at smartphones. Bay Trail, aimed at tablets, is a more powerful Atom SoC, quad-core and using Intel’s own GPU.

If Windows 8 takes off as a tablet operating system, Intel is well placed to benefit since Windows 8 on Intel has fared better in the market than Windows RT, which uses ARM and cannot run existing Windows applications.

Despite these initiatives, Intel is far behind in mobile. The rationale for backing HTML5 tools may be to encourage developers to build apps that will run on any CPU, rather than only on ARM, and to make it easier to port apps between platforms.

The outcome, whatever the rationale, is that the rather good AppMobi library and tools are now available free from Intel. The emulator and build service are useful, particularly as unlike Adobe’s PhoneGap Build service, Intel’s offering is free. The advantage of a cloud-based build service is that you do not need to install the SDKs for the various target platforms locally, or keep them up to date.