Developer Nation Blog

Top revenue models by screen

Post author By Mark Wilcox
Post date April 29, 2014
No Comments on Top revenue models by screen

Screens are everywhere. We’re rapidly being surrounded by bits of glass with some app or other running behind them. Developers have an ever increasing choice of screens to target. There’s a clear and increasing trend towards greater use of mobile screens. However, where is the money? Which screens are users most likely to pay for apps and content for? Are different revenue models better suited to particular screen types?

Mainstream screens

Our developer surveys are only for developers who target mobile devices. However, the developers don’t exclusively target such devices and some don’t even consider them their primary target. The only screen types considered a primary target for large numbers of developers are smartphones, tablets and PCs; all other screen types are relatively small niches. There is some interesting variation in the success of different revenue models by screen type. However, developers earning very high revenues (>$100k per app per month) are fairly evenly spread across revenue models and so they significantly distort averages towards less popular revenue models. It turns out that nearly all of these developers actually use several revenue models simultaneously (far more than the average developer) and we don’t have the data to split out which ones are actually bringing in the bulk of the revenue. Excluding these high earners from our analysis we see the spread of revenues across screens and models in the chart below.

Where’s the revenue?

The most obvious pattern is that [tweetable]revenues for developers who primarily target PCs are generally higher than for those who target smartphones[/tweetable], which in turn are higher than those for tablets. Now, remembering that these PC developers also target mobile platforms, we are most likely looking at more mature businesses and almost certainly more developers targeting enterprises. Affiliate or CPI (cost per install) scheme revenue stands out for PC developers in particular. Affiliate marketing is a fairly big and mature business on the desktop web but CPI schemes for mobile app developers are a relative new and high growth business. Currently, anyone who can reach mobile app users and provide paid installs below the expected lifetime value of an average user is seeing significant demand. With development costs essentially fixed and the marginal cost of serving a new user extremely close to zero, successful consumer focussed mobile apps are willing to pay handsomely for installs.

The notable exceptions amongst tablet first developers are those selling subscriptions; [tweetable]median revenues for tablet subscription apps are by far the highest across all screens and revenue models[/tweetable]. It’s easy to speculate, with tablets being such excellent media consumption devices, that these subscriptions are mostly for media content (magazine, news and video) apps. Obviously there are high costs associated with producing the content, so those high revenues don’t necessarily translate to high profits. Additionally, the higher than average median revenues for developer services on tablets may be related, since tools and platforms for content publishers on tablets are fairly popular.

The e-Commerce mystery

On the desktop web e-Commerce is a giant industry and yet we see smartphones ahead of tablets, with both quite a long way ahead of PCs for e-Commerce revenues. All the e-Commerce spending data says the opposite, with PC spending still ahead of tablet spending and smartphone spending the lowest. Perhaps the scale advantages in online retail mean that there aren’t many businesses able to compete in sub-$100k / month revenue filter we’ve applied here and there are just some niche mobile first e-Commerce solutions starting on smartphones. Indeed our top end revenue band of $500k+ in the survey is probably not large enough to reflect successful e-Commerce businesses. Possibly our survey just hasn’t attracted a representative cross-section of e-Commerce developers.

Continuous clients

Currently PC-first developers are still making the highest revenues for most types of business. Indeed, even the simple paid download model that seems to be almost dying on mobile platforms is looking fairly healthy on PCs. Tablet-first software developers aren’t yet seeing fantastic results despite the growing penetration of the iPad in enterprises and educational institutions. The giant installed base of smartphones does not yet offset the low revenues per user from what are mostly consumer apps. Mobile developers need to focus more on which users are willing to pay for software and what they’re willing to pay for in order to grow revenues. [tweetable]Mobile-first may be an excellent design philosophy but it shouldn’t also imply mobile-only[/tweetable]. Subscription-based businesses are working very well across all screens. Most developers offering subscriptions provide clients for all of the screens their customers use to access their content or service. It seems increasingly likely that the future, regardless of revenue model, will reward those who offer services that work seamlessly across all the screens a person owns, rather than focussing on one over others.

Tags cross-screen development, revenue models, tablet

Business

7 things you need to know before developing a car app

Post author By Stijn Schuermans
Post date April 14, 2014
No Comments on 7 things you need to know before developing a car app

Are you bored with the same old smartphone apps? Why not try developing for cars?

Which tools do you use to develop apps? Have your say in our Developer Economics survey and you could win awesome new gear.

Car makers have started a major offensive to get more apps in their vehicles and open up to outside developers. Their efforts have sparked an interest in the developer community. “A year ago there was very little interest from mobile developers because the automotive market was perceived as being too insignificant,” says Linda Daichendt, Executive Director of the Mobile Technology Association of Michigan, a trade organisation for the mobile/wireless industry located in the heart of automotive country: Detroit. “In late 2013 there was a tremendous surge in vehicle manufacturer outreach to mobile developers with extensive marketing programs. Now there is a much higher level of interest from developers in trying to understand the needs of the automotive companies and how they can profit from working with this market segment. As a result, 2014 is seeing a large number of Connected Vehicle conferences and training programs that are very well attended by the mobile developer community.”

According to Linda, education will be the key to unlock developer engagement and creativity. We thought we’d put in our own 2 cents with our latest report: “Apps for connected cars? Your mileage may vary””. In the free report we describe the state of automotive developer programs in 2014. Here are already 7 things you ought to know before getting into car apps. Many more details inside!

[tweetable]There are 4 ways to develop a car app[/tweetable]. If you want to build an in-vehicle infotainment app, you can run it either on the car’s head unit (the dashboard) or run your app on a mobile device (smartphone or tablet) that is linked with the car. In the latter case, your app’s UI can be mirrored on the dashboard screen using APIs like Mirrorlink or CarPlay. If you want to make an app (in the car, in the cloud or on any device) that uses data from the car, you can use a car maker’s vehicle data API or access the On-Board Diagnostics port (OBD-II) using a bluetooth dongle.
[tweetable]There are 3 routes to market for car apps. Two of them are painful. The third is very early stage.[/tweetable]
- Partner with car makers to get the app pre-installed in the vehicle or featured on a car maker app store. This process takes 2-6 months in the best case. You’ll have to audition with car makers to be allowed to distribute your app, and you’ll be at their mercy for much of the UI design.
- Distribute apps on major mobile app stores (iOS, Google Play). Still, the approval of car makers is needed to distribute apps using their APIs. You’ll need to sign a distribution contract with the car maker in most cases.
- Distribute apps on major mobile app stores (iOS, Google Play) while using an OBD-II dongle to get vehicle data. In this case, you need to convince your user to buy and install a hardware dongle. Platforms like Dash and Carvoyant that allow you to access data from an installed base of dongles have only recently launched, and don’t have a large user base yet (in the tens of thousands at most).
[tweetable]The addressable market for car apps is in the lower millions of app installs[/tweetable]. If you were to produce a car app today and push it in the market with all your might, you can expect at most a few million installs across all platforms. It will probably take you several years to get there. Consider the example of Pandora, one of the most popular car apps around. It took them 3 years and over 30 partnership agreements to reach 4 million unique users. Nokia HERE, the navigation platform, claims to be behind 4 out 5 in-car navigation systems. They have sold 10 million licenses in 2013. Compare this to a potential of hundred of millions of installs on iOS or Android for the top apps. (Apps like Gmail or Facebook will probably count billions of installs when adding up all the platforms.)
[tweetable]…but you’ll face much less competition in car apps than on the mobile app stores[/tweetable]. In our Developer Economics report series, we talk about millions of individual mobile app developers on each major platform. There are hundreds of thousands of app publishers on an organisational level. Based on data from analytics firm Priori, we estimate that each distinct app sub-category or use case has on average 1,500 apps competing for the user’s attention.
In contrast, VisionMobile currently estimates the amount of car app developers at around the ten thousand mark, based on reported figures from car makers that have developer programs. It is still possible to “ride the wave”, i.e. to have an early-mover advantage on car apps just like it existed on smartphones in 2008 or tablets in 2010.
[tweetable]Revenue opportunities for car apps are fuzzy and unproven at best.[/tweetable] Most car makers and car app platform players have not thought through the revenue model question. A common answer is: “the developer can use whatever revenue model he chooses or he is already using”. As we know from mobile apps, it’s not that simple. If you’re relying on an App Store based app for revenue generation, then paid downloads are all but dead in terms of revenue (except navigation apps perhaps), display advertising seems like a no-go and an in-app purchase during normal use seems pretty unlikely, or at least high-friction.
[tweetable]You must design an app that can be operated at 65 mph / 100 km/h without crashing (not your app! your user!).[/tweetable] Safety concerns around driver distraction are absolutely paramount for the car makers you’ll be working with. This is the single biggest difference between car apps and the mobile apps you’re already familiar with. The feeling among car makers is that developers tend to underestimate the importance of new UI paradigms quite a lot – and you’ll be thoroughly scrutinized on it. Expect a learning curve.
This of course doesn’t apply for car apps that are not used while driving or don’t require user interaction – by no means a niche area! Think insurance, fleet management, car sharing, maintenance and reselling: the list is endless.
[tweetable]Things are moving fast. Your life is about to get easier as platform plays similar to iOS and Android are set in motion[/tweetable]. The introduction of Apple’s CarPlay and Google’s Open Automotive Alliance (and to a lesser extent Windows in the Car) seems to herald a tipping point in the industry. Here are two players that have a deep expertise in solving fragmentation, in building developer communities and in enabling developers to add value. There is now a realistic and acute possibility that these new entrants will sweep away the existing car app platforms with a dominant, over-the-top solution, just as they did in the smartphone world. You can find an overview of all the important platform contenders in our report.

Do you consider car apps part of our future? Have your say in our Developer Economics survey and you could win awesome new gear.

Business

Emerging developer opportunities in Enterprise & Productivity apps

Post author By Andreas Pappas
Post date April 7, 2014
No Comments on Emerging developer opportunities in Enterprise & Productivity apps

Andreas Pappas shares our latest findings, from our Business & Productivity Apps report which takes a look at developer opportunities created by emerging trends in enterprise mobility (such as bring-your-own policies and mobile SaaS) and professional and vertical app markets (e.g. healthcare apps). This market was worth $28 billion in 2013 and is set to grow to $58 billion by 2016.

[Want to help us with data for our reports? We’ve just launched our latest Developer Economic survey – take the survey and have your say on the latest trends]

[tweetable]Apps are changing the way people communicate, work and play[/tweetable]. App development has grown into a huge industry, that we estimate to be worth $67 billion in 2013. We expect the app economy to more than double in size by 2016.

Most of the publicity and media spotlights currently fall on superstar consumer apps like Angry Birds or Candy Crush Saga and communication apps like WhatsApp. These success stories have certainly highlighted the massive scale and revenue potential of mobile apps, reaching from zero to tens of millions of users in record-breaking time.

At the same time, a growing audience of prosumer and business users depend on Box, Evernote and Trello to help them be more productive in their work. Enterprises are now allowing employees to use the apps they love at work, inside the corporate Intranet. Organisations of all shapes and sizes are integrating mobile apps within their business processes. This mobilisation creates a demand for off-the-shelf or custom mobile apps and services, translating into new and bigger opportunities for mobile app developers.

Most app developers currently target consumer app markets (think games and lifestyle apps) but they could be missing out on opportunities in the enterprise (aka business & productivity) market. Our research indicates that the business & productivity app market, is not only growing at approximately the same rate as the consumer app market but is also less congested, and offers better revenue potential, for more developers. Read the report to find out more.

Consumer vs. Enterprise & Productivity apps: how do revenues compare

App publishers that target business and productivity markets have a much better chance of generating sustainable revenue than those targeting consumer markets, with just 32% of them below the “app poverty line” ($500 per app per month) compared to just under half of consumer-focused publishers (48%). At the same time, [tweetable]publishers that target businesses or professional users have a much higher chance to generate very high-revenues[/tweetable]: 16% of those targeting the business & productivity market generate revenues exceeding $500,000 per app per month, compared to just 6% among consumer-focused publishers.

While consumer apps and particularly games (e.g. Angry Birds, Candy Crush Saga) can generate extraordinary revenues, it is quite clear that this is not the case for the vast majority of developers that target consumer markets. Business & Productivity apps allow developers to build a sustainable business around more solid business models with recurring revenues from a loyal customer base.

As bring-your-own policies and enterprise app stores become increasingly popular among businesses, the market and the opportunity for developers is likely is set to expand in the next three years.

Which platform should you prioritise if you build business and productivity apps?

While Android is dominating the consumer market in terms of market share, iOS maintains a healthy lead among professional and business users. Data provided by enterprise cloud content platform Box, indicates that 94% of their tablet users are on iPads, while enterprise mobility management services provider Good Technology indicates that 54% of enterprise smartphone activations came through iPhone devices in Q4 2013. It is clear that Apple has an edge in the business device market and this is also reflected in revenues generated via iDevices: VisionMobile estimates that revenue generated via iOS devices accounts for at least 60% of the total revenue in the business and productivity market.

For developers that target the business & productivity sector it makes sense to prioritise iOS for development over the other platforms they develop for. However, there are several considerations to take into account such as integration with existing enterprise services, which may call for an HTML approach or the specific market that you target.

Where are the opportunities in the enterprise app market?

There is an inherent unpredictability associated with the future use of apps and it is exactly this unpredictability that empowers developers to create innovative apps that continue to redefine whole markets and industries. Nevertheless, we can still identify a number of areas that currently attract considerable attention among businesses and where we see future value being unleashed in the business & productivity market:

Vertical apps
Specialised industry apps such as healthcare, real estate, finance or automotive. Vertical specialisation provides a great opportunity for differentiation and for building strong brands as the app economy diffuses into every single industry. Existing industry stakeholders can leverage apps as a differentiation strategy against “un-apped” competitors, integrating apps and exposing APIs across their product offerings. For independent developers, specialisation is a means to capture a niche and survive the discoverability labyrinth.

Productivity/BYO
Apps that cross the boundaries between private-use and work-use, such as storage, lists, calendars, office-type apps are key drivers behind the consumerisation of enterprise IT. Once into an organisation or an enterprise app store, such apps can spread rapidly within organisations.

Mobile SaaS
Software-as-a-Service, delivering CRM, HR, ERP, BI services to small businesses and large enterprises is a booming sector. Mobile apps extend these capabilities much further by allowing anytime/anyplace access to these core business services.

Custom apps/services
Bespoke mobile solutions delivered outside of app stores will continue to take the lion’s share of revenues within the business and productivity app market. As we discussed, the dominance of this model will erode during the next few years as app store purchases increase among enterprises.

MDM/MAM
Apps and services that tackle security and complexity of the decentralised IT department are already essential for any enterprise that adopts BYO policies. More sophisticated app & device management models, that tackle some of the key issues associated with this trend (e.g. managing private/work services, remote deletion of work content) will continue to be hot areas in the next few years, catering to an increasing number of use cases.

Download our free “Business and Productivity Apps” report to find out more about the developer opportunity in this market and the reason you should be developing business and productivity apps.

Have your say in Developer Economics research
Help us continue bringing you great insights about the app economy and app development. Take part in our 7th Developer Economics survey that is launching today! Help us break our earlier world record of 7,000 app developers that took our 6th survey. Take part, spread the word, win prizes and help us do great research !

Tags app business, app economy, Enterprise, forecasts, productivity apps

Business

A guide to building your app business

Post author By Mark Wilcox
Post date April 3, 2014
No Comments on A guide to building your app business

So you want to start a business developing apps? Or maybe you have an app business but want some advice on how to grow or improve it? [tweetable]Simply building an app and publishing it on app store as a paid download is extremely likely to result in disappointment[/tweetable]. This shouldn’t be news to you if you’ve been following the industry in the last few years but what should you do instead? In this article we’ll look at some strategies to increase your chances of building a successful app business.

Risk versus reward

Building a product to sell is exciting and full of creative possibilities but it’s also always a risky approach. If your primary interest is in designing and building apps and solving problems then a far lower risk app business is a software services business. Developers who make most of their revenue from contract development work have the highest median wages by far, in other words, very few of them can’t pay their bills! That said, if you’re planning a software services company it makes sense to use any downtime from client work to build your own products. It can not only generate some additional income but also gives you something you can show potential clients publically (a lot of clients won’t let you publish the fact that you built their app). In our previous surveys, developers who’ve earned a small fraction of their revenue from app stores and the rest from contract work have done significantly better than those doing 100% contract work.

Of course the trade-off with a services business is that the upside is very limited. Global competition makes it hard to charge significantly in excess of typical developer wages. On the other hand, there are several examples of small teams with a hit app that has made them millions of dollars. Our survey data consistently shows that these successes are very much the exceptions. [tweetable]Only a small minority of app development projects are significantly profitable[/tweetable]. Even if you think you’ve got a great idea and a great team then, unless you’re spending your investors money, seriously consider balancing your product development work with some contract development.

Businesses versus consumers

If you’re building products, consider your audience carefully. [tweetable]Who you build your apps for has a massive influence on how successful you’re like to be[/tweetable]. In general businesses are much more willing to pay for software than consumers. As I’ve written before, developers targeting enterprises make four times as much as those targeting consumers on average and yet the latter face much greater competition. Don’t think that targeting organisations rather than individuals means you’re limited to automating business processes. There’s lots of complex and interesting software that businesses need, for example visualization tools to help sell product and projects, or even to help construct things in the real world. There are also extremely simple but valuable pieces of software that can make a positive difference in the lives of lots of people; I’ve met one entrepreneur who’s made a small fortune selling eye-testing software. Additionally, you may be able to target your product idea to an enterprise rather than consumers and have significantly greater success. There have been some relatively small scale successes for developers selling educational software on Apple’s App Store but most of the big successes in educational apps are selling to schools instead of or as well as direct to consumers.

If you’re determined to build consumer apps or your category of choice leaves you with little option (e.g. games) then go big or go home. [tweetable]The app stores only consistently reward the best[/tweetable]; an occasional viral hit may do very well for a short while but they’re impossible to create reliably and they rarely last. If you don’t truly believe you can make an app worthy of the top ten in your category of choice then you should probably relegate this particular passion to a side project or hobby. You don’t really need to make the top ten to earn a decent living (although doing so isn’t sufficient, you’ve got to stay somewhere near the top) but it’s best to allow for some overconfidence!

Be creative with business models

Whether you’re building games for consumers or productivity apps for businesses, design your business model along with your app or service. If you design and build the product first then try to bolt a monetization scheme on top, you may find yourself with relatively few options. A large fraction of developers are still using paid downloads or advertising as their primary revenue model despite the fact that these are the least successful options. There are exceptions where other models are not suitable (e.g most kids apps really ought to be paid download only) but [tweetable]much less than 10% of all revenue paid out by app stores comes from paid downloads[/tweetable]. Developers relying entirely on advertising rarely do much better either.

The ideal business model is some kind of subscription or annual license that produces recurring revenue. This is relatively common with services aimed at businesses but certainly won’t fit every consumer app. Most apps that are aimed at consumers need to be free to download.
There’s simply too much competition. Whether you then get paid through in-app purchases or selling some related product or service is still an area open for experimentation. We’re seeing some games developers experiment with physical toys that unlock content. Amazon wants developers to sell their products and earn a commission. There are plenty of unexplored possibilities and new technologies create new ones all the time. You’re not limited to one revenue source either, mix and match! Whatever you do, don’t copy the strategies that aren’t working for most other developers unless you have a very good reason to believe you’ve got a special case. Either copy strategies that are working or try new ones.

First balance your risks according to your finances. Select your audience carefully. Then design the business model to maximise your chances of getting the audience to part with their cash then. Do all three and you’ll have a much greater chance of success than the vast majority of your peers. Now all you need is excellent execution and a bit of luck.

Tags app business, Business models, revenue model

Business

Fame From a Game: 5 Game Developers Dealing With Overnight Success

Post author By Joe Fortunato
Post date March 26, 2014
No Comments on Fame From a Game: 5 Game Developers Dealing With Overnight Success

The mobile app market has completely overhauled the video game market. In an industry that once required thousands of dollars and a legion of programmers to produce a product, individuals and small groups of entrepreneurs can now produce games grossing millions of dollars from their bedrooms. However, the success of a #1 selling game does not come easy and sometimes causes more problems for the now wealthy developer. Here are five examples of successful game developers who had to learn how to handle success almost overnight.

Which game development tools help you become successful? Let us know of your favourites in the Developer Economics Survey.

Halfbrick Studios (Fruit Ninja)

Before Fruit Ninja, most people had never heard of Halfbrick Studios. They had worked on a handful of games like Rocket Power: Beach Bandits, Age of Zombies, Monster Dash, and a variety of Avatar — The Last Airbender installments. However, Fruit Ninja had the right combination of addictive and visceral gameplay to make it a virtual overnight success. For others dealing with a windfall of cash, Halfbrick Studio’s story is a good one to follow. Instead of tripping over their own feet after a massive growth spurt, the close-knit group of developers decided to focus on quality over quantity, avoiding the route companies like Zynga took (how many “___-ville” games can you name?). The developers said the success of Fruit Ninja has given them breathing room to perfect games they want to make.

The new Developer Economics survey is live – featuring thousands of developers all over the world! Join them now and voice your thoughts!

OMGPop (Draw Something)

Second in our list of successful game developers comes the OMGPOP team. A mobile gaming take on the classic pen-and-paper game of Pictionary, Draw Something is a study in how persistence can lead to huge success in the app industry. Before their top-selling drawing game took off, developer OMGPop had produced around 30 games that quickly fell into relative obscurity (do you remember Hamster Battle? No? Didn’t think so). A short time after Draw Something started topping charts relatively overnight, Zynga bought OMGPop for roughly $200 million, and the CEO of OMGPOP, Dan Porter, later went on to work for them as the vice president of their mobile division for a little over a year. Porter now continues to climb the corporate ladder and currently serves at the Head of Digital at William Morris Endeavor, the world’s largest diversified talent agency.

.GEARS Studio (Flappy Bird)

Not all overnight success stories end well as the tale of .GEARS Studio’s Flappy Bird shows us. Dong Nguyen’s creation was pulling in $50,000 a day—a veritable golden goose—making it one of the most popular games for smartphone users. However, a litany of complaints ranging from the game’s addictiveness, difficulty and resemblance to Super Mario 3 was too much for Nguyen to handle. Something about the fame mixed with user criticisms struck a nerve with the overnight app celebrity, who ultimately took down the game from app stores in mid-February 2014 without selling out to another company. It also begs the question—Was success too much for Nguyen, or was it all a stunt to generate interest for his next title?

King Digital Entertainment (Candy Crush Saga)

Image via Flickr by David Guo's Master — Image via Flickr by David Guo’s Master

Candy Crush Saga, produced by King Digital Entertainment, is one of the mobile gaming world’s most addictive releases yet. To capitalize on their virtual overnight success, King decided to try their luck on Wall Street by announcing their intent to file for an IPO, following Twitter’s example.

Rovio Entertainment (Angry Birds)

The Angry Birds franchise is the most successful smartphone game the world has ever seen. The series’ multiple installments have garnered over two billion downloads worldwide, but things weren’t always up for Rovio. It took them 51 tries on other apps before Angry Birds came around. Rovio’s strategy to deal with the success was simple—diversify. Expanding beyond the mobile platform, Rovio now produces Angry Birds clothing, books, cartoons, educational materials, movie franchise tie-ins, and more. They’ve even been eyeing the Hello Kitty franchise, looking for some indication in how they can expand their own enterprise.

Overnight success in the gaming industry is happening more and more everyday thanks to mobile technology. However, millions made in a night is no guarantee for smooth sailing. Developers soon discover they need savvy business acumen to stay afloat.

– Joe
Joe Fortunato is a tech writer based out of Tampa, FL. His extensive work for T-Mobile has afforded him the opportunity to explore many different avenues of the mobile world. App development, NFC technology, and new device specs are some of his favorite areas to cover. To get in contact with Joe, give him a shout on Twitter at @joey_fort.

If you are trying to hit the successful game developers list, then you first need to understand the Science of Mobile Game Marketing.

Which are your best and worst game development tools? Let us know and you might win amazing prizes and gear, in our Developer Economics Survey.

Tags Angry Birds, app monetisation, app revenues, Candy Crash, Flappy Bird, Fruit Ninja, OMG Pop

Tools

Finding the Right BaaS

Mobile apps — just like any other — need a place to store data. Fortunately, the industry’s push towards outsourced infrastructure (i.e., — “cloud” services) has had a profound impact on both the affordability as well as the availability of cloud-based data storage, often referred to as Backend-as-a-Service (BaaS), or Mobile-Backend-as-a-Service (MBaaS).

What is BaaS?

At its core, [tweetable]a BaaS provider typically enables you to store your data & interact with other critical services in normalized manner[/tweetable], without the headaches and cost of maintaining your own infrastructure. Cloud-based storage is just the beginning of a BaaS offering, though. Quite often, BaaS providers enable push notifications, integration with other social networks, user administration, custom business logic and more.

Which BaaS is Right For Me?

To determine which BaaS can work for you, you need to start with at least asking these two questions:

What platforms do I need to support? It’s common to expect to see SDKs for most major platforms — and usually an HTTP service layer fallback which nearly any client could easily utilize.
What features do I need?
- Storage (should be a given)
- Push notifications
- Usage analytics
- Dashboard/UI
- Social integration
- User Administration
- Custom Code Integration

The second question above really breaks down into all kinds of sub-questions, and by no means covers all the possible features you can find in a BaaS. [tweetable]It’s important to understand the needs of your app before selecting a BaaS offering[/tweetable]. So – what feature-specific questions may be helpful to ask as you analyze your needs?

Feature Analysis

Storage

While every BaaS provider will offer some kind of storage, there are wide variety of differentiating factors. Is the storage schema-less? What’s the search API like? Can you establish relationships between stored items? Can you query geospatial data (without 3rd party intervention)? Are changes pushed to connected clients, or do they need to re-query for updates? Does the BaaS support “data connectors” — allowing you to sync the cloud-based data to another system behind your own firewall? Where are the servers physically located (this can be a critical question to ask both for availability and regulatory reasons)? How difficult is it to export your data en masse should you decide to leave the provider for another option? What kinds of data can be stored — does it include files/binary data storage?

Push Notifications

If you’ve used a mobile app, odds are you are familiar with push notifications. Whether it’s a news app pushing breaking headlines, Twitter alerting you of direct messages or any number of possibilities — push notifications allow you to get important information to your users without the costs of other channels (SMS, for example) and without requiring your app to be in the foreground at the time. As most push notifications arise due to a change in data, it’s logical that many BaaS providers are including this as an offering. Good questions to ask: What platforms are supported (iOS, Android, etc.)? Will I get a consistent/normalized API to work with, rather than having to work with each platform-specific push notification API? Will I get the advantage of automatic scaling during periods of high demand?

Usage Analytics

Does the service enable you to track the number of API calls, storage quota or other feature usage? Since many BaaS pricing plans can vary based on usage, having a means to view analytics is a vital part of wisely (& economically) using the service. Depending on what metrics are tracked, usage analytics may also give you insight into how your app is being used. Does the service support custom “events” which you can provide to track either feature usage, performance data and/or campaign response(s)? Does the provider give you the ability to query the usage over time, filter the data and export reports?

Dashboard/UI

Does the provider give you an option to browse/search your data through some sort of portal or dashboard interface? Can you manage users or use a form to generate push notifications? Most BaaS providers have a web-based interface which you can use to manage your data, services and view reports.

User Administration & Social Integration

Many BaaS options provide built-in user management features. Does the service allow you to create users? Does it focus on role-based user permissions, or allow granular claims-based permissions? At what level can you restrict information — schemas/tables, records, fields? Your target users may not care to create yet another login in order to use your app. Does the BaaS provide integration with 3rd party authentication with sites like Facebook, Twitter, Google and others?

Custom Code Integration

It’s difficult to generalize to a common use-case, and still enable enough flexibility to users without giving them a means to inject custom logic for certain operations. Whether it’s validation, injecting a custom step, priming a cache or other needs, a good question to ask is your provider allows you the necessary hooks to inject your own code. Not only that — but what language(s) are supported?

Options?

Of course, knowing which BaaS options exist is important as well! Below I’ll share a few observations of the BaaS’s that I’ve had experience with to some degree, but this is by no means an exhaustive list. Check out a larger list of the tools we’re tracking in this space.

Parse

Parse was well known before it was acquired by Facebook in April of 2013, even more so after. It supports storing photos and geolocation data, 3rd party/social integration, push notifications and realtime usage analytics. The analytics are particularly impressive, in that they allow you to track custom events & types of devices, highly customized reports and more. Parse has an impressive array of client SDKs. Officially, Parse provides SDKs for iOS, Android, Windows, Windows Phone 8, Mac OS X, JavaScript and Unity (the cross-platform game engine). You also have the option of utilizing the HTTP REST API. Third party developers have created client libraries for .NET, ActionScript, Clojure, Java, Qt, Ruby, PHP, Python, WebOS and more!

Firebase

Firebase is a recent — and interesting — option in this space, focusing on a specific kind of use-case as opposed to larger, more general offerings like StackMob: realtime data synchronization. Multiple clients accessing the same data can see realtime updates (if you’re wondering about latency, it’s impressively low. To users, it will be instantaneous). Firebase also has a very flexible security model — including the ability for you to incorporate your own auth tokens or those from third party services. SDKs are available for JavaScript (both web clients and node.js), Objective-C (iOS) and Java (Android) and an HTTP REST API also exists. Realtime BaaS’s have interesting challenges in the areas of how they handle transactions and conflict resolution. Firebase is one of the first I’ve seen that provides the necessary hooks you need to inject conflict resolution logic without also dictating the client-side UI framework stack. In fact, Firebase provides officially supported integrations with AngularJS, Backbone.js and EmberJS (all client-side JavaScript frameworks). A number of third party libraries exist as well, extending Firebase client support to Python, PHP, Ruby, Clojure and Perl.

Telerik Backend Services

Telerik Backend Services (formerly known as “Everlive”) is another recent and feature-filled option. The backend storage is an object store, but you can create relationships between objects, upload files, store geospatial data (and query it comparatively to other locations for distance) and more. You can inject custom code — written in JavaScript – to be executed before or after items are created, read, updated or deleted. The user management features allow you to create users, assign roles, constrain permissions to resources and data, integrate with third parties like Facebook, Microsoft (LiveID) and Google or even your own corporate Active Directory. Telerik Backend Services support push notifications for iOS and Android, as well as email and SMS notifications. It’s worth noting that the management dashboard provides very easy-to-use tools to define schemas, manage users, create/edit data and test push notifications from within your browser. You also get usage analytics for database size, file storage, bandwidth used, push notifications and emails sent and HTTP requests.

StackMob

StackMob is one of the more well known names in this space – though their recent acquisition by Paypal will result in their services shutting down in May 2014. They directly support SDKs that cover iOS, Android, JavaScript & Java, and they expose an HTTP REST API for other clients as well. StackMob also benefits from an active community which has written 3rd party tools focusing on OAuth integration with other languages & platforms like PHP, ActionScript, Python and Sencha as well as an Appcelerator Titanium SDK.

StackMob has an impressive feature list. Their storage engine uses schemas which can be auto-generated for you based on your data, or you can use a dashboard they provide to define them. They support file storage if you have an Amazon S3 account (their services wrap the calls to Amazon). StackMob supports OAuth 2.0, as well as integration with Twitter and Facebook, and provides adequate user administration/permissions features (depending on your needs, you may need to elaborate if you need as granular as field-level permissions). You can upload custom Java, Scala and/or Clojure code and expose it via HTTP endpoints while having access to their data APIs from within your code. Another interesting feature is StackMob’s HTML hosting, which cannot only host your app, but also integrate with GitHub, enabling you to deploy your app based on what’s committed to the git repository.

So Much More Awaits

Those are only four examples — we’re tracking at least fifty BaaS offerings, and it seems more options appear nearly every month. Are you using a BaaS provider now? We’d love to hear which one(s) and what features drove your decision in the comments below.

Tags baas, mbaas

Tools

Which App Stores Should You Use?

Post author By Mark Wilcox
Post date March 18, 2014
No Comments on Which App Stores Should You Use?

Publishing your app in a store can involve significant effort. Depending on your goals some app stores can be more attractive than others. If you’re looking to earn direct revenue from your apps, which are the best stores to target? What follows is some general advice backed up by data from our latest survey.

To publish, or not to publish?

If you only want to build an app as a hobby, first consider whether you need to publish it on a store at all, or whether you can just share it privately with interested parties. There are more than enough apps already in the stores and the poor developers trying to make a living from their apps have to contend with a lot of noise in the very basic search results as it is. If reaching an audience is an important part of your hobby creation then building an Android app and publishing on Google Play is the obvious option. It’s low cost, there are few rules and there’s a very large user base.

Apple is where the money is

If you’re building an app to generate revenue directly then an iOS app on Apple’s App Store is still the best option initially unless you’re only targeting countries where the platform has very low market share. Even with an ad-supported revenue model, the larger user base on Android is usually more than compensated for by better engagement and higher rates on iOS. When aiming for reach then the most important thing is to match the target demographics with those of the platforms. In most cases you’ll want to target both iOS and Android.

These are the common cases and this is fairly common knowledge. As such you can see it reflected in the overall popularity of the various stores below.

If you already have an app published on one or more stores, the decision to add it to another is not always an easy one. Even if you don’t need to port your app to a new platform to access a new marketplace, you still need to learn about the publishing process, create (and usually pay for) an account, publish the app and future updates and monitor reviews and visibility within the store. If the audience using the new store won’t be reached by your existing marketing efforts you may have to expand those as well.

More stores = more money?

Looking at the average revenues of developers based on how many stores they publish on, it’s tempting to think that publishing to as many stores as possible (and thus using a cross-platform development tool) is the way to go.

However, this is getting causation backwards. There is an improvement in revenues for almost anyone adding more potential customers but looking at the median rather than mean we can see this is unlikely to cover the cost of managing the app across several extra stores. What we can really see here is successful apps tend to port to more platforms and so [tweetable]it’s apps that already have high revenues that then publish in additional stores[/tweetable]. There is also a [tweetable]higher than average proportion of developers working on a contract basis who publish to five or more stores[/tweetable], which pushes the median revenue up.

The same phenomenon causes the average revenue of all developers who publish in a particular store to be very misleading. Developers publishing in the smaller stores often already have successful versions of the apps on the leading platforms, or are simply contracted to port those apps. If we split developers by the number of stores they publish on and look at revenues by platform then the differences become clear.

Where to publish next?

Looking at developers who only publish on a single store, [tweetable]Apple’s App Store is far ahead of every other store except the Amazon Appstore[/tweetable]. However, the number of developers who only publish to Amazon’s store is extremely small (only 16 in this sample) so this figure is not reliable. That said, [tweetable]developers who publish in Amazon’s store and one other are far more numerous and have high average revenues[/tweetable], plus data from Distimo suggests that some Android developers are seeing significantly better revenues from Amazon than from Google Play.

If we consider those publishing to two stores then Apple leads with Google in a clear second place, while Amazon still shows relatively good revenues. The other interesting data here is “where do BlackBerry developers go” – those publishing to BlackBerry World are much more likely to have Google Play or the Windows Phone Store as their second store than others. Only 11% of developers publishing to BlackBerry World and one other store also publish to the Apple App Store. That’s somewhat surprising given BlackBerry’s previous dominance of the enterprise market and that iOS is now taking over in that space.

When developers publish to four or more stores we see a significant jump in revenues for those publishing to the Windows Phone Store. Since the revenues for those who only publish to that store are so low, it seems unlikely that it’s revenues from Windows Phone itself creating the difference. More likely is that Microsoft and Nokia have been providing incentives for the most successful apps to port to their platform. Microsoft’s Windows Phone platform is strongly differentiated from the others. Developers have to design a new UI and generally build it with different technology in order to target the platform. The associated costs are much higher than adding another Android or web-based platform’s store. As such, at similar scale to many alternatives, Windows Phone is unlikely to produce a good return on investment unless Microsoft provides a strong financial incentive.

Conclusion

For developers not looking for direct revenues, an Android app on Google Play is probably the obvious first choice. For those who are looking to monetize their apps directly, Apple’s iOS App Store is the clear leader, with Google Play as the first place to expand after that. BlackBerry World appears to be very unattractive versus the other options from a revenue perspective. Beyond that, the Windows Phone Store seems to be more popular than it deserves (although this might be due to ports paid for by the platform owner) whilst the Amazon Appstore seems unfairly unloved. Some developers have had issues with Amazon’s developer agreement and pricing policy but the results of those using Amazon’s store suggest it’s worth another look.

Tags app monetisation, app revenues, app stores, Google Play

Languages

App Security 101: A list of top 10 vulnerabilities and how to avoid them

Post author By George Karagiannidis
Post date March 12, 2014
No Comments on App Security 101: A list of top 10 vulnerabilities and how to avoid them

App development is becoming more and more popular, as web and software developers are migrating to the mobile industry. Apps have become a part of mainstream culture and entered our everyday lives – at increasing levels. The app economy is comprised of approximately 2 million apps and is expected to continue growing in the years to come.

Secure development on mobile applications, however, has not shown the same level of growth or maturity. As an Information Security firm, we’ve seen quite a few apps suffer from vulnerabilities that are linked to development bad practices, mainly due to lack of awareness. Secure development guidelines do exist in the community, while organisations like OWASP have accumulated a lot of experience in the field and are now offering much of this knowledge for free. In this article we’ll sum up the best practices and show you the best ways to build secure apps. We’ll concentrate on OWASP top 10 (and similar) vulnerabilities, as these are the most common ones found in mobile apps.

So, let’s go through the list of the top 10 mobile app vulnerabilities and how to avoid them.

1. Insecure Data Storage:

This vulnerability occurs because information that is considered confidential is not stored in the device in a secure manner. You shouldn’t assume that the devices themselves are safe. Devices can be stolen and/or tampered with, and the confidential data contained in them may be stolen. Also, you shouldn’t assume that users will protect themselves against this possibility. In order to avoid this vulnerability, the best practices are:

Never store credentials on the device itself
Sensitive information such as user authentication credentials should only be stored in the device’s keychain, using the necessary API
~~All authentication should be done through HTTPS~~ (updated)

Specific guidelines for iOS developers:

You could avoid using iOS Encryption Libraries such as Commoncrypto
You should encrypt SQLite databases with SQLcipher
You might want to avoid NSUserDefaults, as well as plists in general
Keep in mind that the NSManagedObjects will be stored in an unencrypted database

For Android devs:

You should use the SD Card Storage the javax.crypto.
You can use the enterprise Android administration API to force encryption for local files by utilizing “setStorageEncryption”

2. Weak Server Side Controls

You should implement most controls against input attacks on the server side of the application. Nevertheless, app design should include input validation checks and controls, in order to reduce the load of work to be done by the server. Therefore, you could ensure that both the server side and the mobile client development security requirements include at minimum:

Input validation. You can use this kind of data validation in order to detect, and therefore prevent, unauthorized input before it gets processed by the app itself
Canonicalization. Data input in the app should be converted to its canonical (simplest) form in order to be processed by it
White lists on allowable data. The white list validation approach allows only specific types of data as input to the application; everything else that’s not included in this list, is not authorized.
Output encoding. You should encode the output that is presented to the user in order to prevent different kinds of attacks (e.g. XSS[1][2], format string attacks).

3. Insufficient Transport Layer Protection:

You should enforce the TLS/SSL encryption with strong algorithms between communications. A common development mistake is unencrypted connections from the application to 3d party companies. You should program your apps to display any certificate error or warning messages, so that the user is informed of the quality of the encrypted connection.

For iOS developers:

Use the CFNetwork API that utilizes NSStreamSocketSecurityLevelSSLv3 / TLSv1.2.
You should use,the setAllowsAnyHTTPSCertificate parameter to prohibit accepting all certificates

For Android developers:

You should set the AllowAllHostnameVerifier parameter to prohibit accepting all certificates

4. Client Side Injection

This category is comprised of a wide variety of input attacks against the application itself. General best practices for mitigation of client side injection vulnerabilities include the input validation of the application entry points, on the server side.

For iOS developers:

You should consider using parameterized queries (e.g. ? instead of %@, libXML2 instead of NSXMLParser)
In addition, you should avoid functions that are known to be prone to code vulnerabilities, such as strcat, strcpy, etc.

Android developers:

You should use parameterized queries
You should disable Javascript and plugin support for Webviews
You should also disable file system access for Webviews
You might consider using input validated intent filters between Activities

5. Poor Authorization and Authentication

These vulnerabilities are controlled mostly on the server side. The best practices that you should follow are the same with web applications. In addition to these rules, specifically for app development, device identifiers should be avoided (UDID, IPs, MAC Addresses, IMEI) since devices can be stolen and tampered with. Finally, out-of-band authentication tokens should not be sent to the same device.

6. Improper Session Handling

Although session handling mechanisms are mainly applied at the server side of the applications, secure session management practices can be applied at the devices themselves. As with the Authorization and Authentication, you should apply the web application Best Practices for session handling. Same as with authorisation and authentication best practices, device identifiers should be avoided here as well and you should implement safe mechanisms to revoke session on lost/stolen devices. Finally, the Confidentiality and Integrity of session tokens should be protected at all times (secure transmission via SSL/TLS connections, etc).

7. Security Decisions Via Untrusted Inputs

While these issues mainly affect Android-based applications, there has been precedent for iOS apps too. In general, the Best Practices that you should follow are the same with the web application ones. Specifically, input validation, output escaping, authorization controls and canonicalization should be carefully examined. Also, you should exercise extra caution when validating and accepting URL schemes.

8. Side Channel Data Leakage

This category involves data exchange that usually enhances app performance (e.g.: keystroke logging, web caches). As with Insecure Data Storage, you should build your app under the assumption that the device might be stolen. All side channels and 3rd party libraries included should be identified and enumerated for any possible data leakage that might occur. The application should be dynamically tested in order to verify that it doesn’t leak data during runtime.

iOS developers:

You might consider disabling screenshots, along with cut-and-paste buffers. It is also recommended to disable keystroke logging from within the application.

9. Broken Cryptography

Crypto-keys should never be hard-coded in any construct (plaintext, property files, compiled binaries) and should be controlled at the server side.

10. Sensitive Information Disclosure

Different kinds of information may be considered sensitive in an app, as application logic/business purposes define that. You should keep mind that apps can be reverse-engineered and information like this might be exposed. The best practices in this case suggest avoiding storing private data inside the device; unless absolutely necessary.

The vulnerabilities presented here are not an exhaustive list – they’re just the tip of the iceberg! During the past year, we’ve witnessed numerous attacks against apps by direct code exploitation that usually leads to the device becoming compromised. We’ve also seen attacks that leverage various app weaknesses in order to hijack legitimate user sessions and steal information and money.

Since the app market is constantly growing, we expect to see an increase in the number of attacks against mobile devices themselves. So, if you want to keep up with the times, [tweetable]you should build your next apps with app security in mind[/tweetable].

For more insights, get in touch.

– George

George Karagiannidis is a Senior Information Security Consultant at TwelveSec (TwelveSec.com). George is a seasoned pen-tester, having accumulated a wealth of experience from performing, as well as leading, Information Security projects that range from System/Network/Web/Mobile Application Penetration Tests to Reverse Engineering, Security Design and Architecture of critical Information Systems, and Information Security Management System (ISMS) implementation.

Tags android, ios, owasp, Security, ssl, vulnerability, xss

Business

Mobile Gaming’s Dirty Secret

Post author By Mark Wilcox
Post date March 5, 2014
No Comments on Mobile Gaming’s Dirty Secret

Mobile gaming is a major growth industry. Revenues and profits are soaring and the most successful companies are attracting valuations in the billions of dollars. However the market dynamics are such that very few can succeed and those that do have incentives which are a long way from maximising fun for players. Where are all the revenues coming from? Is the market fundamentally broken? If so, why aren’t the platform owners trying to fix it?

Spectacular Growth

[tweetable]In 2013, games accounted for around 40% of all app downloads across the iOS App Store and Google Play[/tweetable] but approximately 75% of the revenues (according to App Annie). Game revenues more than doubled year over year on the App Store and more than quadrupled on Google Play. By the end of 2013, revenue from games on Google Play was still only about 60% of the iOS App Store equivalent. Since Apple had $10 billion in App Store sales in 2013, we can estimate very roughly that [tweetable]there were around $10 billion of games revenues across the two stores[/tweetable]. This is not far from Gartner’s estimate of $13.2 billion for all mobile games in 2013, projected to rise to $22 billion in 2015.

Increasingly Freemium

According to Distimo 90% of all games revenue on the iOS App Store came from free apps with in-app purchases in November. The percentage of revenue attributable to freemium apps in the entire store grew from 77% to 92% across the year. [tweetable]On Google Play 98% of all revenue was generated by freemium apps in November[/tweetable], so the games revenue there clearly favours the freemium model to an even greater extent than on iOS.

Now there are very good arguments that all successful digital content will eventually use some kind of freemium model, here’s a good recent summary. However, there’s a special subset of freemium that’s really generating all the growth and revenue, so called free-to-play games selling virtual goods (e.g. coins, gems, lives). Only a small fraction of users pay at all, only 1.5% according to Swrve, then a fraction of those pay so much more than you could ever get for a paid download or unlocking levels that the average revenue per user (ARPU) is higher than all other models – at least when the game mechanic and purchases are well designed to optimise for this behaviour.

Winners Take All

The games with a combination of high ARPU and broad appeal (so they get high conversion rates on user acquisition spending) can afford to bid the most for new users, squeezing others out of the best user acquisition channels. This creates a feedback cycle with the store charts, bringing in even more users organically. Our Developer Economics survey data confirms this: the typical games developer monetising via freemium and in-app purchase business models makes only about twice as much on average as those using the roughly equally popular paid download and advertising models. This difference is nowhere near enough to account for the highly skewed revenue distribution in the app stores. A large fraction of the total revenues are being made by a handful of top publishers.

Who’s Paying, How Much and Why?

Up to this point it sounds like the industry has hit on a fantastic profit formula to be emulated by all. However, if you look at the numbers and their implications then things start to look a little darker. Of the 1.5% of players who pay anything for their “free” games, 10% of those account for more than 50% of the revenue (see Swrve report above). Indeed just 1% of paying players, that’s 0.015% of all players, account for 13% of revenue; contrast with 11% of revenue from the bottom 50% of payers. Even with the astronomical size of mobile user bases, some basic arithmetic suggests the top 1% are spending more than $10k a year each on these games, even the top 10% are spending hundreds of dollars.

The free-to-play games industry likes to call these high spending players “whales” after the high rollers in the casino industry. However, high rollers only account for a small fraction of revenues in the gambling industry and they have a very real chance of winning big too, even if the odds are tipped in the favour of the casino. A better analogy from the gambling industry would be the slot machine addicts who generate a large fraction of the revenues. In fact, these mobile games are designed to be “addictive” it’s just that for some players the addiction becomes very real and they lose all rational control of their spending. So rather than hunting for the high-spending whales, this part of the industry is really exploiting vulnerable digital narcotic addicts.

If you want to see an example of what that looks like in real life, read the New York Times interview with George Yao, a long time top player in Supercell’s Clash of Clans. He spent $3k of his own money on the game in 3 months before wealthy clan mates started to bail him out. At one point he was taking 5 iPads into the shower with him to help maintain his ranking. In his own words about the experience:
“Looking back, I think I must have been insane,” he told me, with a mix of pride and revulsion. “I was so immersed in it at the time. I knew it was abnormal, but never to the extent that I see it now.”

What Next?

Apple and Google could easily stop this with some sensible limits on monthly IAP spending per app. That could cut off billions in revenue through the stores of which they take a 30% cut. However, the revenue itself is not that significant to either business. More important are the headline revenue and growth figures enabled by this that maintain developer interest in the platforms. As such we’re likely to see external regulatory action before any strong voluntary action on the part of the stores. Apple have already created the Kids section in their store which has extra review criteria to protect children from IAP and targeted advertising but they’re not currently doing anything to stop apps targeting children with purchases that aren’t attempting to list in this new “safe zone”. In most countries, children are not the only consumers protected from questionable business practices. The EU has just announced meetings with the app industry to discuss consumer protection issues – this is likely to repeat elsewhere until the real cost of “free-to-play” games is made more clear to consumers.

If you are interested in Business Models in Mobile Gaming, have a look at the three part series on battle insights by a mobile game CEO.

Tags app monetisation, Clash of Clans, Flappy Bird, mobile gaming, Supercell

APIs

Mapping it out: APIs for location-based apps

Post author By Richard Bloor
Post date February 24, 2014
No Comments on 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 ¹. 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 Satellite Hybrid	Map Satellite Hybrid Terrain	Map Satellite Hybrid Terrain 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)²
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
ARLab – AR 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.

Footnotes

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

Tags gps, location