The future native cross platform UI technology that may not be

Everybody is beating the world wide web horse with respect to cross platform software UI. With so many devices and operating systems on the market today, developers become confronted with a difficult problem, that of choosing which one to develop their applications for. We’ve blogged about this before, recommending the web as a safe and future-proof target, especially for enterprise software user interfaces.

The web is not the only answer

It is unquestionable that native software development brings the best possible user experience for an application. This makes a lot of sense since a platform vendor, such as Apple, Microsoft or Google, will tailor development tools for their ecosystem and capabilities. This is mostly visible in the iOS app world: the popular services such as YouTube and Facebook, are generally accessed through dedicated apps, which are thoroughly optimized and designed for the smartphone or tablet experience. The developers are jumping hoops that are so high as specially designed graphical artwork that goes beyond anything consumers used to experience a decade ago, a characteristic that is enabled by a unified system, a visible marketplace and fierce competition.

The web will have a hard time competing quality-wise with native development and by quality I mean performance and user experience potential. Hardcore web developers will most likely refuse to admit this, but a web browser is a much more restricted environment compared to an operating system. It’s getting better and better, but with the current browser vendors having completely different interests in the web space, I don’t have much hope for fast paced development of the web. It will get stronger, but if you’re looking at the scope of the HTML5 specification, and at the current web browser support, it really doesn’t contain enough to make web apps on par with native ones.

Native means fragmented, but native also means fast

Microsoft is currently the underdog in the modern client platform battle, but their influence is tremendous. The entire IT industry is still dependent on their operating system and office tools. They have an enormous war chest, impressive talent with huge and dedicated developer following. Even though they haven’t lately been able to attract a lot of attention to their platform developments such as Windows Phone 7, they aren’t the kind of company who quits a fight after the first lost battle. Keyboards and mice might be a boring thing of the past, but they still haven’t been replaced by the so called “post-PC devices”. Let’s assume for a moment that tablets are the devices of the future. Even if this would be the case, we are so far from using them instead of PCs that the transition is merely at the beginning. Apple is leading the race, with Android accelerating close behind it, but I doubt they are going to remain the dominant platform for long. Software vendors are also very reluctant to get locked in to a particular platform so the chance of yet another monopoly coming to existence is fairly slim.

If you want to see what a native app behaves compared to a web app, try to open Google Maps on your smartphone’s web browser and then try it on the dedicated app. Repeat the experiment with Facebook. If you were to choose between two software products that offer the same functionality, but one has a native client for your platform, which one would you choose?

Cross-platform native rendering. Dream versus reality

Even though native development is desirable, it’s not actually easy, I would dare to say even possible at this moment, to do it in a cross platform manner. There are some efforts such as Appcelerator Titanium that claim to be “native”, but the only native part is their runtime, which is based on platform components that are exposed through a common wrapper API. They are faking native apps by running JavaScript code which calls native code, but by this logic, web apps are also native since the DOM operations are executed natively by the web browser.

It’s especially difficult to achieve the cross platform crown since Windows Phone doesn’t even allow native code to be executed. This is going to change with Windows 8, because WinRT, the modern application runtime from Microsoft, is going to be exposed to native code as well as to managed code. The implications could be spectacular.

With mobile hardware getting more and more capable, running immersive 3D graphics on a handheld device is no longer science fiction, it’s reality. The really nice thing is that ALL platforms will have the capabilities of running these kind of applications, either through OpenGL ES or some version of DirectX, which although are different, game developers have been writing game engines that work with both for a very long time. Let’s make an imagination exercise: if high-quality 3D graphics can be rendered in real time on more than one platform, why shouldn’t it be possible to render a basic table of information the same way?

iOS has native app support by default, Android has it through NDK and Windows 8 will also have it by default. Rather than reuse UI components from the operating system, it is possible to synthesize cross platform components through native accelerated graphics calls directly, the same way games are drawing their UI. For device-specific functionalities, such as camera, phone book and such, a cross platform wrapper could be developed, the same way PhoneGap does. The main difference of this approach is that applications would be executed natively, with direct and unrestricted access to platform and hardware functionality.

How would a cross platform development framework look like?

One important challenge is the fact that C++ is currently the only mature and well-supported cross platform language for doing native development, which is undesirable to many developers. There are a few contenders, such as D and Go, so a potentially successful native development framework should carefully consider those languages instead of going with the established choice.

This idea is not completely split from reality. The Qt development framework has already made some steps in this direction, which enables seamless C++ and JavaScript integration with native UI rendering on multiple platforms. Recent efforts have been focused on running Qt applications on iOS and Android, which proves the feasibility of this approach. There are some potential issues with Qt, since Nokia might be in a conflict of interest and the licensing of Qt for mobile use cases is quite unclear. I believe there is a short window of opportunity in this space, because not everybody is satisfied with the current choices and a better alternative is not only possible, but it would offer enormous value to those who want to focus on multiple platforms, but still achieve fast performance, concurrency and a compelling user experience.

Conclusion

I hope this article has opened your mind towards alternative future scenarios, since these days everybody seems to be talking about the web (including myself), but to be honest, I don’t expect graphically rich professional-level 3D games to be developed in HTML&JavaScript any time soon. Let’s not forget that games are not the only type of applications which are not well-suited for running in a web browser, there are many more…