Categories
Languages

Is HTML5 about to make a comeback?

The web is losing and apps are winning. At least that’s what the most recent data from Flurry says – 86% of time on mobile devices is spent in an app other than the browser, up from 80% last year. Does that really mean the web is losing? What about apps built with HTML5? Is the implementation technology more important than the distribution mechanism? Why should anyone care? A number of new tools and frameworks are maturing that should make it much easier to build great mobile sites and apps with HTML5. Could they stop the shift from web to native apps, or even reverse it?

is-html5-about-to-make-a-comeback-650px

Why the web is losing on mobile

Modern web browsers and standards were designed for a desktop computing environment and they built upon a base that was designed for sharing linked documents. Mobile computing environments have capabilities and constraints that desktops don’t. Native mobile app platforms were designed for building highly interactive, animated, apps utilising hardware graphics acceleration. The result is that apps running in a mobile browser are disadvantaged in terms of performance, user experience and access to device functionality versus their native counterparts.

The app is the new browser bookmark. People have favourite services and sources of information or entertainment even though a great deal of substitution is possible in most cases. Providers have to compete on user experience and that creates a bias towards native apps. You want to check the weather every day? You don’t search for a weather forecast every time, or find a favourite weather site and bookmark it, you download a weather app. Need to catch up with your friends on a social network? You don’t open the browser, type a URL or go to a bookmark and wait for the latest updates to download, you get update notifications pushed to you by the native social network app, or when you open the app it has already downloaded the latest content in the background. For frequently accessed apps, the native versions have much less friction, as well as a nicer user experience.

What about hybrid apps?

Delivering a web app in a native wrapper allows it to access device functionality and reduce some regular usage friction. However, it doesn’t fix performance (indeed on iOS it makes it worse), nor make it easier to deliver a great user experience. Another problem with delivering a packaged web app that uses a system WebView is that the functionality of the WebView itself can change with OS updates. Android recently switched to a new Chromium-based WebView and broke or crippled lots of hybrid apps. The flip-side to this problem is that WebViews upgrade slower than browsers; on Android the WebView is currently tied to OS upgrades (which are still lacking from most manufacturers) while the Chrome browser continuously auto-updates. This means it’s a long time before it’s feasible to start using new standards added to the browser specifically to tackle mobile issues. A hybrid app is also still subject to app store reviews and policies. It may be possible to update functionality without an app update in the store but the platform owner still controls what developers can and can’t do.

Another popular complaint about hybrid (and native) apps is the loss of ability to cross-link versus the web. I believe that Facebook’s recent App Links project puts all native apps (including hybrids) about on a par with web apps here. It may be possible to link to any web page but many modern web apps only have a single page. What’s actually needed with a web app rather than a web site is the ability to link to app states. This is only possible if the developer enables it by setting up routing for URLs to app states – native apps can already do this and App Links solves the “what if the app isn’t installed” problem with web fallbacks or store links. If platform providers enhance app interoperability then native (and hybrid) apps could significantly exceed the capabilities of the web here.

Engagement versus ease of access

As discussed above, any content or services you access frequently create less friction by providing native apps. Less friction enables more engagement and a virtuous cycle of greater usage. On the other hand, new or infrequently accessed content and services have extremely high friction if you need to download an app before you can do anything else. Here the web has significant advantages over native apps. The companies who really don’t get this are the ones that have a full screen popup asking you to download their app every time you visit their website on a compatible device! Another way to look at the Flurry stats linked at the top of the article is this: exclude games (which have almost always been native for performance) and social networking (which falls firmly into the frequent access category, plus a lot of the time will be using an in-app browser anyway) and the browser still has more than a third of the remaining mobile usage time. That doesn’t sound quite so bad.

New frameworks fill the gaps

With the threat of being relegated to the “infrequently accessed” category of apps, the web development community has not been sitting around doing nothing. A new framework recently into public beta, famo.us, attempts to solve the major performance problem for animated web app UIs. Their current approach is a series of clever hacks involving minimal manipulation of a very flat DOM structure. However their JavaScript APIs will also render to WebGL in future (when it’s sufficiently widely available, ahem, Apple). The approach is promising and the demos are impressive. Currently their homepage (on both my retina iPad Mini and Nexus 4) kinetic scrolls with a stutter that makes my 2006 Symbian device look slick, so there’s a way to go before they’re ready to come out of beta. Note that using Famo.us JavaScript APIs starts to make building web apps look more like creating a native app.

Another framework close to its 1.0 release is Meteor, a new way to create real-time web apps very rapidly. They fix common issues with the responsiveness of web apps out of the box – having to poll the server for new data and wait for it to update the UI after user interaction. The latter is achieved with a technique called latency compensation (UI is updated with local data immediately, then fixed if the server returns something different). The former is down to having long-running bi-directional connections between client and server rather than a more traditional RESTful API. Meteor actually supports native client apps too but with the ease of creating the web front end it would be unusual for developers not to have both web and native options if they go down that route.

Although there are lots of new and interesting frameworks in development I’ll highlight just one more that’s in a fairly mature beta stage. Ionic is a framework designed specifically for building hybrid apps. It’s built for performance and to provide common UI components and interactions out of the box so it’s easy to make an app with a native feeling user experience. The default styling is very similar to, although deliberately not exactly like, iOS 7. The major disadvantage to this approach is that while it works on recent iOS and Android versions you lose the broader cross-platform and device compatibility. It’s not for building mobile websites or desktop web apps. As such Ionic is building on HTML5 purely as an implementation technology and abandoning the browser. However, as it’s still running in a WebView developers retain the privileged position of being allowed to download new code on iOS.

Native user experience

I listed performance and user experience as two separate issues for a good reason. Despite all the great efforts at resolving performance issues for web apps, native user experience is not just about performance. For some apps it’s natural to take over the full screen and provide an immersive user experience. Games fall into this category, unfortunately they’re also the category of app most in need of full native performance. The majority on non-game apps use some standard platform components and need to follow platform user experience conventions. This makes it easy for users to learn how a new app works; navigation and controls work in the same way as most of their other apps. In this sense when we say “native” user experience we mean aligned with the platform culture and conventions rather than compiled to native binary code. The folks at Ionic are right not to mimic iOS 7 too closely. The more native looking an app’s UI, the more users will expect it to behave exactly like one (and get frustrated when it doesn’t always). A phenomenal amount of effort is required to make an app look and feel just like a native one when it’s not actually using native controls. Even if this can be achieved, the platform will change and the app won’t, making it stand out like a sore thumb until it can be updated (again at significant effort). This is an issue for all cross-platform environments that have their own rendering engine rather than wrapping native controls.

What the technology wants

Marc Andreessen famously said that the eventual application model on mobile will be the web application model, because the technology wants it to work that way. Having every app stored on a remote server and the latest version always updated to the device when it becomes available is a superior model to downloading and periodically updating local apps. This technological advantage applies almost equally to hybrid apps, assuming the native wrapper rarely needs changing. Native apps that automatically update is a step in the right direction but doesn’t aid lean development practices like split testing and continuous deployment. The latter are so valuable in figuring out what to build quickly that there are plenty of entrepreneurs and businesses out there who would build mobile apps with the web model if they were good enough for their customers.

The next wave?

Consumer apps that don’t have highly desirable unique content or features are going to have to compete on user experience for the foreseeable future. For most that will mean native apps. However, building native apps is significantly more expensive than building cross-platform web apps. Not all of the people who pay for apps are going to prioritise user experience. The next generation of software for large enterprises right down to small businesses is going to need a much better user experience than the last but the current state of web technology is probably good enough.

Revenues from consumer mobile software may look quite attractive but the bulk is in Free-to-Play games and is highly concentrated amongst a handful of publishers. The majority of the growth in that market is in Asia. A more interesting opportunity for many developers may be the only slightly smaller but faster growing Software-as-a-Service (SaaS) market for businesses. As mobile devices become increasingly essential in our work lives as well as our personal lives, maybe we’ll see more of that total usage time in business and productivity apps.

Conclusion

So, is HTML5 about to make a comeback? In a way. If the first wave of mobile computing adoption was primarily about consumers, the next wave will see many more businesses getting serious about using mobile devices to enhance productivity and collaboration. I suspect the use of HTML5 in business apps to be much more successful than in the consumer space. Possibly we’ll see a return to the browser but for now the hybrid app looks more likely. General purpose business apps like time and resource tracking or project management will have large enough user bases to justify native client apps, although of course they’ll need web access too. The more specialised the app, the more likely it is to be a hybrid app than a fully native one.

Categories
Platforms

Which top platforms are easiest to develop for?

In the mobile software world, developers are considered vital to the health of platforms, of which they have several to choose from. Platform owners have to work very hard to make sure their SDKs and tools are easy to use. Too much friction, too little documentation or too steep a learning curve can drive developers away. Which platforms are the easiest to develop for? More importantly, does ease of development translate into popularity? Or is it just a hygiene factor?

platform

A lesson from history

Mobile platforms have not always tried to make things easier for developers. Before the iPhone, Symbian dominated the smartphone market and had a policy of making developers jump through hoops to ensure both the resource efficiency of apps and the security of the platform. Nokia tried to add a developer friendly layer on top of the OS with Qt but it was too little too late to capture developer attention, even with an existing large installed base. So, a terrible developer experience can ruin a platform’s chances but does greater ease of development lead to success?

Interpret with caution

In our last developer economics survey we asked developers how easy it was to use a common set of APIs on their primary platform. Before diving into the data, there are some caveats:

  1. Comparison between platforms is slightly unfair because the API categories are broad and not all platforms will enable access to the same level of functionality
  2. Not all developers target multiple platforms, so some do not have a good basis for determining ease of use (although purely subjective ratings are still valid for comparison)
  3. The APIs that were included in the survey primarily focus on native functionality, so this comparison in somewhat unfair on HTML5
  4. The APIs do not include UI functionality and building the UI is a significant part of the work in most mobile apps.

Bearing those points in mind, below is what developers think of their platforms.

Easy != Popular

Our data shows that the challenger platforms, BlackBerry 10 and Windows Phone are the easiest to develop for, with BlackBerry 10 having a slight lead. In the middle are the leading platforms, iOS and Android, with iOS fractionally easier to develop for overall but with Android having several APIs where it leads.

In a distant last place we have HTML5, suggesting that it’s still very difficult to build apps that take advantage of uniquely mobile features with web technologies. In this regard it’s interesting that the recently appointed CTO of Mozilla, Andreas Gal has this to say:

“For Mozilla, anything that the Web can’t do, or anything that the Web is not faster and better at than native technologies, is a bug. We should file it in our Bugzilla system, so we can start writing a patch to fix it.”

There appear to be a few more entries for their Bugzilla system above. Web technology has matured a long way and makes it very easy to develop web sites across a wide range of screens – mobile apps are not the same thing and pose a different set of challenges.

To answer the question we posed at the beginning, it seems that ease of development is mostly a hygiene factor. The top platforms are not the easiest to develop for. BlackBerry 10 seems to have surprisingly high levels of continuing loyalty amongst developers despite the very poor sales for the platform to date, so perhaps there is some value in creating an environment developers really love to work with rather than one that is simply not painfully difficult.

The next frontier?

As we move towards a world of connected sensors everywhere and wearable devices are being hyped as the next big thing, an interesting sidenote is that Bluetooth was rated as the hardest API to use by developers across all platforms. After years of failing to reach its potential, Bluetooth is emerging as one of the key technologies enabling smartphones to talk to wearables and other external devices without sufficient power to maintain their own permanent internet connection. Perhaps this is an area for all platforms to consider revisiting, or an opportunity for an Internet of Things platform provider to abstract away the details.

Categories
Business

How much does it cost to create a successful app?

The app stores contain a range of apps from hobbyist creations built for fun to the carefully crafted output of venture backed startups and mega-corporations that have had millions of dollars spent on their development.

05 App Profit & Loss 2014

Even though the market is maturing and exceptionally well-funded developers have taken over the store charts, the occasional small independently developed app that goes viral can still break through and achieve a decent level of success. The question is, how likely is a small budget developer to succeed? What platforms give them the best chance of success? Where should the budget be spent? With all the competition out there, how much does a bigger budget improve your chances of turning a profit?

What are the odds?

In order to look at how budget can impact profitability it’s worth calibrating by the average chances of making a profit on each platform.

The figures in this chart are probably more positive than most industry observers would expect. Looking at the data it seems likely that many solo developers have valued their time at zero when reporting costs. For hobbyists and explorers, working in their spare time this might make rational sense. They don’t expect to be paid for the time anyway and their small app profits more than cover their other development costs. This is reflected in the slightly lower level of Android developers losing money versus iOS (there are far more hobbyists on Android than iOS).

Leading platforms

On the most popular platforms – iOS, Android and HTML5 – there’s a general correlation between spending more on an app and making more revenue. However, not all spending produces equal results. Spending more on development only slightly increases the chances of making a profit, while increased spending on design and marketing are strongly correlated with higher probability of making significant profits. Higher spending on customer service is almost always associated with greater profit probability but here the causation is almost certainly in the other direction; successful apps incur greater customer service costs because they have a lot of customers! These platforms show very similar patterns but they aren’t identical. The biggest difference between them is that spending more on design for HTML5 apps seems to produce much less of a boost to profit probability than for either of the leading native app platforms.

The second tier

BlackBerry 10 and Windows Phone show similar patterns of spending versus profit probability that are very different from the leading platforms. For small amounts of spending, there are similar patterns to the leading platforms. More investment, greater chance of a profit, with better returns from design and marketing spend. However, before reaching a level that would sustain a full-time designer or developer, the trend reverses; investing large amounts in any aspect of apps for these platforms reduces the probability of a profit and increases the chances of making a loss. This suggests that these platforms have not yet reached sufficient scale in terms of app revenues to sustain many highly complex or polished apps.

Opportunities everywhere

On the leading platforms, developers with budgets in the multiple thousands of dollars a month have roughly twice the chance of turning a profit on their apps as those spending minimal amounts. Even at lower spending levels, the probability of breaking even or better is reasonably high across all platforms, particularly for those investing in design and marketing. While it’s clear that only some of the platforms discussed above are likely to support scalable app businesses at the moment, there are plenty of opportunities to build profitable apps on any these top 5 platforms.

Want to know more?

I’ve only scratched the surface of our data here. What scale of profit or loss can be expected on different platforms with different levels of investment? Are there optimal investment levels to maximize the chances of success? Which app categories are most likely to product a profit. What do successful app development companies look like at different sizes? All this and more is covered in our App Economy report.

Categories
Platforms

Which top platforms are easiest to develop for?

In the mobile software world, developers are considered vital to the health of platforms and they have several choices. Platform owners have to work very hard to make sure their systems are easy to develop for. Too much friction, too little documentation or too steep a learning curve can drive developers away. Which platforms are the easiest to develop for? Does ease of development translate into popularity? Or is it just a hygiene factor?

A lesson from history

Mobile platforms have not always tried to make things easier for developers. Before the iPhone, Symbian dominated the smartphone market and had a policy of making developers jump through hoops to ensure both the resource efficiency of apps and the security of the platform. Nokia tried to add a developer friendly layer on top of the OS with Qt but it was too little too late to capture developer attention, even with an existing large installed base. So, a terrible developer experience can ruin a platform’s chances but does greater ease of development lead to success?

Interpret with caution

In our last developer economics survey we asked developers how easy it was to use a common set of APIs on their primary platform. Before diving into the data, there are some caveats:

Comparison between platforms is slightly unfair because the API categories are broad and not all platforms will enable access to the same level of functionality
Not all developers target multiple platforms, so some do not have a good basis for determining ease of use (although purely subjective ratings are still valid for comparison)
The APIs that were included in the survey are biased towards native functionality, so this comparison in somewhat unfair on HTML5
The APIs do not include UI functionality and building the UI is a significant part of the work in most mobile apps.

Bearing those points in mind, below is what developers think of their platforms.

Easy != Popular

Overall we can see that the challenger platforms, BlackBerry 10 and Windows Phone are the easiest to develop for, with BlackBerry 10 having a slight lead. In the middle are the leading platforms, iOS and Android, with iOS fractionally easier to develop for overall but with Android having several APIs where it leads. In a distant last place we have HTML5, suggesting that it’s still very difficult to build apps that take advantage of uniquely mobile features with web technologies. In this regard it’s interesting that the recently appointed CTO of Mozilla, Andreas Gal has this to say:

“For Mozilla, anything that the Web can’t do, or anything that the Web is not faster and better at than native technologies, is a bug. We should file it in our Bugzilla system, so we can start writing a patch to fix it.”

It looks like they still have a lot of work to do! Web technology has matured a long way and makes it very easy to develop web sites across a wide range of screens – mobile apps are not the same thing and pose a different set of challenges.

To answer the question we posed at the beginning, it seems that ease of development is mostly a hygiene factor. The top platforms are not the easiest to develop for. BlackBerry 10 seems to have surprisingly high levels of continuing loyalty amongst developers despite the very poor sales for the platform to date, so perhaps there is some value in creating an environment developers really love to work with rather than one that is simply not painfully difficult.

The next frontier?

As we move towards a world of connected sensors everywhere and wearable devices are being hyped as the next big thing, an interesting sidenote is that Bluetooth was rated as the hardest API to use by developers across all platforms. After years of failing to reach its potential, Bluetooth is emerging as one of the key technologies enabling smartphones to talk to wearables and other external devices without sufficient power to maintain their own permanent internet connection. Perhaps this is an area for all platforms to consider revisiting, or an opportunity for an Internet of Things platform provider to abstract away the details.

Categories
Business

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?

Revenue_Models_FINAL

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.

Categories
Business

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.

03-A-guide-to-building-your-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.

Categories
Tools

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.

app-stores-you-should-use

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.

Categories
Business

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?

Mobile Gaming's Dirty Secret

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.

Categories
Business

App monetisation tip: Go for niche markets, not user reach

Mobile apps have enabled some developers to reach unprecedented scale in an incredibly short time. The companies that do this best have hundreds of millions of users and are typically valued at billions of dollars. The winners in this battle for mass market attention and appeal are either backed with millions of dollars in venture capital or created by companies already worth billions. Can developers without quite so many resources behind them achieve a smaller scale of success by following the same formulas, or might targeting a smaller niche achieve better results?

VisionMobile

Categories
Business

The Android Monetisation Myth: iOS still rules the west

[tweetable]Revenues from Android apps saw tremendous growth in 2013[/tweetable]. If you look at the headline global figures then revenues from Android apps on Google Play are rapidly closing on those from iOS apps on the App Store. It looks extremely likely that 2014 is the year that Android will overtake iOS in total app revenues. However, dig a little deeper and you’ll find the distribution of revenues, both geographically and across apps is rather different. If you’re planning your platform strategy for this year then a dive into the details might prove invaluable.

Almost a year ago, I wrote about two important app market trends to watch in 2013, which were continued growth of app revenues (they’re still growing, Android significantly faster than iOS) and revenue distribution (it’s getting even more concentrated at the top). According to Distimo:

“On a typical day in November 2013, we estimate the global revenues for the top 200 grossing apps in the Apple App Store at over $18M. For Google Play, our estimate is about $12M. In November 2012, these estimates were at $15M for the Apple App Store and only at $3.5M for Google Play.

That’s 20% annual growth at the top of the market for iOS and just over 240% annual growth for Android. Add to that there are also alternate stores for Android that have been growing revenues too. These figures and relative growth rates make it seem as if Android is the place to be in 2014. It might be, if you can make it to the very top. If we look at AppAnnie’s report for a similar period, they estimate that total iOS App Store revenues roughly doubled year over year*, while total Google Play revenues were a bit more than triple their year ago levels. So although Apple seems to be improving the revenue distribution slightly, it’s getting even more concentrated at the top of the market on Android.

Even the wider distribution of revenues on iOS may not be quite as good as it looks when we also consider geographic spread. Although the US is still the top revenue earner for iOS, the bulk of the growth is in Asia, particularly China and Japan. The top grossing charts in these countries look very different from the global top grossing apps and this may account for much of the widening range of high revenue apps. [tweetable]On Android, the bulk of the growth and total revenue is in Asia and thus so are the top grossing apps[/tweetable]. Japan has overtaken the US as the top revenue earning country for apps overall mostly due to growth on Android. The vast majority of the increased revenue is in free-to-play games and App Annie’s report shows that in Japan, almost all of this was attributable to just five publishers. Two of those publishers were existing major games powerhouses before the mobile era and they have several well known franchises. Two more reached the kind of scale where TV advertising became a viable route to market and exploded from there. The last of the five is LINE, who built a messaging platform with over 300 million users as a channel to promote their games.

This concentration of revenues amongst five publishers in Japan is mirrored elsewhere in the world. Consider Supercell (makers of Clash of Clans and Hay Day) were at $2.4M per day in revenues in April 2013, when they were still only publishing on iOS (they’ve since launched on Android) and were in the middle of expanding through Asia. That’s more than 10% of daily global App Store revenues for the top 200 grossing apps made by one publisher with 2 apps. Supercell aren’t unique either – according to Think Gaming’s estimates, King.com’s Candy Crush Saga is making more than $900k per day, just on iOS in the US. Indeed Think Gaming give us a better idea of the distribution. Their estimates show that the number 10 grossing game makes only a 10th as much as the top grossing game and by number 100 you’re down to nearly 100th of the revenue.

So, with revenue concentration at the top of the charts on Android even greater than on iOS, Android is the platform to target if you’ve got a world beating app with global appeal on your hands. Otherwise you’re almost certainly still better off on iOS first. Our own data, which considers revenue sources outside the app stores as well, agrees with this. If we only include the publishers earning less than $5M per month then iOS comes out on top, although if we include everyone with non-zero revenues then Android sneaks ahead. Significantly higher revenues for a tiny number of top Android developers pushes the average ahead of iOS (although the median remains way behind – there were more iOS than Android developers earning >$5M per month in our survey).

Android may become the top earning platform from App Stores in 2014 but it seems that only an elite few developers will reap the rewards. We’ve already shown that building enterprise apps and avoiding the app stores is a better bet financially but Android is not currently a lucrative platform in the enterprise market either. Still, it’s not all bad news for Android developers – the rising tide of revenues will lift all boats to some degree. Also, even 2014’s cheap Android device should be running at least Android 4.0 and have hardware capable of running almost any app well. This should reduce costs and increase the real addressable market for all Android developers. Last but not least, for an increasing number of developers [tweetable]it’s not a question of Android or iOS, it’s becoming ever more important to target both[/tweetable].

* Distimo’s year was November to November, while App Annie’s was October to October, so there may be some impacts from the relative timing of new product introductions.