My ideal cross-platform mobile development framework

Let me state up front that I haven’t yet found an ideal (to me) cross-platform mobile development framework. But let’s see what would it take to have one. Then I’ll take a look at what’s out there and which of those are heading toward that (my) ideal state. If your criteria is different, shoot a comment.



The technology must be open-source. Nowadays only an open-source framework can reach large popularity in the software industry. The reasons are multiple, but fundamentally engineers will only go the extra mile if they can fully understand and influence how a system works.

The project needs those extra miles to increase the quality of the framework (both code and documentation) and get a constant influx of valuable code contributions.

A paywall is the opposite of openness and prevents widespread adoption.


The framework mustn’t have magic under the hood. It should have layers of abstraction and allow engineers to go as deep as required to understand its inner workings and fix bugs. There should be minimal behavioral differences across platforms to enable highly portable skills. Being open source goes a long way towards transparency.

Optional Web support

It’s time we put the Web behind us. The Web today is a hack. The mix of HTML, JavaScript and CSS is trying hard to make us forget that we’re fundamentally working with a document. Think of a Microsoft Word document with lots of customizations to pass as an actual application. You can try it, but it will never pass the uncanny valley.

There are no good solutions to make the Web work with just patching something here and there. Give an engineer one minute with any Web UI and she’ll point out several flaws. It’s either a layout broken by a particular browser DPI, the CSS loading late and the page showing HTML garble, accidentally pressing a select all which makes the page surreal by the text highlighting, the page not fully utilizing the page width, the contextual menu showing out of this world entries for non-engineers (view page source, inspect this item). Give a regular user one minute with any Web UI the he’ll find the same things except he won’t be able to spell out the issues clearly.

The Web has fueled the exponential growth of the computer industry.We should be grateful for that, but it’s time to up the game on the software side. Software engineering can do so much better than HTML/JavaScript/CSS and users can have superior experiences.

Mobile is the first step in that direction. It’s not perfect, but even in its current state is an engineering marvel compared to the Web development model. As soon as the mobile OSs will make it to the desktop the role of the Web will be marginalized. Windows is already there, Android will follow in 2017 and iOS will reluctantly have to as well. Yes, you will still be able to read the newspaper or a blog on the web but for any more complex functionality you’ll prefer an app.

While Web support would be desirable for a cross-platform mobile framework, it shouldn’t be a mandatory requirement.

Historical data

What’s the best cross-platform software development solution to date for frontend and backend software. It’s Java.

The backend and any non-UI Java code works very well on all major platforms. This isn’t accidental though but the result of large investments made by the major players from the software industry of the 90s in making the JVM robust: Sun, IBM, BEA and even Apple (up until JDK 6) just to name a few. Microsoft is the notable exception as the company wasn’t at all happy with Java as it was endangering its PC and server market monopoly. Instead it focused its attention on .NET, a completely parallel ecosystem.

For frontend desktop Java there are two serious UI toolkits: Swing and SWT.

Swing was all about rendering the UI in pure Java and applying themes to match the look and feel of the host operating system. First it failed short on performance when operating systems started using hardware acceleration for rendering the UI widgets. UI rendered by Java simply cannot compete with native UI widgets whose rendering is offloaded to the GPU. Even plain text looked awful and slow because it was font aliasing rendered differently from how the host OS would render it. Secondly Swing failed at platform integration: getting access to things like a file context menu, file actions, native dialogs for file selection and so on. By far the most popular Swing application today is IntelliJ IDEA. It shows Swing at its best, but the UI isn’t perfect. Try a small exercise on MacOS X: right click the code editor and while the pop menu is showing go and open the menu. You’ll end up with something similar to this awkward layout (one is a native menu and the other is a Swing rendered menu):

Screen Shot 2015-12-09 at 10.25.13 AM

SWT was developed for the needs of the Eclipse project. In contrast to Swing, it went with a different approach: it used Java wrappers around natively rendered widgets. Performance was way better, but SWT had to implement the least common denominator widget set. It did however have its own extensive widget set which was developed by composing Java widget wrappers – a good compromise with still excellent performance. The downside was that you had to extensively test your applications looks and behavior on all supported platforms. SWT is still with us today powering the Eclipse IDE, but not much else.

Speaking of Eclipse, another great byproduct of the IDE was the Eclipse Rich Client Platform (RCP). This made it possible to create elegantly designed cross-platform desktop apps. Its limited popularity is due to addressing only the desktop use case and its heavy reliance on OSGi which still didn’t yet get its tooling sorted out (good luck with doing a command line build or integrating with a build system like Maven or Gradle).

My ideal solution

The characteristics of my ideal solution for cross-platform mobile development are:

  1. A uniform execution model across all platforms. I want to have the same runtime and debugging experience on all platforms. Ideally I’d like a virtual machine based execution model but if that’s not feasible then a cross compiled solution might work.
  2. Cross-platform UI option. I want the ability to build a UI as fast as possible.
  3. Platform-specific APIs and UIs. I want the ability to use platform specific features to refine my UI and code. I should have the option to make the UI fully native, should I have more time to spend on the app.
  4. Android as a first class citizen. Android is the dominant mobile OS and has a great potential for displacing Windows to become the dominant desktop OS. It is thus my expectation that the framework shines on Android. This pretty much narrows down the language to Java.
  5. Everything open source. I want to debug as deep as I can inside the code which powers the app. I want to be able to make code contributions to the framework.
  6. (nice to have) Diverse developer community. I want the people behind the project to be engineers from multiple companies, educational institutions and independent engineers. I don’t want a single company to monopolize the project. This excludes a project owned by Google (vested interest in Android), Apple (iOS owner) and Microsoft (Windows proponent).

Elevator pitch

When next time in an elevator and somebody wants to know, I’ll have this project description ready: An open-source Java framework for developing Android apps that are customizable for and executed on both iOS and Windows.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s