APIs Community

What makes up a high-quality API

With third-party APIs, developers can leverage the power of external expertise to enhance the functionality of their applications. However, to ensure success, they must carefully evaluate the quality of APIs before incorporating them into their applications. This chapter aims to investigate the key characteristics that make third-party APIs high-quality, according to developers.

In recent years, application programming interfaces (APIs) have become a key part of modern software development. APIs act as intermediaries that facilitate communication between different applications through established protocols and definitions. By using APIs, developers can leverage the power of other applications without needing custom integrations. In turn, this allows them to focus more on building the core parts of their applications and less on recreating features that already exist or are not feasible.

With this in mind, it is unsurprising that almost all developers (89%) report using APIs in their projects. According to our data, 74% of developers use third-party APIs while 15% state that they only use private or internal APIs. Using private/internal APIs makes it easier for developers to link their in-house applications together and ensures that only authorised personnel can access their systems and internal information. On the other hand, using third-party offerings gives them access to external expertise but introduces additional dependencies that can affect their projects.

high-quality API

74% of developers use third-party APIs

With so many developers relying on third-party APIs to expand the scope of their applications, modern services are becoming increasingly more likely to offer public APIs. However, not all APIs are created equal. Just as high-quality APIs can enhance the capabilities of a given application, adopting a low-quality API can be detrimental to its success. Implementing low-quality solutions can create a wide range of issues such as poor performance, negative user experience, and security vulnerabilities. Therefore, developers must carefully evaluate the quality of APIs before incorporating them into their applications.

In the latest edition of our global developer survey, we asked developers who use third-party APIs to identify the most important characteristics of high-quality API offerings. Our results indicate that developers consider security, documentation and sample code, reliability, ease of use, and performance to be the most important characteristics of high-quality APIs. These five qualities separate themselves from the rest as the core pillars of strength developers look for when considering third-party APIs. In fact, 89% of those who use third-party APIs mention at least one of these characteristics in association with high-quality APIs.​

Security is the most important factor in evaluating the quality of third-party APIs, according to 42% of developers. Using third-party offerings opens up a line of communication with external services that can expose their users to unauthorised access to sensitive data and other security risks. To keep up with the rapidly evolving landscape of threats, developers and modern businesses must ensure that the APIs they use are secure to protect their assets.

Developers consider security to be the most important attribute of a high-quality API

Having access to clear documentation and sample code can make it substantially easier for developers to incorporate APIs into their applications. Our data suggest that 39% of developers consider documentation and sample code to be among the most important qualities in third-party APIs.

These features allow developers to quickly understand the capabilities and limitations that a given API brings and make it easier for them to get started. This goes hand in hand with ease of use, which is mentioned by 37% of developers who use third-party APIs.

On the other end of the spectrum, reliability (38%) and performance (36%) of third-party APIs can directly impact the success of a given project. If an API proves to be unreliable, it can lead to issues ranging from minor errors to system failures and data breaches.

On the other hand, reliable APIs help developers minimise the risk of something going wrong and ensure the highest chances of success in their projects. Similarly, applications can only perform as well as the APIs they use.

Therefore, it is essential for APIs to be fast and capable of handling high volumes of requests to be used in modern applications.

high-quality API

Those who are new to the field of software development tend to work on less challenging problems and can often turn to their peers and mentors for support. As such, they are the least likely (20%) to cite documentation and sample code as an important characteristic of a high-quality API and tend to prioritise other features.

However, as they gain expertise and take on more complex projects, developers begin to appreciate the benefits that clear documentation and sample code bring to the table. In fact, 65% of developers with 16+ years of experience mention documentation and sample code among the most important characteristics of high-quality third-party APIs, surpassing even security (51%).

Highly experienced developers value API documentation and sample code significantly more than beginners

With a greater reliance on self-guided learning, experienced developers become less likely to focus on the community when evaluating the quality of third-party APIs. However, technical issues can arise regardless of experience and may be difficult to resolve or diagnose without expert-level knowledge. In turn, technical support appears to retain its above-average importance for all but the most experienced developers.

high-quality API

With more years of experience, developers gain a deeper understanding of what is essential for their projects. For some, performance may be critical, while others may focus more on ease of use. By focusing on the right characteristics of third-party APIs, developers can enhance the functionality of their applications and deliver better products.

Would you like to contribute to similar findings?

Participate in our latest wave of the Developer Nation survey!

Complete the survey to access our amazing virtual Goody Bag filled with subscriptions, resources, and more!

Sign up for the chance to win prizes, earn loyalty points, and receive updates on survey results and future opportunities.

Take the survey anonymously here

APIs Platforms Tools

Do-it-yourself NLP versus wit, LUIS, or




Alex and I have been building bots for about 1.5 years and have talked to hundreds of bot devs through our BotsBerlin meetup, which now has over 1,000 members. Something we get asked a lot is whether it’s worth investing in building your own NLP engine, or whether it makes sense to use a third party service like, LUIS, or

What does a chatbot’s NLP engine do?

Let’s say you’re building a restaurant bot. These tools will help you take a sentence typed by a human, and turn them into structured data, for example:


NLP Module chatbots


Do you build yours or use third-party tools? Let us know in our DE Survey.

The structure on the right is something computers can actually work with, and you can pass this on to the business logic of your bot. For example, you would probably query the Foursquare API and fetch a list of restaurants. If there are some popular restaurants matching those constraints, you would probably suggest those to your user. If not, you might suggest a Chinese restaurant instead.


Foursquare has already done the hard work of finding matching restaurants, so the trickiest part of building this MVP is finding a way to generate structured data from natural language. The great thing about tools like wit, LUIS, and is that they make this part so easy that you can build an MVP like the above in an afternoon. In our experience, 3rd party tools are an excellent way to build quick prototypes. You could just as quickly build a bot to find videos with the YouTube API, or products from Product Hunt.

Reasons to do it yourself

If your restaurant bot is a runaway success, you will inevitably want to become independent. We see that the more advanced bot teams are all developing their own NLP. Data from the Developer Economics surveys, which polled the opinions of thousands of developers interested in chatbots, are pointing towards a democratisation of chatbots through open source projects (there’s a live survey out now if you want to contribute to this knowledge pool).
Here are three real-life examples of why people switch.

API constraints

databot was a Slack app we built at the start of 2016. Databot would connect your data warehouse to your Slack, so you could ask

what was the ROI like for October’s facebook ads?

and databot would generate the corresponding SQL query and answer your question.

We started off using, which would always default to guessing that October referred to the following October, not the previous one. So we had a lot of fun with our date library to build a workaround. Of course wit could add a feature to let you customise this default, but that’s missing the more general point. If you use an API you are have to live with someone else’s engineering decisions, and that friction tends to grow as your project matures.

Data ownership

We talked to a startup building a commerce bot, specifically one which let you look for presents for friends and family and find good deals, e.g. “my sister likes running and craft coffee and I want to spend around $30”. For them, gathering the data around people’s purchasing intentions is core to the value of their business, and they want to make sure it belongs to them. Moreover, for privacy sensitive verticals like insurance, health, and banking, sending every message to a 3rd party is not an option, users and businesses just aren’t comfortable with it.


Admithub is an education startup. This team actually has one of the most technically advanced NLP modules I’ve seen, it can recognise thousands of intents. Their bot helps university students by updating them about events and deadlines, and can answer questions ranging from “when are housing applications due?” to “can I have a salamander in my dorm room”.

AdmitHub found very quickly that third party tools weren’t up to this task (they tend to optimise for the small data use case, performing well even when a developer is getting started and there are only a few examples). Most also failed to handle misspelled words, which are common when chatting with teenagers. While simple bots are generalizable, sophisticated bots are all complicated in their own way. Every algorithm has trade-offs, and a one-size-fits-all approach can let you down when your use case becomes more advanced.

Bonus: Control your own fate

Ultimately, technological independence is compelling for many teams. It’s great to use free tools developed by big tech companies, but they may not stay free (Microsoft have started charging for LUIS) and they may disappear with little notice (like Parse did).

The rise of do-it-yourself NLP

{wit,LUIS,api}.ai are wonderful tools that make prototyping very quick. But from talking to dozens of bot teams, I’m convinced that everyone will eventually become independent. Early indications from the state of AI survey are that virtually all businesses are uncomfortable relying on APIs for their AI, and that doesn’t surprise me given the examples I’ve just talked about. The engineering case is that web APIs just aren’t the solution to every problem in programming. The business case is that you really want to own your data and be independent.

In 2017 we will see the bots that have traction moving away from 3rd party NLP services. The biggest drawback, until now, has been the engineering investment and machine learning talent required to build a custom NLP engine. It makes no sense every bot team to reinvent the same things, so at LASTMILE we decided to open source ours. You can find out more at


Are you involved in ML and/or AI? Take the Developer Economics Survey and shape the future of ML/AI development.


4 + 2 tools for a happy multi-cloud developer

It is exciting to be a developer these days. You’re the talk of the town and everyone looks for ways to make you happy, competing to create new tools or new services just for you. Developing a great app in such a mesh of services shouldn’t be an issue. Still, this often proves to be a daunting task. Just like the last time you wished to deploy in the cloud and there were 15+ various different services you had to consider.


– OK, so what is the problem? Having many alternatives is good … Right?

Well, that depends…. Here’s an example…
Let’s take the app we just talked about. To develop an app for cloud “X” you will need to download the SDK or Toolkit of that cloud and start writing code to use it. But what happens if you wish to switch to another provider? In case you want to change to cloud “Y”, you will need to download the toolkit for the new cloud. Cloud “Y”’s toolkit in turn has its own structure, syntax and design.

What can you do?
1. Stay on the same cloud…
2. Switch to another cloud. That is: Remove the old cloud code; download the toolkit of the new cloud; understand how it works; learn its particulars and re-design your app around it. Quite complicated, isn’t it?

It is clear that switching to another cloud provider is becoming difficult. Should you stay or should you go? This problem can be solved by two ways: standardization or 3rd party tools.

There are currently two organizations competing to come up with a standard for all cloud providers. These two standards are the CIMI / Cloud Infrastructure Management Interface and the OCCI / Open Cloud Computing Interface. The problem is that neither CIMI or OCCI are very widely used – instead of standardising, providers are increasingly coming up with their own APIs. Which leads to the 3rd party tools solution.

Cloud providers offer REST APIs for their services, but these often differ at the details. Cloud libraries or multi-cloud toolkits try to fix this by offering an abstraction layer over these services, allowing interaction with various cloud providers. They hide away their differences, provide one view and a unified API and eventually make moving between cloud providers easier. With their help, you can avoid getting stuck with one vendor. You only have to download the toolkit and write the code to use its API, which in turn will communicate with the cloud services. To switch to another cloud, you will not need to download another SDK or toolkit. You simply need to write some code (which is what you do anyway) to “talk” to both clouds.

What is out there?
There are several open-source, multi-cloud toolkits that you can use in your projects. Which to select largely depends on your coding language, cloud provider and service you need to work with. There are 4 main types of services supported by these toolkits:

  1. Compute nodes (Start / Stop instances or configure)
  2. Data Volumes (Creating / Attaching / Delete volumes, snapshots etc.)
  3. Load Balancers
  4. DNS

Note that not all providers are supported or willing to hand you over all the above four functionalities. To choose therefore the tool that best fits your needs, you need to do some homework.

To understand why you need to do any homework, let’s consider an example.

Assume you want to deploy and integrate your application and you only have to select between Amazon AWS and Microsoft Azure. Which are the best tools for you?

Apache Libcloud – Python

In 2009, Cloudkick created a SaaS cloud monitoring and management platform as a means of “talking” to many different providers. That early version of Cloudkick was later released as an open source Apache project and was finally acquired by Rackspace and replaced by Rackspace Cloud Monitoring.

Libcloud is a library that abstracts the differences between cloud providers. It allows you to manage different cloud resources through a unified and easy API. It is an open source project with a single Python interface of 35+ cloud providers and their services. Below is a list of the features and supported providers:

Compute 40+ YES
Block Storage 17+ YES
Cloud Object Storage 8+ YES YES
CDN 6+
Load Balancers as a Service 7+ YES

Libcloud is the de facto choice for devs into Python and is supported by a great community. The documentation on their website is pretty good.

Let’s see some community stats:

  • Stackoverflow questions: 160
  • Github repositories 176
  • Most Github Stars (on single project) 518
  • Github Code results 2.2M
  • Google search (name + “libcloud”) 80K

Notice that Libcloud does not fully support Azure. For the time being it only supports Azure Blob Storages plus many of the AWS methods.

More about Libcloud at:

Note 1: If you exclusively work with AWS you may want to check Boto <>. It is a Python library for interacting with AWS APIs which allows you to build tools in Python, change and manage your AWS resources.
The project is led by an Amazon Engineer.

Note 2: If you feel adventurous, take a look at Libcloud REST, a Google Summer of Code 2012project which exposes most of the Libcloud functionality over HTTP.

Apache Jclouds – Java, Clojure

Jclouds, now one of the most popular solutions, started off as a project from Adrian Cole who later joined the Apache incubator. Adrian Cole is considered an active community leader in the cloud interoperability, REST and DevOps space. His current title is “cloud guy” at Twitter. Jclouds is an open source library that allows you to use portable abstractions or cloud-specific features and supports Java and Clojure.

Let’s see what kind of cloud resources Jclouds can manage:

Compute 17+ YES
Block Storage 7+ YES YES
Cloud Object Storage
Load Balancers as a Service 2+ YES

Jclouds, being a Java toolkit, naturally relies on a great community to support it. They also have excellent documentation on their website.

Here are the community statistics:

  • Stackoverflow questions 26
  • Github repositories 52
  • Most Github Stars (on single project) 531
  • Github Code results 7K
  • Google search (name + “jclouds”) 33K

While Jclouds supports some of the AWS services, it does very little on the Microsoft Azure side. In fact, it does not go beyond Azure Blob.

Note: There seem to be some early Azure implementations in the Jclouds labs. If interested, take a look or even contribute to their project.

More about Jclouds at:

Fog – Ruby

Wesley Beary, currently working at Heroku, is a great Rubist and the creator of Fog back when he was at Engine Yard. Fog is a cloud provider agnostic toolkit, therefore it supports a variety of cloud providers. The Fog gem is the most popular cloud SDK in the Ruby world and it is heavily used with over 4M downloads and a large and active community contributing to its development. It is an MIT-licensed open-source community project and is also used as basis for other Ruby gems like Chef.

Compute 25+ YES
Block Storage 9+ YES
Cloud Object Storage
Load Balancers as a Service 2+ YES

You can find many tutorials about Fog and its implementation online and adequate documentation on their website.

  • Stackoverflow questions 279
  • Github repositories 188
  • Most Github Stars (on single project) 3230
  • Github Code results 305K
  • Google search (name + “fog”) 565K

While currently Fog supports some of the major AWS services, it supports nothing on Azure! There are various discussions around the net about whether Fog will eventually go that way but, for the time being, no ongoing relative efforts exist other than some sparse GitHub repositories. Thus, if you are a Rubist and Azure user, the official SDK is a one-way option.

More about Fog at:

Apache deltacloud

RedHat wanted to develop an open cloud, vendor neutral so they started Deltacloud in 2009 and later joined the Apache incubator. For all you Rubists outhere, Deltacloud was written in Sinatra.

While Deltacloud is not the only open source project to offer cloud abstraction, it has a remarkable difference: Libcloud and Python, Jclouds and Java, Fog and Ruby are programming language-specific libraries. Deltacloud on the other hand is independent of the programming language and can also be used as web service. It provides three different APIs for interacting with Cloud service providers (a RESTful API, a CIMI-compliant API and a proprietary API) and is backward compatible across different versions of support cloud platforms.
Let’s see what kind of cloud resources and providers it supports:

Compute 15+ YES
Block Storage 15+ YES YES
Cloud Object Storage
Load Balancers as a Service

Apache Deltacloud has an active community of programmers who constantly update it. You may find adequate info both in their website and online to get you started.

  • Stackoverflow questions 10
  • Github repositories 37
  • Most Github Stars (on single project) 80
  • Github Code results 34K
  • Google search (name + “deltacloud”) 23K

More about Deltacloud at:

…and 2 bonus tools

1) Do you like to play with node.js? Check pkgcloud! It is a standard library for node.js that abstracts away the differences among multiple cloud providers. It supports the usual Cloud resources and providers. Interestingly, it supports Azure Compute resources which is not the case in any of the above toolkits.

2) If you are the Erlang type of dev take a look at elibloud. An Erlang wrapper around Libcloud.

Community Statistics Comparison

Below you will find two charts: a comparison of the number of cloud providers supported by each of the above toolkits and some community statistics.



Since 2006 the number of cloud providers has been steadily growing, bringing more services in the game. This is good news for developers, as more options become available to choose from. Using tools that provide a single interface to work with all these services can prove of great value to you, facilitating a potential transition from one provider to another. Still, good research prior to choosing a toolkit is essential. In our example, it becomes clear that Azure support from the toolkits presented is problematic, which is not the case for AWS (there could be many reasons for that, some originating in the very nature and definition of the Azure API). It seems that the development of toolkits is still a work in progress and things will soon start moving. Support of all major cloud providers is only a matter of time – and a game changer!

Do you use any kind of multi-cloud toolkits?


What the logs don’t tell you

In a world that is increasingly dominated by mobile applications and cloud services, APIs are becoming crucial to developers and service providers alike. But what are developers actually getting? And is this what service providers think they provide?



Developers want to use APIs that extend their service without having to either build the technology themselves or comply with required legislation or security (think payments or anything to do with storing large amounts of personal details).

[tweetable]Developers want simple, scalable, well-documented APIs that are as reliable as possible[/tweetable]. They do not want API they use to make their service unreliable, buggy or slow, i.e. make them look bad. Poorly-performing APIs can harm a developer’s reputation but also the API provider’s, should the branding of an API be visible to the world (think Twitter, Facebook, Instagram).

API Providers

API providers grant access to a service or services through the use of public or private APIs; a private API being a service that is not for public consumption for privacy or security reasons. Why grant access at all? To allow developers to use services and functionality that they do not have to build themselves and provide stickiness to an existing user base. Salesforce has done an amazing job of allowing third-party developers to use and extend the functionality that is provided and has even allowed developers to build a thriving apps and plugin community.

API providers look to balance the load on their servers that may also be dealing with other services. They are trying to provide minimum response times whilst maintaining the access and integrity of the data and the service for the developers.

Schrodinger’s API, it both works and doesn’t work at the same time

Here lies the problem; when an app that relies on an API performs badly whose fault is it? Is the app performing how the developer expected or is the API not responding and thus slowing the service? I[tweetable]t is very easy for the API provider to believe that just because the green light is on that the API is working[/tweetable]. Many systems behave completely different from the theoretical under load, when exposed to extreme conditions or elements beyond normal operation or even users doing unexpected things to the API.


System logs, either from servers, application monitoring tools or other conventional developer operating systems are excellent at hiding things because there is usually a lot of data to digest and identifying the issues from the noise can be nearly impossible.

Some examples include:

Averages – Whilst an average latency of 300ms may look ok its not if you are still getting a number of calls that take 10 seconds. To understand whether or not your slow performaning outliers are an issue means you have to look at the distribution of latencies and the frequency of the outliers.

Errors rates – hopefully these are low. Even a low error rate in a popular API can represent a huge issue. Consider an API that deals with 2 billion transactions a day at 0.2% error rate still has 4 million failed calls a day.

Logs only measure calls – If the API is not frequently used then the logs are not going to tell you anything. If the bulk of transactions are say only done on a Friday but the services failed on a Thursday then the detail will not be in the logs. Only frequent monitoring will notify you of issues before they hit your users.

Basically what the logs don’t tell you is how APIs work end to end, in different geographic regions and what the end-to-end latencies are when using real transactions.

Some simple rules

Monitoring is for life not just for Christmas.

An API that is switched on may not stay on but may be on every time you check.

The reliability of an API is inversely proportional to the number of people using it and the number of developers trying to do things that may break it.

The use of server logs is a function of user base and the amount of data being recorded.

Test the API like it would be used in the wild, end-to-end across a range of cloud services and apps. In this instance cloud services means hosting platforms like Google Apps Engine, Amazon Web Services and Azure to name a few.

Key question to ask is whether the servers are being tested for performance or the API and the impact on users and the overall experience?

As a developer and a user of services it’s the experience that matters. Poor experience equals poor brand perception, which leads to trying a different API or app, losing the client whether it’s a developer or a guy with an iPhone migrating onto the next app.

Things to consider when testing

Where is the data being served and where are your users?

An app that works in San Francisco when the server farm is in Mountain View may show differences when the same server farm has to serve the app in Europe. Test the API from different locations.

I got a HTTP200 response that means everything is fine, right?

Whilst most of us have seen HTTP 404’s, page not found, we also know HTTP 200 indicates an OK response from the server. The challenge comes from when a HTTP 200 means that things are not OK. For example, in order to avoid browser problems, some APIs only return HTTP 200 with an error message which needs to be parsed. Alternatively, the API might be returning invalid content which could cause an App to fail.

API search function comparison


In the above figure it can be seen that the average latency for search using the Facebook and Twitter API is approximately 2 seconds apart with Twitter being the faster and less erratic. Whilst we can only guess at what is happening in the background the reality is Facebook Graph Search appears to be less responsive to anyone using this feature in an app.

Regional server response variation


The above figure shows Facebook Get response across 6 regions globally. It can be seen that Asia and particularly Japan are poor cousins when it comes to regional performance. This behavior has been viewed with other APIs that have been tested in this way.

Caching data


The above figure shows the effect of caching on server response. After caching was implemented on the server it can be seen that response improved, even during refreshes (the spikes) overall performance was up.

Server issues


The above figure shows intermittent server issues over time. This can be indicative of load balancing issues or a problem with a server in a server cluster.

What is the future?

[tweetable]The number of APIs is only going to increase and developers are likely to rely on 3rd party services more and more[/tweetable]. It is also likely that more than one API from more than one provider will be used in an app. How can we mitigate against the response of one API compared to another? We see a need for intelligence in the app that can let that user know that something may be awry with the service trying to be accessed. This should be utilized as part of the UI flow to warn that ‘hey looks like is not responding, please bear with us’. This would be enabled by pinging the monitoring service to determine if there are any issues reported or the app being alerted automatically on a fail scenario that is outside pre-determined boundaries.

Intelligence in the monitoring will also lead to better understanding of the results and give a heads up to the API providers when issues occur or when the data is showing that a server is about to fail and allow providers to avoid downtime.

Disclaimer: Data was provided by who focus on API Performance measurement, testing and analytics. John Cooper is advisory board member at APImetrics


Permissions in Mobile Ad SDKs

If you’ve ever tried to integrate a mobile ad SDK into your application, then you’ve definitely had to declare a few permission for it to work. Permissions in mobile platforms such as Android and iOS have been baked in from day one as a mean to control what applications could do or access on your phone, preventing despicable people getting access to your most personal and sensitive data. In this article, we will review what permissions are required to integrate 10 of the most popular mobile ad SDKs out there.


For the sake of clarity and consistency, we will use the Android SDK permissions. Since most of these mobile ad networks mirror their Android and iOS SDKs this is an acceptable simplification, so without further ado, let’s jump right in.


The Internet Permission

This is a no-brainer really. If any ad SDK is going to be able to serve real-time ads, then it has to be able to communicate with an adserver over the internet. It’s no surprise then that all 10/10 SDKs require this permission.

The Network State Permission

Accessing the network state simply means identifying if the device is connected to the internet. If the answer to this question is yes, then this permission can also be used to identify if the connection is through a WiFi or a Cellular connection. This is the second most common permission across our sample with 7/10 SDKs requiring this permission and another 2 listing it as optional.

Access WiFi State Permissions

Using this permission is another way to check if a user is connected to WiFi or not but is clearly not the most popular method as only 2 SDK mark this as required with another 3 making it optional.

Read Phone State Permission

A less popular permission as only 3 SDKs require this but nevertheless all three make this a requirement.

Access Coarse/Fine Location Permissions

This is a very important set of permissions. Traditionally location has played a key role in advertising but has an especially increasing importance in digital mobile advertising. It comes then as no surprise that 7/10 SDKs are interested in this permission. There is a clear trend here that these permissions are mainly optional permissions because they can be considered as more “intrusive” by users so developers tend to avoid them if not using them already. On the other side, including location info with an ad request can usually boost potential by a great deal so this situation can present a great dilemma.

Other Permissions

While the permissions mentioned above are the most popular ones, you may encounter some less frequent ones like write to external storage or even record audio. Throughout the 10 SDKs mentioned in this article, we measure 12 distinct permissions which is not a very big number considering that the Android OS has more than 100 available to declare.

Most SDKs that we have reviewed for this article have very reasonable permission requirements. Ultimately, it’s up to the app developers to find the sweet spot on what they will allow these SDKs to collect and if they are willing to introduce new permissions in their apps just for this. On the other hand, by doing so, app developers can realise a substantial boost in earnings due to more targeted and relevant ads, which can be a great thing for the end-users as well!


Mapping it out: APIs for location-based apps


It wasn’t many years ago that, finding yourself with a hankering for a curry in an unfamiliar city you’d two choices; trudging the streets or waylaying a local. Today, with almost any smartphone you can quickly locate nearby eateries, see reviews and ratings, make a choice, and get guided to your meal with turn-by-turn navigation.

Location-based services are an important, integral part of the smartphone experience. The desire to offer users ‘the best’ mapping experience was graphically illustrated in 2012 when Apple launched its own map offering. Enabling developers to take advantage of and extend a platform’s location data is a vital part of the ‘location’ value proposition.

I’ve been asking myself, what’s the state of play when it comes to creating location-based apps? Has the technology reached a maturity where all platforms are equal? If you’re starting with your first location based app, which platform offers you the best tools and the most opportunity to differentiate?

The first question: which platforms? The big three seem obvious: Android, iOS, and Windows Phone. The other major thread in platforms would seem to be HTML5 ─ not only do we have the browser options, both native and third-party on the ‘big three,’ but potentially interesting developments with the likes of Tizen and Firefox OS offering ‘native’ HTML5 apps. So I’ve thrown that into the mix.

Now, having set the scope, let’s find out what’s available.

1. Location

The foundation of all location-based apps and services is the ability to determine where the user is located. Then, for applications such as navigation and augmented reality, direction of travel or the direction the user is facing are vital pieces of information as well.

1.1. Location technology

Most smartphones offer a GPS chip, usually with the addition of Assisted GPS (A-GPS) to improve the time to a first fix when initially requesting location details. In some platforms GPS-based location acquisition may be augmented with techniques based on mobile network cells and WiFi hot spots. These technologies help improve the accuracy of location information in cities, where buildings may obscure the signals from GPS satellites.

GPS also provides heading information, but only when the user is moving. The need for heading, or more particularly information on the direction the user is facing, is provided by magnetometers and gyroscope sensors.

1.2. APIs

The key feature of the APIs provided by all the major platforms is that they insulate you from the underlying technology used to acquire location/direction information. As might be expected, given this is the core enabling technology for location based apps and services, the features offered across the main platforms are fairly uniform, as shown in the following table:

iOS (7) Android (4.x) Windows Phone 8 HTML5
Location providers GPS and GPS/Cell/WiFi GPS and Cell/WiFi GPS/Cell/WiFi Platform specific, mainly GPS
Location (lat/long) Yes Yes Yes Yes
Altitude Yes Yes Yes Yes
Direction of travel Yes Yes Yes Yes
Direction facing Yes Yes, sensor API Yes, sensor API Yes, Orientation API
Geocoding/Reverse Geocoding Yes Yes Yes No
Background tracking Yes Yes Yes Platform dependent

All the three main smartphone platforms provide similar location and orientation APIs, in addition to geocoding capabilities. While iOS and Android provide you with explicit access to the GPS location, Windows phone provides location based on a desired accuracy and fix time, which can be manipulated to ensure a GPS location is provided.

iOS is the only platform that incorporates information on heading/facing within the location API; the other platforms rely on separate sensor APIs.

In HTML5 the orientation API may create challenges due to variations in coordinate reporting by various browsers 1. Compared to the ‘big three’ HTML5 has two main limitations: Lack of a ‘native’ geocoding API, for this feature you would have to rely on the mapping service used. The ability to track location in the background is the second difference and varies depending on the platforms’ ability to run HTML5 apps in the background.

It is worth noting that Google also offers some additional location related APIs through its Google Play services (in the Google Android Location API), notably:

  • to determine the user’s current mode of locomotion (still, walking, cycling, or in a vehicle)
  • geofence feature, which can trigger an event when the user goes outside a defined area.

1.3. Indoor navigation

One of the general limitations of GPS is that it doesn’t work well within buildings. A number of technologies have been investigated to overcome this issue, the principal options are WiFi and Bluetooth based. The advantage of WiFi-based systems is that WiFi hot spots are already common. Bluetooth based systems, such as iBeacon from Apple — which are based on Low Energy Bluetooth (BLE), also known as Bluetooth 4.0 or Bluetooth Smart — offer an interesting alternative, but it is likely to be sometime before there is sufficiently dense, widespread coverage to provide a universal solution. In addition, these Bluetooth-based technologies are not yet integrated into the platforms’ location frameworks, so they aren’t transparent to the location APIs. However, they offer you an interesting avenue for differentiation.

2. Mapping Services

Having obtained your location and orientation information the next step is to add a visualization. The most obvious of these is a map, or closely related representation, such as a satellite or street view.

2.1. The big three

Each of the big three smartphone platform providers have their own mapping solutions for native apps: Apple has MapKit, Android has Google Maps, and Windows Phone HERE Maps (BING Maps was deprecated in Windows Phone 8). Google and HERE also offer their maps for other platforms, in addition to several third-party map providers, more on this later.

2.1.1. Map and related APIs

There is a lot of common ground between the Map APIs provided and the features available for the maps you can display in your apps, detailed in the table below.

There are two main areas of difference between the platform offerings:

  • the routing information provided, however in most use cases you will want to pass off routes handling to a navigation app anyway (see the discussion on extended services below).
  • offline maps. While this doesn’t directly impact on you as a developer, it could affect your users’ experience when the phone goes offline and is no longer able to obtain updates to map data. While HERE Maps offers users the ability to download maps country by country, Google does it by displayed area and Apple appears not to offer an offline option.

Google has now made its Android APIs for maps a Google Play service. So, if you wish to make use of alternative stores, either to target devices such as Amazon’s Kindle or simply take advantage of other outlets, you need to use another mapping solution. This ‘other’ solution could be the HTML5 Google Maps, a vendor offering such as Amazon Maps API for Kindle, or a third-party offering.

Apple MapKit Android (Google Maps) Windows Phone (HERE Maps)
Views Map
Night/Day colours
Indoor maps No Yes Not available programmatically
Pan and zoom Yes Yes Yes
Pitching/Camera (2.5D view) Yes Yes Yes
3D landmarks Yes Yes Yes
Markers/Annotations Yes Yes Yes
Custom layers Yes Yes Yes
Polylines Yes Yes Yes
Route details Multiple routes for walking or driving, with expected travel time and trip advisory notices. Yes (Google Maps API Direction Services), single route for driving, bicycle, public transport, or walking. Single route for walking or driving.
Map Snapshot Yes Yes Workaround
Map type Vector Vector Vector
Offline access No Yes – by area Yes – by country
Restrictions Depends on developer program Only available as a Google Play API, no Navigation, Autonomous Vehicle Control, or Enterprise Applications, map call limits Apps for businesses, some API limits

As an alternative to embedding maps within your apps, you can pass location details to the platform’s Map app to display the user a map. This approach could be ideal where your app has a simple map use case. You can also use the same method to open StreetView on Android devices from your app.

2.1.2. Terms of Service

Apple MapKit appears to be the most flexible offering, with no apparent limitations on the applications you can create using the APIs nor on the volume of map data. Data use is ‘managed by the framework’, but there is no indication that this has created any practical restrictions. The only control is on app types through the Apple Developer programs, if you want to create apps for private distribution to company employees you need to enroll in the more expensive iOS Developer Enterprise Program.

Both Google and Microsoft place similar restrictions on the types of applications that can make free use of map data. If you want to create apps designed purely for use within a business and some specific types of apps (such as those for business asset tracking, fleet management, or dispatch) you’ll need to obtain licences through either the Google Maps for Business or HERE for business service.

In addition, Google only permits free use of its maps in free apps or paid apps that are available in an online store and are “downloadable to a mobile device that can access the online store”.

When it comes to the volume of use, both companies apply similar restrictions.

When using Google Maps you may have to pay, either through a Google console option or the business program, for additional traffic the app generates over 25,000 map loads or more each day, for more than 90 consecutive days.

For HERE Maps on Windows Phone the restriction is on routing and geo-coding requests, where there is a limit of 25,000 within 24 hours from any one app. More than that and you will need to contact the business service.

2.2. Extended map related services

The inter-app communications that enable you to pass a location to the platform’s map app, can also be used to open other location-based apps, such as those for navigation or transit routing. The various options are shown below:

Apple Android Windows Phone
Maps Yes Yes Yes
StreetView No Yes No
Traffic Yes No No
Guided or assisted navigation:
Car Yes Yes Yes
Walk Yes Yes Yes
Bicycle No Yes No
Public transport No Yes Yes

2.2.1. Third-party alternatives and options for HTML5 apps

With integrated support for maps in the main platforms it’s perhaps surprising how wide a range of third-party offerings is available. If you are creating a location-based app for HTML5, you will be using one of these offerings. An exhaustive review of the available programs is beyond this articles scope, but here is a list of some of those available:

Provider Features iOS Android Windows Phone HTML5 Pricing (Maps)2
HERE Similar to native n/a OEMs only Native JavaScript and REST Free low volume access
Google Maps Similar to native Yes No No JavaScript Free low volume access
CloudMade Map styles, Geocoding, POI, routing (vehicle, bicycle, or pedestrian inc. route times). n/a n/a n/a JavaScript $25 per 1M tiles (first 500K free)
Nutiteq Offline maps, 3D views, map projections for GIS n/a Yes n/a n/a Free for OSM data, costs on request
TomTom Geocoding, POI, routing, traffic, traffic cameras Yes Yes n/a JavaScript On request
Trimble/Spime Geocoding, POIs, routing, voice guided navigation, overlays, native app access (contacts, calendar, e-mail), monetization n/a Yes n/a n/a On request
mapIT Geocoding, POIs, routing, indoor maps, search, geo-marketing analysis tools, traffic (from Tom Tom) Yes Yes n/a Yes On request
mapquest Geocoding, POI, routing for vehicle, walking, transit, and bicycle with optimized and alternate routes, traffic including traffic search Yes Yes n/a JavaScript Free for OSM data, costs on request

You may wonder why I haven’t included Open Street Map in the list. While this service provides tiles, its open source/donation supported status means it may block your app if it breaks the ‘heavy use’ tile download policy. Therefore, the most practical way to use Open Street Map data is either to host it on your own server or use the free Open Street Map data provided by a third-party, such as Nutiteq or mapquest.

3. Augmented Reality

Location apps are increasingly moving away from the map, through the medium of Augmented Reality (AR). With applications, such as HERE City Lens, users are no longer required to figure out what all those lines and pins are telling them, they can simply point their phone’s camera at a scene and have it annotated with relevant information.

In addition to the need for location and heading information, AR requires the ability to paint over a display of the camera viewfinder and project POIs into the viewfinder. With the exception of POI projection in HTML5, all the platforms provide native APIs to enable the creation of AR apps.

In addition there are several third-party tools for creating location-based AR app, these include:

Provider iOS Android Windows Phone HTML5 Pricing
ARLabAR Browser Yes Yes n/a n/a €199 per platform
ARPA SDK Yes Yes n/a n/a On request
DroidAR n/a Yes n/a n/a Open source
GART – Geo Augmented Reality Toolkit n/a n/a Yes n/a Open source
Layar Geo SDK Yes Yes n/a n/a €7500 per year
Wikitude SDK Yes Yes n/a Yes Free with watermark, € 99 to € 1499

4. Conclusion

With minor variations, developing apps for the main platforms (iOS, Android, and Windows Phone) brings similar features and capabilities to your location-based apps. Only iOS, however, leaves you free to create whatever app you want, free from additional licensing costs.

In most cases the development process, from coding to store, is straightforward. The exception is where you want to target devices based on the Android Open Source Project, such as the Kindle, which use a store other than Google Play. The resulting need to use alternative (non-Android Google Maps) APIs will be something of an annoyance, at least.

Developing for HTML5 adds additional complexity, as a choice needs to be made of a third-party location/mapping service, but achieving similar results to those seen in native apps is entirely possible.

As I mentioned at the start, location–based apps and services are a key value-proposition for mobile devices. Their importance will only increase as the technology powering mobile devices starts to transition beyond phones and tablets into watches, cars, and a range of other smart mobile devices. This, combined with the competition between platforms, means that additional capabilities will continue to be added to the features available to apps, such as the ability to include and manipulate traffic data, and create embed and customize navigation.

  1. Firefox and Chrome does not handle the coordinates the same way.
  2. Vendors may offer separate pricing for geocoding, routing, navigation or other services.

Device API Usage and Trends

In the early stages of new technology markets, a lot of services are created because new technology has made new ways of doing things possible. [tweetable]Where app developers go, apps and then users will follow[/tweetable]. By looking at the popularity of various device APIs across platforms, we can see which developers are making the most of the capabilities their devices offer. If we then look at the device APIs that developers say they plan to adopt, we can see future trends in the app market, possibly months before the apps start to appear. Would it be wise to move against the herd, or is the trend really your friend?

Distinctively mobile computing

Mobile computing devices enable a greater range of applications than their desktop counterparts purely by being mobile. There are also features that are unique to, or much more relevant on mobile devices. In our last survey we asked developers about their plans for and usage of device APIs related to these features to gauge how much different groups of developers are taking advantage of mobility. The device APIs we asked about in our survey were those available to HTML5 developers, which allows us to compare their usage versus native developers across the most popular platforms.

Rather unsurprisingly, it turns out that HTML5 developers make less use of almost all device APIs than native developers. A lot of web developers are targeting desktop as well as mobile platforms and as such are less likely to build functionality that relies on mobile device specific APIs. However, that does seem to be changing as HTML5 developers are among the most likely to say they’re planning to use the majority of device APIs. You can see the popularity of each of the APIs covered in our survey by primary platform in the interactive chart below.

Another point to note about almost all of the APIs surveyed is that a greater proportion of iOS and Android developers use them than for other platforms. This suggests some maturity factor for platforms, either through increased competition causing developers to seek out more mobile-specific niches, or more likely, developers becoming more creative with ways to enhance their apps with mobile features over time.

Peering into the future

The differences between what developers are currently using and what they plan to use allows us a glimpse at future trends. Some of them are obvious, like the increase in intent to use the video camera. Video has long been more engaging for users but making effective use of local capturing and uploading relies on high bandwidth mobile uploads, which 4G connections provide. This trend is already preceded by mainstream services like Twitter’s Vine and video features for Instagram and Pinterest. For web developers, WebRTC offers the promise of easily integrated video chat in any site.

Voice recognition is another area where the trend is expected. The technology is maturing and the platform providers are investing heavily. It’s interesting that Windows Phone has the highest fraction of current usage here and the highest planned usage by a fairly wide margin. Perhaps there is some very effective developer marketing for the relevant APIs going on here?

Other APIs on the rise are less obvious, particularly the increase in interest in proximity sensors – the sensor normally used to detect whether you’ve got the phone held to your ear! It’ll be interesting to see what other creative uses developers put this to, or if it has been mistaken for technologies like NFC and Apple’s iBeacons. Sharing and Pairing is another less obvious candidate – as we didn’t specify exact technology here, it’s safe to say interest in various forms of social sharing from apps is unlikely to decline anytime soon and local sharing options such as Apple’s new AirDrop feature are likely to be popular.

User needs trump technical possibility

Given that Apple and Google (Motorola) have added special hardware for motion sensing, it’s not surprising that there’s a resurgence of interest in this type of API. Lets hope this time we get more creative uses like Magic Plan and not just a lot more motion controlled games and fitness trackers. For those looking where to take their app business, it might not be wise to follow any of these trends. Where lots of developers are exploring (and we do all love to explore new technology) there will be a lot of competition, yet the more general transition to mobile computing is still in the early stages. There are probably much more lucrative opportunities in slightly less exciting corners of the market.

APIs Tools

Accelerating Web Apps – It’s all about politics

On desktop computers web apps have come to dominate many application categories. They are easier to develop and deploy across multiple platforms and it’s possible to iterate much faster. A very large number of developers would like to be able to apply the same technologies and techniques on mobile devices but very few are able to do so successfully, particularly for mass market consumer apps. One of the most important reasons for this is performance. Resolving this issue is much more about politics than technology.

Are mobile web apps doomed to be slow?

Back in July, Drew Crawford wrote a blog post that got a lot of attention essentially claiming that JavaScript performance on mobile devices was simply too slow for serious apps and likely to stay that way for the foreseeable future. It showed, amongst other things, that the browser on the iPhone 4S was around four times slower than the slowest browsers capable of running Google docs real-time collaboration or Google Wave back in 2010. He claimed that ARM processors were not going to get faster rapidly enough to make a difference and JavaScript runtime improvements had stalled and were unlikely to make significant progress. Technically both of these points seem to have been proven wrong already. Apple just announced the iPhone 5S, with a processor twice as fast as the iPhone 5, which was in turn twice as fast as the iPhone 4S – so we have four times more raw CPU performance than we had just two years ago, theoretically enough to support 2010 desktop class browser performance. Also, Mozilla are working on asm.js, which uses a subset of JavaScript compiled ahead of time (AOT) and promises to enable apps to run in the browser at just 1.3 times slower than native performance – almost another four times speed increase versus the current five times slower than native performance of modern JIT compilers.

In addition to being at least partly incorrect this is also looking at a very narrow area of browser performance, a point well made in Sencha’s blog post in response. Across all vendors there are key performance areas where each is 10-40 times behind another. In reality, most of the major performance issues that prevent web apps from being competitive with native apps are related to graphics performance. Mobile device users have come to expect slick animated UIs which are only enabled by GPUs on the devices rather than, say, manipulating the DOM with JavaScript. Fortunately HTML5 and CSS3 provide several opportunities for GPU accelerated graphics with e.g. Canvas, CSS animations and WebGL. So, as mobile hardware and browser software continue to improve over the next couple of years competitive web apps should be just around the corner, shouldn’t they?

Platform wars and politics

With the technologies available or on the very near horizon today, plus improvements to mobile browsers across the major platforms, there’s almost no doubt that we could have competitive web app performance. The problem is that to get there requires platform providers and OEMs to adopt the technologies and implement the improvements – it’s not necessarily in their interests to do so.

Apple and Microsoft want users locked-in while Google wants them logged-in. Mozilla wants the open web everywhere but Google funds them. Opera recently gave up on writing their own browser core and use Google’s instead. That’s over-simplifying but fairly accurate. With other browser vendors attempting to prevent the user tracking that Google’s business model depends on (through default Do Not Track settings or third party cookie blocking) the best way to ensure users stay logged-in is to get them all using Chrome. This means they’re fighting a new browser war for control of the desktop web and taking that to the bulk of the mobile market through Android. In the process they are building several browser technologies to differentiate rather than standardise (e.g. they’ll prefer their own Native Client solution to asm.js).

At the same time Apple wants a great browsing experience but wants developers to build native apps rather than cross-platform web apps. As such they adopt most new web standards quickly but are very slow to include any that might enable high performance web apps – e.g. WebGL has been implemented since iOS 4.2 but only enabled for iAd, not in the browser, also Apple has famously not enabled their JIT compiler in the WebViews used by wrapped web apps* (needed to access native APIs) slowing their JavaScript performance by almost four times. Mozilla’s asm.js seems a very unlikely candidate for Apple to adopt anytime soon. Unless their new CEO makes a major change of strategy, Microsoft seem determined to follow the Apple model, although they might need first class web apps enough to accelerate their standards adoption.

A ray of light?

While there may be several classes of app for which mobile browsers are already good enough, for those hoping to develop all apps with web technologies, the news is not all bad. Although it seems unlikely to be possible to deliver a single solution with great performance everywhere, we might not be far from being able to deliver a good level of performance almost everywhere. Although Apple appear to have some strategic performance limitations, they also have some of the fastest hardware on the market. At the other end of the spectrum good Android browsers are reaching low end smartphones and the Firefox OS, also targeted at low cost devices, has an excellent web app environment. The other good news is that while we have real competition in the mobile market, browsers should keep getting better all round. We’re unlikely to see the return to stagnation of the Internet Explorer dominated early 2000’s.

* Apple do have a good security reason for doing this but they haven’t been in a hurry to resolve it either.

APIs Languages

Websites vs Web apps: What the experts think


Definitions of web sites vs. apps

Web sites are so deeply embedded into our daily culture that it is impossible to imagine life without them. Even as a developer, I find it hard to remember the times from my childhood when my chubby little hands didn’t yet know how to type. In the last two decades, the Internet has grown, expanded, exploded and became impossible to ignore, making any keyboard without an Internet connection pretty much useless.

In the last few years, the web brought with it a new term that can be exciting and confusing at the same time: “web app”. But what is a “web app”, how does it differentiate from a “web site” and why does it matter?

Understanding this difference ultimately makes us better users or developers? Is a business going to blossom just by marketing its online presence as a “web app” instead of a “web site”?

To figure out the boundaries between websites and web apps, I interviewed several prominent figures in the web technology domain who contributed with their experience and professionalism to help guide the debate: Dominique Hazael-Massieux (Mobile Web Initiative Activity Lead at World Wide Web Consortium), James Pearce (Head of Developer Advocacy at Facebook), Michael Mullany (CEO at Sencha), Christian Heilmann (Principal Developer Evangelist – HTML5/Open Web – at Mozilla Corporation) and Stephen Pinches (Head of Learning Technologies – ELT at Pearson plc and Group Product Manager – Mobile & Emerging Platforms at Financial Times). In this article I pieced together their expert input to help answer the web site vs web app debate.

The difference between Web sites and Web apps

In the pre app store era, the word “applications” had been applied to Web sites that provided advanced user interactions and capabilities previously available only through installable software. Early examples of web applications include Webmail, Google Maps and Google Docs. Compared to the classic web, i.e. blogs and news sites, web apps provided a richer user experience and access to advanced browser capabilities.

Today single-page web sites might still be referred to as web apps, but it’s more about the task focus than the technology itself. From this perspective, as Christian Heilmann explains, “The use case of an application is always to DO something with it”.

The task centricity of web apps is easier to understand if you think of smartphones or tablets: an app’s purpose is to achieve a specific task, like making a call, checking your email or finding a taxi nearby.

Some may argue that we can simply classify Web sites as being read-only and Web apps as being read-write. That certainly seems simple enough: Web sites are for consumption what Web apps are for creation. Does it sound right?

For developers, it is easier to draw the line between web sites and web apps if we think of the technical distinctions. Web apps have some defining attributes that bring them closer to their native counterparts:

  • self-contained
  • rich/interactive user interface, possibly mimicking the native UI of the device,
  • using advanced device capabilities – like geolocation, camera integration, or other technologies that the W3C Device APIs and Policy Working Group is developing,
  • action oriented rather than information oriented
  • not relying heavily on (or hiding when possible) the browser chrome (back button, reload button, address bar),
  • working off-line, for example using HTML5 ApplicationCache, localStorage, or indexed database.

Mozilla’s Christian Heilmann argues that the offline attribute is not a technical necessity in terms of definition, but rather a crucial usability distinction:

“Seeing how flaky our connections are – I am writing this on a plane – our apps should make people as effective as possible and this means we shouldn’t be dependent on a connection. The interface should be usable whilst we are off the grid and sync as soon as we go online”.

But how can we explain the difference to non-technical users? And, do we need to?

According to Dominique Hazael-Massieux, a Web site can be presented as a Web app as long as users consume it in a similar way they do a native app. If it’s exposed as an iconified app and used for a specific task, it shouldn’t matter whether it’s contained in the browser or installed via an app store. Facebook’s James Pearce outlined a few possible vectors that need to be considered when differentiating between Web sites and Web apps. I‘ve summed up his arguments:

Creation versus Consumption

Pearce asserts that read-only interaction should be classified as a site, but this criteria is not sufficient to distinguish between web sites and web apps. We still have cases like Flipboard (clearly oriented towards consumption) or Twitter and Facebook (with entirely user-generated content) that do not fit in any box.


Since both web sites and web apps can be launched by entering a URL into a browser or from a home-screen icon, this is clearly “not a reliable way to distinguish between web apps and web sites” according to Pearce.

User Experience

Visual pizzazz is an important argument, one that users might particularly relate to, but is also a fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list appears as hyperlinks instead of ‘tappable’ items? What if I use plain scrolling instead of smooth fancy bars?


In the case of single page webapps, is SEO the price to pay when choosing to give the browser far more autonomy and responsibility and take advantage of its HTML5 APIs like storage? Do Web sites have SEO capabilities while Web apps don’t? We are back to explaining the differences between the two by using technical terms.

Should you be building web apps or web sites?

This question might be regarded as a technicality with a pinch of marketing to spice it up. This reminds me of the “HTML5 is ready” contest by Sencha that was announced a few months back, encouraging developers to draw inspiration from native apps and create similar web apps that show off the capabilities of HTML5.

The creators of the competition correctly argued that “the mobile web is the most fertile ground for leading edge web development because it doesn’t have the legacy of the older internet explorers that the desktop does. You can start your development with the assumption that your app or your content will be used in a fairly recent browser, so you can take advantage of a whole host of features like Canvas, inline SVG, HTML5 video, CSS3 styling etc. that bring the experience alive for the user”, as Sencha’s Michael Mullany explains.

Would it be safe to argue in favour of building web apps instead of web sites especially on mobile? Mobile users perform specific tasks on their devices, so a web app that offers the same experience as a specialised native app might gain more interest compared to a regular website.

Long term the distinction should not matter. According to FT’s Stephen Pinches, it really doesn’t make any sense, on the long term, to speak about the future of the mobile web: “there shouldn’t be “mobile” and “desktop” but simply good, user-centered design, which adapts and responds to the screen size and features of the device upon which it is displayed. However, on short to medium term, there is a need to differentiate and ensure the user experience is as good as possible on a given device.”

The ‘app-ification’ of the Web

Whatever your preference may be, there is an increasing number of mobile developers targeting web apps. Based on VisionMobile’s latest Developer Economics survey of 6,000+ developers, already 23% of HTML5 mobile developers develop web apps, compared to 38% who develop mobile websites.

With browsers increasing support for device APIs, and with a growing number of developers going direct to native with PhoneGap, Icenium or Appcelerator, or even with the recently launched Firefox OS, the web world is clearly moving in the direction of apps.

As Sir Tim Berners-Lee said in 2012, “the solution is in your hands: develop web apps!”

APIs Tools

Which apps make more money? App monetization insight from our Developer Economics 2013 report

[This post by Andreas Pappas, Senior Analyst at VisionMobile, first appeared on the VisionMobile blog on April 3, 2013.]

[How do app developer revenues vary by country, or platform? Does the number of platforms make a difference to app revenues? Which models bring in the most revenues? We revisit Andreas Pappas’ November analysis of app monetisation with more insights from our Developer Economics 2013 survey across 3,400+ developers – while launching our latest survey, which is available here]


Back in November, we looked at which apps make money based on research on how app revenues vary by platform, app category, country and more. In this article we update our analysis on app monetisation based on the latest research from Developer Economics 2013 across 3,400+ app developers, including analysis that did not make it into the report.

We ‘re also proud to launch our very latest Developer Economics survey, which reaches across thousands of app developers and provides the data for our famous state of the developer nation reports. Thanks to the sponsorship by BlackBerry, Mozilla, Intel and Telefonica it possible to provide these reports and additional insights, for free, to the entire mobile community.

Take part in the survey, spread the word and help us drill deeper into the app economy and what makes it tick. We have prizes aplenty for developers, with 7 devices up for grabs (one iPhone 5, two Samsung Galaxy SIII, two Nokia Lumia 920 devices and two BlackBerry Dev Alpha handsets) – plus an AR Drone 2.0, a Nest Learning Thermostat and a Nike Fuel Band for participants who also subscribe to our developer panel. Last, but definitely not least, our friends at Bugsense are giving away one month of free crash reporting to each and every participant.

Survey Q1 2013


Developers in North America lead the revenue leaderboard

We’ll start by taking a look at income distribution by the region where app developers are based. Last time we saw that US developers earned almost double the revenue of UK developers. Based on our Developer Economics 2013 data, North America (and particularly the US) is still in the driving seat of the mobile app economy with developers in North America generating about 30% more than their european counterparts, who in turn generate 47% more revenue than developers in Asia. To some extent higher revenues for NA developers are explained by higher consumer spending in the US and higher penetration of iOS, which as we will see later on, still generates higher revenues than other mobile platforms. Note that across this analysis we are restricting our sample to mobile app developers, and have excluded the top 5% of revenue earners in order to minimise the effect of outliers.

North America leads app revenue leaderboard

While app development activity is booming in Asia, the average app-month revenue is quite lower than in the US and Europe, although developers in Asia develop, on average more apps and use more mobile platforms. As we explained in the previous article, there are multiple reasons for this revenue gap, but the prevailing reason is the fact that paid apps are not popular in most of Asia, the country that drives the Asian app economy. Instead, developers in Asia rely much more on advertising revenue, which, according to our findings is the least profitable revenue model.

iOS still monetising better than other platforms

iOS continues to dominate platform revenues, generating, on average, 30% more revenue per app-month than Android. The revenue gap has reduced by 5 percentage points compared to that reported in our Developer Economics 2012 report in June 2012.

iOS continues to dominate revenues

At the same time, Windows Phone has caught up with Android and seems to be doing slightly better. Although the 5% advantage is arguably within the margin of error, Windows Phone has significantly improved its position relative to the figures reported in the Developer Economics 2012 survey, when it generated, on average, about half as much revenue as Android. How has the landscape of platform monetisation changed in Q2 2013? Join the survey and help us track the state of the developer nation.

Multi-platform developers earn more

Developers using more platforms earn more

There is a wide revenue gap between developers/publishers using 6+ platforms and those using 5 or fewer platforms, with those developing for 6+ platforms generating, on average, 75% more revenue. However, only a small part of the developer population (4%) develops on 6+ mobile platforms; these are probably established services with a large footprint that want to ensure that their apps are universally available (e.g. Facebook, Skype etc.) or large software houses with a large enough pool of resources to target multiple platforms for their customers.

Those developers employing just one platform are probably solo, amateur developers or have not yet had the success that warrants (and allows) an expansion onto more platforms. As developers become more successful, they will expand onto new platforms and generate more revenue. So while, expanding on more platforms is not sufficient to generate more revenue on its own, those that do find success are likely to invest in a multi-platform strategy.

Extending apps to new markets is a profitable strategy

We asked app developers how they decided on which apps to develop or work on next and then looked at the way revenues vary depending on their strategy. While most developers will develop apps they want to use themselves (50%), this is apparently the least successful strategy and should not become the sole deciding factor for your next app.

Extending apps into new markets pays better

Developers that use some form of market research such as discussing with users, monitoring apps stores or directly buying market research are much better off, generating at least double the revenue of those who just develop the apps they want to use. However, market research is not widely used among the developer population: only 24% of developers discusses with users, highlighting a lack of business maturity and also a gap in frictionless 2-way communication channel between developers and users.

Overall, the most successful developers are those that extend apps to new markets, either to new geographies or different verticals. To some extent, these strategies rely on copying the recipe of an already established and successful business: these are apps that have been tried and proven in at least one market and are generally less risky options or “low hanging fruit” for developers. Why start from the ground up when you can stand on the shoulders of giants?

The most lucrative revenue models are off limits for most developers

When talking app monetisation, there are over 10 different revenue models to chose from. Device royalties and distribution licensing fees are the top-grossing models but are quite rare among app developers due to their high barriers to entry. These models imply deals with device manufacturers and distributors which means long, expensive sales cycles and a successful app to start with. Among the rest of the revenue models, commissioned apps (development for hire) come on top since they come with a low risk and guaranteed income for developers that work under contract.

Royalties & licencing fees pay better

The next most lucrative revenue model is the subscription-based model but this also comes with caveats: a subscription service implies a significant investment in licensing, and maintaining quality content or services that keeps users engaged on an ongoing basis.

Among the revenue models that are most popular and more accessible to developers, In-app purchases come on top, generating, on average 34% more revenue than Freemium and 43% more revenue than Pay-per-download. In-app purchases and Freemium models are becoming increasingly popular, now being used by a quarter of developers as they seem to be appealing to consumers. We ‘re revisiting the topic of most lucrative revenue models in our latest survey. Join in and help us size the app economy.

Smart developers use smart tools

Finally, we take a look at how developer revenues correlate to the use of third party tools and services. It’s interesting to see how app revenues correlate with usage of performance tracking and management tools like user analytics and crash reporting. Developers using crash reporting and bug-tracking tools such as Crittercism or BugSense generate on average, three times more revenue than developers who don’t use these. Similarly the usage of User Analytics (e.g. Flurry, Apsalar) services is also associated with much higher revenues, with those using user analytics services generating 168% more revenue than those who don’t.

Higher revenues for developers using dev tools

Both user analytics and crash reporting services are used by experienced developers who recognise the importance of optimising for user acquisition, activation and retention, while reducing in-the-field crashes and the resulting user churn.

Track the state of the developer nation

[tweet_this content=’App developer? Take the new Developer Economics survey and win prizes!’ url=’’]These insights are made possible by our ongoing surveys. Join the latest Developer Economics survey to help us draw deeper insights into monetisation, the size of the app economy and the debate of HTML5 vs. native. In this survey we ‘re focusing on the population of iOS, Android, WP, BlackBerry and HTML5 developers, across countries, app categories and developer types. If your are a developer take the survey, or otherwise spread the word and watch this space for an update on revenues, platforms and the state of the developer nation.[/tweet_this]

And don’t forget to fire away with those comments, rants, criticism, praise or simply feedback on what you ‘d like to see next.

Andreas (follow me on twitter @PappasAndreas)