Sundial Services
Professional Software Engineering Consultants Since 1992

Cross-Platform Mobile Development with Haxe

"Mobile applications" are a necessity these days. Trouble is, when you want to write one, you ordinarily can't write just one. Every mobile platform has its own SDK, its own "favorite (or, only) language," and its own proprietary library suite and APIs. Thus, if you want to build "your app" for iOS and Android, say, you wind up creating two apps that share absolutely nothing with one another except appearances.

Some companies respond to this by doing the same thing they've always done: they build "a web-site in drag." The "app" consists of JavaScript code that runs on a web-browser front end within the phone. And – it shows.

Native applications are always preferable, but traditionally they require totally-redundant development efforts, and the work of specialists who probably know only one platform well. You're not writing one application – you're writing two or more.

Haxe and "Transpiler" Technology:

Haxe, with its companion tool OpenFL (built in Haxe ... like many other such "companions") provide a dramatic improvement on this situation. This is a so-called transpiler technology, which accepts programming in one language (Haxe) and generates source-code in any one of several others: C++, Java, JavaScript, Adobe Flash®, PHP, NekoVM and so on. This generated source-code is then compiled, using the appropriate vendor's SDK, to produce a truly native application.

Partly because of its specific purpose and design, the Haxe language is fundamentally different – and, in our opinion, fundamentally stronger – than most of the languages that you are used to using, such as: Perl, PHP, Ruby, JavaScript, etc. All of these languages are dynamically typed, which means that they consider the "type" of data (integer, string, boolean, and so forth) that they are dealing with, and try to "do the right thing," never actually knowing whether this reflects the programmer's actual deliberate intention. (Visit any commercial web-site today, other than this one, and notice how very-many JavaScript error messages show up in the "console log" of your browser. There's no practical way to discover that an error exists ... until it actually happens.)

Because the Haxe language is designed to generate source-code in a wide variety of languages – both "dynamically-typed" and "strongly-typed" – Haxe is "strongly typed." It requires the programmers to state their intentions more strongly in advance, so that it can detect logic errors (and, "simple tpyos") before they occur. Therefore, "if Haxe produces an output, the odds are quite good that it's correct."

But especially, Haxe is designed to generate source-code in a wide variety of languages and environments. Recognizing that "what you want to say" is the same in each (and every) one, Haxe isolates the language/environment specific issues away from your intentions. And, it detects your "liitle mistkaes" – how very costly such "little mistakes" can be!before they actually happen.

Let's Take a Concrete Example ...

As an example from our own experience, we worked with an educational testing company to make-over their antiquated web application. We redesigned the format of the tests and of the associated on-line study materials to be XML-based, then were faced with the challenge of deploying this new system to the web, to Android-based tablets and to iOS-based tablets, all at the same time. (Schools, in the real world take, and use, what technology they can get.)

Each version of the app had to do basically the same thing: first, to accept test material from a secure back-end server and render it for the student. Then it had to also support a variety of on-line tools – calculators, compass and protractor, periodic table of the elements and so-on. Test progress had to be sent back to the server in real time so that a student could stop and resume work at any time and on any machine. (Batteries do run out, often at the most inopportune times.)

All of these requirements were the same for each platform, but the respective implementations were different. (For example, the web deployment was actually two – one which assumed Flash, the other which assumed HTML5.)

To write three (really, four ...) different applications would have been prohibitive, particularly given the short time constraints and very limited budget. But, Haxe provided an elegant solution which allowed us to construct all three deployments – and the server-side API with which all would communicate – from one Haxe source-code base.

(Plus, Haxe was also able to generate the server-side handler for this API!)

The resulting applications of course did not look exactly the same – we used API components which were native for each platform so that they "looked and felt right" for each one – but the application itself was, to our development teams, "only one application." We could create all of the logic just one time, with only small portions of the Haxe code being specific to any particular so-called "target." We didn't have to reconcile the differences between the platform because the developers of the Haxe packages which we were using had done so for us.

So, What's So Important About "Strongly Typed?"

One of the most important features of the Haxe language is that it is, as we say, "strongly typed." This means that the language requires the programmer to clearly specify exactly what "type" of data a particular variable may contain at a particular time. (Notice also that this concept is very-widely expanded, to include "programmer-defined types" as well.) This enables the language to provide a fundamental service: the "compile-time error."

Digital computers being what they are, "they can't miss anything," provided that you first equip them with the ability to do it. If you build your language – as Haxe did – with a rigorously-defined set of rules that can be enforced by the compiler, these errors will not appear in your production code. Even if the so-called "target" language – such as JavaScript – would have allowed it.

Furthermore, these strictures allow Haxe to produce more efficient output source-code, in any language. Because the programmer has provided more information about his intentions, and because the source-code he provided has been verified at compile-time to conform to it, the output source-code can assume these things, as well.

This notion stands in stark contrast to – well – most programming systems in common use today ... PHP, Perl, JavaScript, etc. ... which are completely permissive about such things as data-typing, and which provide no "compile time" at all. These languages – powerful though they are – completely fail to exploit the digital computer's inherent ability to detect human mistakes at any point sooner than "runtime – the moment when they actually (just) occurred."