Distilling market noise into market sense

VisionMobile is the leading research company in the app economy. Our Developer Economics research program tracks developer experiences across platforms, revenues, apps, tools, APIs, segments and regions, via the largest, most global developer surveys.

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]

  • Pingback: Mobile Analyst Watch()

  • Pingback: Emgenius News ()

  • V

    nice analysis..could you please send us a link to slideshare document.


  • Hi Andreas,

    Nice post, though there are some things that I disagree with:

    – First I didn't get what you meant on whether an AE is meant for 2nd vs 3rd parties: did you mean 'solely' or 'primarily'? For example, you can't say that Symbian is designed 'solely' for 2nd-parties, because there are lots of public Symbian OS APIs (not S60, nor UIQ) that 3rd-parties can use, too. This is the same reason why I can't say if these APIs are 'solely' or 'primarily' for xth-parties.

    – Don't understand, either, how it contradicts who made an AE and whom it's designed for. Let's take Symbian, again, as an example: regardless of that Symbian OS was made by Symbian, I wouldn't say that it's for 2nd-parties only.

    – Who said that the definition of AE designed for 3rd-parties is that it requires basic development skills only? It's ideal, I would say, but not essential.

    – Android's idea about making the whole platform open in terms of being able to replace core applications, too, is nice. But I think we should wait what carriers will say on this and how it will work that the security system will rely on (dummy) user's decisions. The idea is nice on paper, but let's wait how it will work out.

  • V – the link to the slideshare doc is now fixed.

    Tote, good comments, let me clarify:

    – I meant that an AE can be primarily designed for either 2nd or 3rd parties. An AE can't be solely designed for 3rd parties, as 2nd parties will always get involved. However an AE *can* be designed for 2nd parties only (e.g. RTOSes)

    – Symbian OS is a corner case. It was originally designed for 2nd parties, and gradually extended some of its APIs to 3rd parties.

    – AEs designed for 3rd parties can use any language – you 're right, I 'll clarify the wording.

    – Agree entirely on Android and I think I pointed this out on the post; Android may be open, but Android-based phones may be closed to limit OEM/MNO liabilities.

    – Andreas

  • Nice article, but I don't like much the categories.

    As a software engineer communication with the real world is not a feature from Deliver. What you name as Deliver is a list of capabilities, either basic or extended. And it's the main point in order to start studying the rest. I'd call it AE Scope: what the ae can and cannot do.

    Core and downloadable applications can use exactly the same API. Other problem is the developing scope: if you're modifying bluetooth support, or you're just changing the icons and some menus in the default distribution package.

    Outside the core (modified or upgraded) then you have the applications based on what you consider core libraries.

    And the last thing commenting on your trends.

    – Android is a risky platform. Before the last release, the SDK was closed and open only to few privileged human beings. The short and medium term investments are waiting for something more real.

    – iPhone did the opposite. First the phone and then the SDK: "here is the real thingy, now you can think about developing for my platform".

    – JavaScript is a bit dangerous some times if it's used with specific platform extensions. You need to have a clear vision of where you want to get applying that technology into your project. But the future for javascript is quite birght in safari 4 and firefox 3.1 (IE8 has to show it deserves something more than pre packaged compatibility hacks).

    – Mixing BREW and Nokia's Web Runtime: should be forbidden to put them in the same sentence.

    – BREW and Apple Store: comparing printers with bookshops.

    Thats all 🙂

  • Hi,

    The categories of core vs downloadable are based on commercial limitations and by extent technology limitations as well. For example SEMC handsets prior to JP8 don't make it possible for a developer to access the idle screen.

    The core vs downloadable apps impact the user journey differently as I highlight.

    The point you mention about APIs is true, but does not apply to 'sensitive' APIs that in many cases give developers more access to the screen real-estate and system events than the manufacturer feels comfortable with, for both branding and liability reasons.

    Re: BREW and Nokia WRT: they both integrate with device APIs more than the average AE

    Re: BREW and AppStore: Here I was comparing BREW and BDS with AppStore, which is comparing lemons with limes 🙂 They are very well designed B2B2C and B2C channels respectively connecting developers with users.


  • Regina

    Looking forward to hear your comments on newly launched Google's Chrom in the context of Application Environments landscape.


Distilling market noise into market sense

What gets desktop developers out of bed in the morning?

desktop developer segmentation

Despite all the hype around the death of the PC and the enormous amount of media attention focused on mobile,…

Continue reading ...

A proven model for targeting IoT developers


  What if you could identify a handful of developer personas, or segments, each with a very distinct set of…

Continue reading ...

1000 skills: Amazon Alexa as a metaphor for the IoT developer community


Alexa is a centerpiece of Amazon’s Smart Home push, and quickly growing to become one of the most promising attempts…

Continue reading ...


Research on the app economy and developer ecosystems

Developer Segmentation 2014


The Developer Segmentation Q3 2014 report is the most sophisticated study of developer segments to date. The report delivers a…

Continue reading ...

App Profits and Costs


This research report examines the critical success factors for a profitable app, and how business and technology choices, such as…

Continue reading ...

Developer Segmentation 2013

Developer Segmentation 2013

The Developer Segmentation 2013 report delivers a needs-based segmentation model that actually works, with extensive profiling of the eight principle…

Continue reading ...