Application Environments: Order from Chaos

[Flash, Web Runtime, OSX, widgets, Java engines, Python.. the array of software platforms is chaotic to say the least. Research Director Andreas Constantinou digs deeper into application environments, explains who’s what and identifies 5 clear market trends].

Talk in the mobile industry is often peppered with software mega-brands; Google, Adobe, Microsoft, Linux (see earlier article on the 7 centres of gravity). After a long 7 years since the introduction of smarter mobile phones, software brand names like these are making a splash into the mobile phone scene.

But the array of software platforms for mobile phones keeps growing.. and gets more and more entangled by the month, as new platforms surface. Of particular interest are Application Environments (AEs), the software layer which enables developers to develop, deploy and execute their applications on a mobile phone. Here I attempt to shed some light into the darker corners of the AE space, based on a similar presentation I gave at Informa’s Handsets World conference in Berlin in June 2008. For access to the full presentation see the end of the article.

A very diverse range of application environments is available today:
- Java ME, Flash Lite and BREW  (and their implementations) are the most well known  application environments. Silverlight has made a lot of noise recently as a Flash Lite competitor licensed by Nokia. Microsoft’s .Net compact framework and Red Five Labs’ Net60 are also noteable.
- Google has introduced the much talked about Android operating system which in most part is a well designed application environment for Java SE-like apps.
- decending from the web ancestors, the WebKit core and Nokia’s Web Runtime are also suitable for running lightweight apps with HTML  elements and in some cases access to native device APIs.
- on the scripting front, a diversity of scripting engines exists such as Lua, Bling’s ECMAscript engine, Sun’s JavaFX and ActionMonkey (the merge of Mozilla’s Spider Monkey and Adobe’s Tamarin).
- SVG player vendors like Ikivo and Bitflash are actively evolving their software into application environments for custom operator and OEM applications.
- Smartphone operating systems (Symbian/S60/UIQ, Windows Mobile and OSX) are often portrayed as ‘open’, where in reality they offer  yet another application environment, which exposes (some) phone internals to application developers.
-Linux-based operating systems like MontaVista, WindRiver, PurpleLabs, Azingo and Access ALP all encompass some form of application environment
- traditional real time operating systems (RTOS) also feature proprietary application environments – including Mentor Graphics’ Nucleus, ENEA’s OSE and lesser known OSes like OpenPlug’s ELIPS. Naturally every tier-1 OEM has multiple, proprietary in-house application environments.

Clearly, this makes for a huge choice of platforms to write mobile software with. So who’s who ? who’s what?

Understanding Application Environments
In this post we introduce a basic framework for comparing and contrasting application environments. To start with, AEs have four main properties:
- Develop: open, simplify, manage and support mobile application development
- Deploy: tools and processes for marketing, distributing, installing and monetising from applications
- Execute: the client runtime that interprets or compiles and executes the application; the runtime in many cases ensures interoperability (consistency of execution across devices) and also integration into internal device APIs.
- Deliver: help connect the application to the online world via web, widgets, as well as provide synchronisation and remote management APIs.

Traditionally, the focus of AEs has been on opening the phone to application developers, installing the application and ensuring interoperability across devices (lovingly referred to as write-once-debug-everywhere). Little attention has been paid to critical issues for application developers such as marketing, distribution and device integration (BREW is a bright exception here).

Order from chaos
To make sense of who’s what out of the 50+ application environments we introduce 2 key criteria for AEs:

- whether an AE is designed for 3rd parties (i.e. any developer out there) or 2nd parties (handset OEMs, network operators and their partners). This design goal makes a huge difference to the ease of development, ease of access and overall number of applications.

- whether an AE is designed for core applications (e.g. dialler, idle screen, main menu, inbox, camera, album, mp3 player) or downloadable applications (e.g. games, messaging and VoIP utilities). This design goal makes a major difference in terms of the commercial relationships required, application frequency of use and impact to the user.

The slide below provides more detail.

If we attempt to classify application environments across these two axes (core vs downloadable and 2nd vs 3rd party focus), we end up with the following very interesting chart.

Two key observations emerge:

1. AEs for developing core apps are restricted to 2nd party developers only. This means that innovation for the most critical applications used more often in the phone are available to only a few 100s of software houses forming the inner circle of trusted partners amidst OEMs and MNOs. Conversely, 3rd parties only have access to a limited range of APIs and in most cases no opportunity to write applications with high impact such as addressbook and inbox applications.
2. Android is the first application environment to allow 3rd parties to develop core applications. Google’s OS offers a well thought-out architecture allowing applications to tap into system events (e.g. incoming calls and messages) and access user data. However, the true test of Android’s openness will be in the OEM’s implementation of the phone security policy; it is plausible that an OEM will restrict application rights to a circle of certified (read: trusted) developers in order to manage and mitigate liabilities from the threat of malicious applications.

Wrapping up, there are five clear trends emerging in the evolution of AEs:
- Android is leading the trend to open more parts of the phone to more developers
- the iPhone dashboard is leading the way to simplifying the discoverability of third party applications
- JavaScript and Lua are leading the way for the simplification of the development environment
- BREW and Nokia’s Web Runtime are leading the way for integration of the AE with the device internals.
- BREW and Apple’s AppStore are leading the way for streamlining go-to-market channels and offering financial incentives to application developers.

The next slide offers more detail into these five trends.

Clearly an interesting space to watch. Comments welcome as always.

- Andreas

[a full version of the presentation with additional content is available through Slideshare]

•