Author: Mark Wilcox

Mark is developer who has worked on everything from the lowest level smartphone firmware to games and apps that sell pizza. He's also a project leader with a focus on lean methods and a consultant who loves rapid prototyping, app economics and business models.

Categories
Business

4 Reasons Not to Build Enterprise Apps

In an earlier post we showed how enterprise app developers make 4 times the revenue of those developing consumer apps on average. Targeting enterprises with apps can be very different from building consumer apps and not all developers prioritise revenue, so it’s not for everyone.

chapter1

Do you want the indie developer lifestyle, or to build a company? What sort of contact do you want to have with your customers? Do you like consulting work or do you prefer to build your own products full time? Do you have a strong development platform preference? Depending on your answers to these questions you might find one of the 4 reasons below keeps you focused on consumer apps for the foreseeable future.

1. You like to work alone

The creation of the app stores enabled vast numbers of individual developers to create and monetise their own apps. Amongst the revenue earning developers targeting consumers, almost 43 percent are in one person companies and practically all of those don’t involve anyone else in development. Of the developers building apps for enterprises, only 13.3 percent are in one person companies and those are almost exclusively doing contract work. The one person enterprise development companies earn 24% more revenue than the equivalents building consumer apps but it’s definitely not the independent developer lifestyle they’re living. In general the enterprise developers earn more than those developing for consumers at every team and company size, with the difference increasing with team size up to the 500 employee mark. Above that revenues from app development per person drop significantly, although on both sides a lot of large companies developing primarily for reasons other than earning revenue are included here.

2. Direct sales repels you

As you can see from the charts above, enterprise app developers tend to work in larger companies than those targeting consumers. There’s also a bigger company size to team size ratio. The difference here is likely to be sales, marketing and support teams. In general, larger customers need more direct contact. In the consumer apps space it’s possible, although unlikely to be successful, to launch an app and sell it without ever having contact with anyone that uses it. However, although the costs of direct sales staff may seem high, consumer apps with large revenues and user bases typically pay to acquire a decent fraction of users (e.g. via in-app ads, Facebook app install ads, cross-promotion networks). We don’t have any data to compare the cost of sales for these developers but I wouldn’t bet that the average cost of sales as a fraction of revenue for the successful consumer app developers was significantly lower.

Whilst subscription revenue is by far the best earner for consumer app developers, it is one of the worst revenue models for enterprise developers. In the enterprise market per user/device licensing and other sales outside of app stores is a key revenue component for most successful businesses. This aspect of a business can often be very unattractive to developers.

3. You want complete creative control

On average [tweetable]enterprise app developers earn a much greater fraction of their revenue from contract work[/tweetable] (consulting). The most successful enterprise app businesses earn 25-75% of their revenue in this way (we only have 25% bands). It’s likely that there’s a lot of custom integration work involved in selling to larger enterprises. Even those selling to SMEs often offer customizations.

Developers who consider their apps an art-form and build them primarily to earn a living doing something creative they love will probably want to stay away from areas where a lot of contract work is involved. Those same developers are also not very likely to be inspired to help automate business processes or other similarly mundane but useful enterprise app functions.

4. You love Android development

There are some very major differences in the revenue models and revenues of enterprise app developers depending on their primary platform. The really big revenues are currently being earned by HTML5 developers (> $100k per developer per month). Next highest revenues are for iOS developers (a little over $50k per developer per month) but it seems that [tweetable]a lot of iOS app enterprise development is currently outsourced[/tweetable], since more than 70% of these earn >75% of their revenue from contract work and 40% earn 100% of their revenue in that way.

Compared to these two, the Android developers are the poor cousins. Despite having a much wider range of revenue models, their average revenue per developer is much lower (about $14k per month). Enterprise development still pays very slightly better on Android than building consumer apps but given the other trade-offs discussed above, it might seem like a relatively poor deal.

Running out of excuses?

When we published the last article, showing that enterprise developers make 4 times as much revenue as those targeting consumers, a lot of responses suggested that this difference was all in the large enterprise sales market and required large direct sales teams. While there is definitely some advantage to scale, this is certainly not the case. Not all enterprises are large and there’s a very big market of SMEs looking for mobile software to make their businesses more efficient or convenient. Although the most profitable enterprise app development companies are in the 51-500 employee range and solo developers are only marginally better off targeting enterprises, a 2-5 person company makes more than 4 times as much revenue on average by choosing to build enterprise apps. The 2-5 person enterprise app business is much more likely to be building HTML5 hybrid wrapper apps rather than the native iOS or Android apps of a similar sized consumer focussed business. They are also likely to be spending more of their time (although far from all of it) doing contract work. If neither of those things bothers you then it might still be worth considering the enterprise market for your next app.

Categories
Business

Why are you still building consumer apps? Enterprise pays 4x more!

Consumer apps are the focus for all the excitement and media attention in the industry. Enterprise software is dull and boring, right? Not if you care about making money! Our data shows [tweetable]enterprise developers generate 4 times as much revenue as those targeting consumers[/tweetable]. Besides, what’s so dreary about reinventing the way people work in a mobile and connected world?

Print

“Wait”, I hear you cry, “what about BYOD and the consumerization of IT? Surely the future is all about selling computing tools directly to professionals?” Well the data from our April-May 2013 Developer Economics survey says that future isn’t here yet. In any case, if you’re going to collaborate with colleagues then you all need to be using the same tools, so most of the time the company still has to choose and buy them.

We asked developers which type of customer they primarily targeted from a selection of Consumers, Professionals, Enterprises, Other and Not Sure. Using this data we can compare the fortunes of developers serving each of those audiences.

It’s entirely natural that a new consumer-focussed computing market for smartphones and tablets spawned a large industry of consumer focussed app development organisations. The market is rapidly maturing now, with smartphone penetration above 50% in all developed markets and tablet adoption not far behind, yet still almost 75% of companies involved in app development are focussed on consumer apps. Traditionally software spending has been much higher in enterprises and although there is a shift towards employees selecting their own technology and tools it is surely not happening as fast as the shift to mobile computing. This leaves a gap in the market for developers focussed on apps for the mobile enterprise to fill.

A little over 12% of the money-making developers in our survey were targeting the enterprise yet they made on average almost 4 times as much revenue (per person involved in development) as those targeting consumers and typically had more than 4 times as many people involved in app development. Developers targeting professional users rather than their companies only made about 50% more revenue per person than consumer focussed developers and had about twice as many people involved in development. So, while this is a promising market, [tweetable]independent app developers are not replacing the enterprise IT department just yet[/tweetable].

At the bottom of the revenue pile it’s no big shock to see that developers who aren’t sure about their target market make by far the least money. How do you build a great product without knowing who it’s for? The small number of respondents who felt their audience didn’t fit one of our categories, selecting “Other”, may possibly be targeting too small a niche since their revenues are not far above half those of developers building consumer apps.

It’s important not to get confused by the similarity of the increased development team size and higher revenue figures – the chart shows revenue per person, so the effect multiplies. That is, the average enterprise focussed app development organisation is making around 16 times as much revenue as the average consumer focussed one in total. That makes the total revenues of the enterprise developers significantly greater than those of the consumer developers, even though there are around 6 times as many of the latter. Averages hide a lot of detail though. You don’t have to build a large company to be extremely profitable in the enterprise mobility market – smaller development teams actually have much higher revenues per developer. More details on that and important differences between consumer and enterprise app developers will be the subject of a future post.

Agree with our figures or disagree? Drop us a comment.

– Mark (@__MarkW__ )

Categories
APIs

Device API Usage and Trends

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

Distinctively mobile computing

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

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

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

Peering into the future

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

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

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

User needs trump technical possibility

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

Categories
Languages

How to succeed with HTML5

Although the debate on HTML5 versus native apps seems to be favouring native apps currently, particularly in terms of user experience and performance, average developer revenues tell a very different story. Our survey data shows the mean average revenue for developers who consider HTML5 for mobile devices their primary platform is the highest of all platforms, just over twice that of the next nearest (iOS)*. However, the rewards are very unevenly shared, with the median average revenue for the same developers under half that of their iOS counterparts. Diving into the data we can see significant differences in revenue depending on how mobile apps built with web technologies are delivered to users and the categories they target. Understanding these differences could improve your chances of succeeding with HTML5.

html5

Apps but not App Store sales

The majority of developers using HTML5 in their businesses still prefer to deliver it via the browser, either as traditional websites, or more complex web apps. The range of deployment options for developers using web technology and their relative popularity is shown in the chart below. The data throughout this post is filtered to only include developers whose organisations earn between $1 per month and $5 million per month. There are a large number of hobbyists with no revenue who are excluded and we also exclude a small percentage of super-high earners who create large distortions in the averages.

It turns out this browser-centric preference, despite the protests of the open web advocates, is bad for business – at least in the short term. On average (mean and median) [tweetable]developers deploying their code as standalone apps earn 50% more than those delivering via the browser[/tweetable]. If we exclude apps for platform native web frameworks (e.g. Firefox OS and BlackBerry WebWorks) because these are only available on niche platforms, then the advantage rises to 70% (mean, or 100% median). If we also only look at those developers who consider HTML5 their primary platform then the difference is larger still (mean revenue per person per month of ~$77.5k for app delivery versus $21.5k for browser delivery).

A popular misconception is that the web has poor monetisation and app stores solved this. However, as we’ve shown previously, [tweetable]the more developers rely on app stores for revenue, the less they make[/tweetable]. Web developers are no exception, in fact, avoiding reliance on app store monetisation is one of the keys to their success. Amongst developers using HTML5 for mobile devices as their primary platform who gave us a revenue breakdown, 65% had no revenue at all from app stores and of those that did, a further 65% generated less than 50% of their revenue from app stores. Contrast this with those targeting iOS as their primary platform – 67% of them generate some of their revenue from app stores and for 50% of those it was more than 50% of their total. So where do these web developers make their money? A much wider range of sources – more contract work than most platforms, many more sales outside of app stores and also e-commerce.

The right tool for the job

It’s also clear that HTML5 is not suited for all types of app and while in the case of enterprise clients it seems browser based delivery is still slightly preferred, an app delivery method opens up many more opportunities. The interactive graph below compares revenues by category for browser and app based delivery methods.

Outside the Enterprise software and Maps & Navigation categories, the revenues are at least an order of magnitude higher for app based delivery in this subset of popular categories. The outsized revenues earned by business productivity software developers suggest that the consumerization of IT is making significant inroads into the enterprise and even the comfortable revenues of those who focus on (mobile) browser based delivery for enterprise clients may not last.

Although we shouldn’t underestimate the impact that the relative maturity of many web businesses versus native mobile competitors has on the above figures, web technology seems very far from dead as a way to capture value in the mobile software market. Our data does suggest that those who want thrive in the age of mobile should embrace the consumer preference for apps rather than rely purely on the browser to deliver their services.

– Mark

A brief note on the figures presented in the article:

* Calculated as a mean revenue per person involved in app development and excluding organisations with $0 revenue per month or more than $5 million revenue per month. This is attempting to narrow our inquiry to real app businesses rather than hobbyist developers whilst excluding a small number of outliers that distort the averages. As such this is not comparable with our published reports based on market size estimates for all developers, including hobbyists, students etc. Average revenues on iOS are still the highest if we include all developers.

Categories
Business

Are you using the right app revenue model?

The most popular revenue models appear to be those that are easiest to implement. The developers using them tend to have lower revenues. This may be due to greater competition or it might just be a result of less sophisticated app businesses producing less valuable apps. There are some interesting differences between platforms but [tweetable]subscriptions appear to be a relatively untapped gold mine everywhere[/tweetable], although maybe not for everyone.

VMMoneyNote2_800

Revenue models versus average revenues

Our research shows some significant variation in average developer revenues depending upon the revenue models being employed. An investigation of the relative popularity of revenue models versus revenue generated across the major platforms produces some useful input for app development strategy and planning. Unsurprisingly, the simplest revenue models to implement, like paid downloads and in-app advertising, tend to be the most popular. The often repeated stereotype that “Android users don’t pay for apps” also leads to a strong preference for ad-supported apps on Android, while iOS developers prefer paid downloads. Slightly more surprising is that although Android has a larger user base who seem less inclined to pay up front for their apps, freemium and other in-app purchase schemes are less popular than on iOS. It would seem that on average [tweetable]iOS developers are more sophisticated in their approach to the app business[/tweetable].

Revenue distribution

When considering revenues it’s important to note that the distribution of revenues in the app business is highly concentrated at the top and there are a lot of hobbyists who earn nothing. We exclude most hobbyists, those who’ve not started earning revenue yet, the mega-rich chart toppers and large publishers from our analysis by only counting developers with between $1 per month and $5 million per month in revenues here. Even so, there is a fairly large “middle class” of smaller independent developers with a lot of users and high revenues. As such there’s a massive difference between mean and median revenues even in this subset.

The revenues shown in the chart above don’t necessarily all come from the platform or revenue model they are linked to – [tweetable]developers use multiple revenue models and multiple platforms[/tweetable]. For example, amongst developers who target iOS first the in-app advertising model appears to do much better than for those who target Android. Although iOS advertising rates are higher, this isn’t the primary cause, since very few of our iOS respondents derived most of their revenue from ads. The actual reason is that many of those using ads also used a freemium upgrade model (presumably paying to remove the ads and possibly add features) and derived a significant fraction of their revenue from that also. The same strategy does not appear to work as well on Android. Although not entirely accurate, we’ll refer to revenues by platform and revenue model as a shorthand in the rest of this post because it’s a reasonable approximation in most cases.

Less popular, more people, more revenue

Interpretation caveats aside, one thing that seems clear from this data is: [tweetable]the more popular the revenue model, the less successful the developers using it[/tweetable]. The exception here is contract work, which shows much higher revenues on iOS and lower on Android relative to its popularity. Although there’s some evidence that contract development rates for iOS are slightly higher, the difference is mostly due to where the platforms are most popular with developers. Otherwise, most revenue models show slightly higher mean revenues on Android but significantly lower median revenues. There’s also a link between the average number of people involved in app development in an organisation and the revenue model. More people involved, may signal more complex development for the associated apps. The fact that this is also associated with increased revenue is possibly related to using the extra development complexity (or team size) on a more sophisticated revenue model. It is not the case that more people involved results in higher average revenues per person in general. In fact, there is a very strong peak in mean revenue per person for organisations with 6-10 people involved in development – there are probably some significant efficiency losses above this size.

The subscriptions gold mine

Across both Android and iOS, [tweetable]subscriptions generate by far the highest mean revenues[/tweetable]. Median revenues for subscriptions are also higher than every revenue model except contract development. At the same time, only just over 10% of developers use a subscription model and the average number of people involved is lower than for all but the simplest revenue models. Mean monthly subscription revenues for Android-first developers are 3 times higher than for their iOS-first counterparts. It seems that Android users not paying doesn’t apply to subscriptions. However, median monthly subscription revenues on Android are less than half those on iOS, so there are a smaller number of very big winners with Android-first subscription businesses.

Should more developers be trying to build subscription-based businesses? Almost certainly yes, but they’re not for everyone. While 53% of developers using the paid download model and 45% of those using in-app advertising are in 1-person companies, that’s only the case for 20% of subscription businesses. In fact 53% of the subscription businesses in our survey had more than 5 people, not all of which are directly involved in app development. This is because many popular subscriptions include continuously updated content and there’s significantly more work (and cost) involved in providing ongoing content for subscribers. Our survey has also shown that money is not a primary motivator for lots of developers and managing the content side of the business may not be something they’d want to be involved with. For entrepreneurs looking to build successful app businesses, the subscription model is definitely worthy of further investigation.

– Mark

Categories
Platforms

Is Android First Really a Myth?

Popular perception in the tech press is that iOS gets all the best apps first. With Android market share beginning to dwarf that of iOS globally, there’s lots of speculation around when developers will switch to Android first. Our data shows iOS is still the priority for startups in the U.S. but that doesn’t necessarily apply outside the high-growth consumer app market, or elsewhere around the globe.

VM_76_transformers

The importance of platform priority

Just over a week ago, Steve Cheney wrote the very widely shared “Why Android First is a Myth”. The post makes some well-reasoned points about an important issue for the future of the smartphone market. One of the things that makes iOS attractive to a significant subset of early adopters is that it gets most apps ahead of other platforms, sometimes exclusively. [tweetable]If most developers start targeting Android ahead of iOS then those users will switch platforms, taking their app and service spending with them[/tweetable]. Where the early adopters go, most of the rest of the market will eventually follow. As such, developer priorities are considered an early indicator of platform fortunes, particularly at the high end. So if, as Steve suggests, iOS is set to dominate Android in this area for many years yet then Apple will keep making the bulk of the profit in the smartphone market. So is he right?

Silicon Valley doesn’t dominate apps globally

The major problem with the “Why Android First is a Myth” argument is that it is incredibly Silicon-Valley-centric. Whilst the two major smartphone platforms may be developed in Silicon Valley and dominate globally, the content and services used on them does not follow that pattern. Although there are lots of apps in common between U.S. and European app store top charts, there’s still plenty of highly ranked local content in most countries. Looking at the top grossing charts of massive smartphone markets like South Korea, Japan & China, U.S. users would struggle to recognise the name of any publisher (major exceptions being Supercell and King.com from Finland and the U.K. respectively). Not only is the assumption that the apps that make a platform attractive are going to come from the U.S. (or even “the West”) flawed, the assumption that they’ll primarily come from “sophisticated startups” is as well.

Mobile messaging services provide a good example. While VC funded startups may be the way many new services get built in the U.S., WhatsApp being a typical case, the global competition is rather different. KakaoTalk comes from a startup of sorts, although founded by a former CEO of Korea’s internet giant NHN, while LINE came from the Japanese subsidiary of that same Korean internet giant. WeChat comes from Tencent, China’s largest internet company and one of the biggest in the world. It’s more than just how the apps get funded and built though, it’s the types of apps too. The breadth and depth of the app offering on a platform is essential to have all the apps that are important to any individual user, whether it be an app from their bank or niche apps catering to their interests. Otherwise the Windows Phone strategy of paying for the most popular apps to be ported would be a lot more successful. As Paul Graham says, VC funded startups are all about growth, so they have to address issues that they believe are relevant to very large markets. They don’t build more niche or local apps and they don’t build the essential extensions of existing services to mobile devices. This suggests that the platform preferences of a much wider range of developers are important, not just the “sophisticated” startup developers.

Global platform preferences

With this in mind, VisionMobile has a great source of data for monitoring this important platform priority trend. Our regular Developer Economics surveys ask thousands of developers to rank the platforms they use in priority order. Just looking at the data from the last survey on which platforms are most frequently cited as primary by developers in each country we can see strong geographic patterns.

[tweetable]In almost all countries there are a significant fraction of developers who treat Android as their primary platform[/tweetable] and overall the number of developers with iOS and Android as primary platform is almost exactly even. This is biased by a large number of Hobbyists and Explorers* who overwhelmingly prefer Android, largely because it costs less to get started and the platform is more open. As such, iOS still leads by a decent margin (39% vs 32%) amongst those full time developers trying to build or grow businesses. However, this is not true everywhere with South America being dominated by mobile web developers and most of Asia ruled by Android. Europe is fairly evenly split between the two platforms. Most countries’ developer populations follow local user preferences with a slight bias towards iOS. A major exception is Russia, where iOS penetration is low but developers have an unusually high preference for the platform – this is not just outsourced development either; good technical education, a low cost of living and access to affluent global markets seems to be a great combination for smaller independent developers too.

What about startups?

Finally, if we’re purely talking about startups (or Gold Seekers in our segmentation) then iOS is clearly preferred to Android in North America. Out of those with iOS or Android as their primary platform, 70% are iOS first versus the 30% starting with Android. By the same metric, Asia has a 66% majority of Android first startups and Europe is split 50/50. Although our data set for this particular segment might not be large enough to be comprehensive, it’s clear that “Android First” developers are far from mythical!

If you work in a startup cluster and don’t agree with our numbers then please leave us a comment.

* Explorers are part time mobile app developers with a different day job – for more information on developer segments and their preferences see our segmentation report.

Categories
Tools

App Industry Picks & Shovels: How to succeed with mobile developer tools

developer tools

In the great app store gold rush of the last 5 years a lot of vendors of virtual picks and shovels have set up shop, hoping to cash in on the boom regardless of which individual developers succeed in a fiercely competitive market. Having surveyed developers on their tool choices and revenues, we can see how popular these third party tools and services are. We can also reveal whether those buying the virtual picks tend to do better than those who opt for the virtual shovels, or whether you really need both developer tools.

Print

With great opportunity comes great complexity

As the expected level of quality and functionality in mobile apps is increasing, the monetisation strategies are also getting more complex. [tweetable]In order to succeed, most developers need advanced tools to manage quality in a world of fragmentation[/tweetable]. To optimise revenue models beyond the simple paid download, systems to acquire and analyse the behaviour of users are also essential. Most developers turn to third parties to provide some or all of these tools. Many additionally look to third parties to provide some of the functionality, particularly via scalable cloud-hosted services.

Over 85% of developers who completed this section of our survey use at least one third party tool, while just over 45% of developers use tools from at least 3 different categories. There’s clearly significant demand but how does tool adoption correlate to revenue? Looking at only those developers who generate between $1 per month and $5 million per month (i.e. excluding those not trying to make money, not yet making money and the mega-rich – n=1596) we get the following:

More developer tool use, less risk

Looking at only the mean average revenues you could be forgiven for thinking that developers should be avoiding most third party tools, since by far the wealthiest developers are those not using them. However, a look at the median revenues shows the opposite. Some of the largest and most successful developers can afford to build and control their own tools so don’t need third party offerings. [tweetable]The vast majority of developers trying to make it without any third party tooling support generate hardly any revenue at all[/tweetable]. The median number of people involved in development for the organisations not using tools is 1, whilst it is 3.5 (2-5) for all other results. In general the increasing median revenue with use of more tool categories suggests that those who use more tools have lower financial risks. It’s tempting to speculate that there’s some causation here where developers are able to offload some risk by using proven third party solutions. In fact, the major driver is that the tool categories cover such a wide spectrum of apps that the more you use the more likely you are to be doing a lot of contract development – an inherently lower risk revenue model.

It’s not what developer tools you use, it’s how you use them

How use of tools in the various categories correlates with revenues doesn’t produce any great surprises. Those using cross-promotion networks, game development tools and ad networks are at the bottom of the revenue pile. Large game developers and publishers tend to have their own game engines, can cross-promote with their own titles and even run their own ad systems. The [tweetable]smaller, independent developers who rely on third parties for this typically struggle to climb the app store charts[/tweetable]. App store analytics users are next up from the bottom, this may simply reflect the relatively poor revenues of those who rely on app stores. Most other tool use was correlated with fairly average revenues. Notably above average, ranking second overall, is Backend-as-a-Service (BaaS) – where the mean revenues are about 35% higher than average and the median revenues 50% higher. As a result those using a BaaS typically beat average revenues by significantly more than the associated costs.

Using the data from our survey at the beginning of the year, we previously argued that developers who collect lots of analytics and quality data for their apps and act on it are significantly more likely to succeed. Users of crash analytics tools had the highest mean ($26k/person/month) and median ($2.1k/person/month) revenues of any single tool category in the latest survey. Nearly 50% of respondents to this section of the survey now use usage* analytics tools so it’s unsurprising that their mean revenues are almost exactly average ($17.5k/person/month) although noteworthy that their median revenues are 50% above the average ($1.5k vs $1k). Those using both crash and usage analytics tools had similar mean revenue to those just using crash analytics but significantly higher median revenue ($3.5k). The only tool combination to beat this was crash and usage analytics plus beta testing, which had mean revenues of $33k and median revenues of $3.75k. Beta testing tools can also help developers to improve the quality and usability of their apps, as such it’s interesting that those using just crash analytics and beta testing had extremely low mean ($5k) & median ($750) revenues. Possibly this last tool combination typically signifies a developer with a quality problem rather than one proactively seeking quality?

Is selling picks and shovels where the real money is?

There are some massive app developer success stories but our data suggests that the typical app developer (as represented by median revenue) is struggling to break even. It turns out that the developer tools market is similarly competitive. Selling services to developers ranks third in mean revenue per organisation and per person involved amongst all revenue models (behind per device royalties/license fees and subscriptions). Compared to the users of the tools the mean average income at $29k/person/month is slightly higher than for users of any single tool category but the median income is exactly the same as for the tool users.

* This category gets called both “user analytics” and “usage analytics”. The developer tools do both, although if you only use them to get an idea of who your user base are and how often they use the app (user), rather than what they do in the app (usage), you’re probably doing it wrong.

Categories
Business

App monetisation: Games vs. Enterprise and Business Apps

The mobile apps business is maturing and while most of the media attention is still focussed on the latest app store success stories, developers are finding lots of better ways to improve app monetisation. Considering all revenue sources, which categories of application are generating the most money and what’s the competition like on each platform?

DE12c3_web

App Stores not the answer?

In our last developer economics survey we asked developers to give us a breakdown of their revenue from different sources. Of the 1,695 developers earning between $1/month and $5 million/month who reported their revenue breakdown to us, 55% generated some of their income from app stores. There is a negative correlation between the fraction of revenue an organisation earns from app stores and the total revenue they earn per person involved in app development. That is, the more you rely on app stores for revenue, the less you are likely to make any. By excluding those with revenues above $5 million/month, we’re ignoring the very top of the store charts where the bulk of app store revenue is made. However, this is just a handful of developers, who would otherwise have an extremely disproportionate effect on the average. It’s also worth noting that [tweetable]there are limited costs involved in app store publishing but it produces the lowest average revenues of all sources[/tweetable] in our survey – it’s clearly not the easiest way to build a profitable app business.

Is there gold anywhere but games?

With games accounting for around 75-80% of all app store revenues it’s possibly not surprising that they were the most popular category of app amongst the developers in our survey. Given the chart above it shouldn’t be surprising that they are far from the most profitable (~$2,500/person/month more than the lowest mean income and the lowest overall median income). So [tweetable]which were the most profitable app categories? Business Productivity and Enterprise apps[/tweetable]. However, there are some significant differences between platforms so it’s worth playing with the interactive chart below to spot any opportunities that might be of interest.

[tweetable]Median developer revenues are higher on iOS than Android across all categories[/tweetable], but in some categories mean revenues are higher on Android. This shows that there are some developers managing to exploit the much larger market on Android successfully but most developers are still financially better off on iOS, including revenues from outside the app stores. Where average revenues across all platforms were higher than either iOS or Android, web developers were usually making the most revenue in that category.

The averages in the charts above still hide a lot of potentially interesting detail on where the best opportunities in the apps market are. Those wanting a more complete analysis should look at our App Economy Forecasts report.

Categories
APIs Tools

Accelerating Web Apps – It’s all about politics

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

Are mobile web apps doomed to be slow?

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

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

Platform wars and politics

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

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

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

A ray of light?

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

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

Categories
Tools

Cross-Platform Tool Trends – Freemium & Flexible

CPT trends

CPT trends

Creating versions of an app for multiple platforms (at least iOS & Android) is an increasingly common requirement. Building and maintaining native code for every platform supported is both difficult and expensive. Cross-Platform Tools (CPTs) offer a solution to this problem by enabling sharing of code across platforms and in many cases a single code base can target multiple platforms. With such significant cost savings available, why don’t all developers use CPTs?

Learning curves & licensing

Unfortunately the platform spanning magic provided by CPTs doesn’t come without any costs. Most CPT vendors depend on licensing revenue – developers have to pay to use the tools. Of course the cost of licensing most of these tools is far less than the cost of a full native port of an app to one additional platform. However, there are more costs associated with adopting a tool than the license fee; learning to use a CPT and building confidence in it’s suitability for future projects requires a significant time investment. The potential future cost of switching away from a tool that isn’t working out as hoped is also something that developers must consider.

The spread of Freemium models

In order to build sufficient confidence in a CPT to build their businesses around it, some developers need lots of time for evaluation, perhaps building a side project before risking major apps or customer projects. For many the 30 day trials that were typical in the sector just weren’t sufficient. One of the first mobile CPTs, MoSync, was very early to recognise this and had generous free options early on, they even went open source with a dual licensing model back in 2009 around the time many of their competitors were just launching. This year has seen a tipping point, possibly partly due to increased competition in the sector but also to capture a larger share of the ever growing demand for mobile development – Appcelerator, Corona, RunRev, Unity and Xamarin have all either switched to freemium models or expanded their free offering for mobile. RunRev has also joined MoSync in releasing their code under an open source license, Appcelerator have open sourced more of their code and Xamarin have just open sourced some of their cross-platform API wrappers. Having access to the code for the cross-platform layer can help remove developer fears of getting blocked by a bug in their chosen tool and being entirely dependent on the vendor for a rapid fix.

Technical tradeoffs

In many areas platforms are sufficiently different that it’s not possible to unify them under a single API. CPTs get around this in a number of different ways:

1) Not providing access to the problematic functionality – this restricts what developers can create.
2) Providing a lowest common denominator API – this prevents developers from using the full power of the native platforms.
3) Providing their own implementation of the functionality – this can bloat apps and often prevents them from having a fully native experience.
4) Providing thin wrappers or separate extensions for each platform – this gives maximum control but adds complexity to the code, reducing the benefits of a cross-platform approach.

Different apps, or even parts of apps, will have different priorities that determine which of the above approaches are acceptable. For example, a mass market consumer utility app is likely to require a completely native look and feel for the UI, while an internal app for a large enterprise may want to look and feel exactly the same on all platforms to minimise both development and staff training costs. The same tradeoffs won’t always apply to every part of an app either; most games have a completely custom UI and don’t require access to the native platform UI components at all, however, they may well want access to the new Google Play game services, or the iOS 7 Game Controller APIs as soon as they are available.

A flexible future

Faced with a still growing list of platforms to support and wide array of new features in each new platform version, CPT vendors now have to specialise for a sufficiently profitable subset of the market that has fairly narrow requirements or become increasingly flexible. Most vendors currently provide flexibility through a native interface that enables the creation of third party extensions or plugins. Xamarin’s approach to flexibility enables developers to (semi-)automatically generate wrappers for any native API or library, which is ideal for developers who want to stick with C# for all of their own code yet build on the work of native developers for each platform.

Even greater flexibility is possible though. What if you could just build the parts of an application that made sense to be cross-platform with a CPT? RunRev has a beta for an embeddable library version of their engine to enable this, although currently only for iOS. They are also re-architecting their engine to put 3rd party extensions on an equal footing with the core functionality – even allowing them to extend the language where necessary. Another interesting option going forward here is Digia’s Qt, the open source cross-platform framework that was acquired and re-purposed for mobile by Nokia before they dropped it in favour of Windows Phone. Qt is now the native framework on BlackBerry 10, Ubuntu Mobile and Sailfish OS and is close to production readiness for iOS and Android; it also has a Tizen port ahead of the release of that platform. The core of Qt being C++, it can easily interface with native code on most platforms and has always been delivered as a library, so it’s also embeddable within native apps.

Flexibility enables greater agility

This library format means that developers can start cross-platform and add or optimise parts of their app with native code later. It’s possible to just add a full native experience for the platforms that get the most traction. Alternatively, starting on a single platform and then adding new functionality that works across all platforms after achieving some success and starting to port to other platforms is also an option. Last but not least, the library format also removes any concerns about lock-in. If a developer decides to migrate away from a CPT, they can do so gradually, without having to port/re-write everything in one go. It’ll be interesting to see how many vendors can push flexibility this far and how many developers take advantage of it.