Categories
Business

6 tough questions on app business models and strategies

[VisionMobile’s Andreas Pappas was recently quizzed on app business models, best practices and strategies for developers and entrepreneurs. In this post we’re presenting the most interesting questions and answers from this interview. These are tough questions that all developers and entrepreneurs are faced with in the early stages of their ventures.]

 Print

Q1: I am thinking of developing my own mobile app: What are the main business models I can use to make money and how do I select the right one for my idea?

There are numerous factors to take into account when developing your business model but the two key questions you have to ask are:

  1. What problem am I trying to solve?

  2. How am I solving this problem?

Once you have answered these two questions, you will be in a much better position to develop a business model. A good place to start from is the Business Model Canvas, a simple tool that outlines the key areas that a business model needs to address.

A number of areas within your business model are interdependent. For example, your target market will initially be defined by the problem you are solving. Once you have identified your target market you can start thinking about revenue models, marketing, partnerships, distribution etc.

While it helps to get everything right the first time, it is most likely that you will need to adapt both your product and your business model several times along the way.

From an economics perspective, a large number of successful business models these days are built on two-sided networks and even multi-sided networks. These are usually services that connect businesses to consumers or consumers to consumers, such as, for example AirBnB and eBay type services. These models exhibit powerful network effects if they manage to scale up and allow owners to monetise either one side of the network (e.g. consumers or businesses) or both (e.g. commission-based) depending on the application.

[tweetable]When it comes to making money, there is a variety of revenue models available[/tweetable] and the selection is to some extent dependant on your business model, competition, target market, and exit strategy. There is no one-size-fits-all solution here.

Free services can scale up quickly but monetisation may be problematic. So if your business plan requires scale, think about indirect income sources such as advertising or even VC funding, to get you through the growth phase. Once you’ve achieved scale, an exit is an option you should consider: user acquisition is expensive and larger businesses will frequently opt for acquisitions rather than organic growth.

[tweetable]Advertising may be profitable but requires massive scale and even then, getting it right is tricky[/tweetable]. Advertising is more popular on Android and WP than on iOS, due to the fact that Android users are not as heavy spenders as iOS users.

Obviously app-stores allow developers to monetise their apps directly, via paid downloads or in-app purchases. The latter has become increasingly popular, particularly on iOS and competes favourably against paid-downloads.

Beyond these obvious ones there is a range of options that have to do with the type of app/service that one is providing. For example, apps offering content or services (e.g. news apps or some fitness apps) may utilise a subscription model. This app business model is not easy to pull off though – even popular newspapers are struggling to make money off subscriptions.

 Advertising most popular revenue model

Q2: I am a mobile developer. Which sectors have the most potential in my country?

The good thing about mobile apps is the fact that the market is global and the costs and barriers to reach international markets are very low compared to other, more traditional businesses. So mobile app development should not be seen in the traditional way of “what works in my local market” but instead, from the viewpoint of “what works in the markets that I want/I am well placed to reach”. In short, any sector has potential in your country if your focus is international and it should be international-first.

While this change in mindset is critical, that is not to say that there are no opportunities locally. If one is developing apps that rely on local content or services (e.g. transport services) then highly localised content is required. So it may be easier for local developers to source and access this content, although this is not always the case.

One would think, for example, that local travel/tourism apps would be more successful since they’re optimised for each region. However, the most successful apps in this sector are global because they have scale. [tweetable]For most apps, scale is critical and thinking locally can only get you so far[/tweetable].

Q3: What is more difficult? Coding or marketing the app?

The consensus among developers says marketing. While adopting new languages, frameworks, SDKs and APIs may pose challenges, it is usually a straightforward matter of learning to use new technology. For most developers, marketing has been uncharted territory until the very first app-store appeared. Mobile marketing is quite a different beast to anything that was available before iPhone-era smartphones. Even digital marketing specialists may find the landscape too perplexing since the strategies, practices and even the KPIs are in constant flux. Constant experimentation (in other words trial-and-error) is one of the strategies most frequently used in order to find out what works best in your case.

Q4: What are the best ways to do marketing for my app and acquire users/downloads etc?

😉 See above. The best advice is to try several options and see how they work for your particular case. Before you pay for any advertising or promotion network, try some textbook marketing methods that are still of great value:

#1 Cross-promotion

If you have several apps, make sure you promote your other apps through them. Of course this must be done in a way that will not annoy your users. If you can promote your app through other apps, that’s also a good idea.

#2 Become part of an ecosystem/platform

Make your app work with other apps if this is an option. For example, if you’ve developed a fitness app that could work with Withings or Runkeeper, why not make it work with these and gain more visibility through their own ecosystem?

#3 Do some PR

Let people know about your app. Send emails or press releases to popular websites, newspapers and anyone with a sizeable reach. Most of them may not respond but it’s definitely worth a try and there are several success stories that started this way.

After you’ve done the above, there are plenty of options to try, depending on your marketing budget. If you have determined how valuable each customer is to you, then you can hire a mobile marketing expert to handle all your marketing activities and pay them per customer acquired.

Q5: What are the most common mistakes that mobile app developers do and how can I avoid them?

#1 Failing to see app development as a business

[tweetable]The best technology solution is not good enough without the right business models and execution[/tweetable]. This is one of the best known principles in the area of technology strategy. Developers that lack business experience often fail on the commercial side of the business.

#2 Failing to prepare for success

The nature, scale and pace of the app economy is such that in a matter of days your user based may grow from tens to tens of thousand users. Will your back-end cope? Will you be able to pay for third-party API calls utilised in your app? If not, what may have been initially a great service, will fail due to poor customer experience or you may run out of money. A proper business case should anticipate success.

#3 Failing to pivot/adapt

A common advice in the startup world is “pivot till you die”. If your idea is not working try applying it on a different market, adapt it to the current market, flip it on its head or scrap it altogether and go for something else.

#4 Failing to know and listen to your users

In a market where consumer switching costs are so low and a user can easily replace your app with the competitor’s app, user experience and customer support are critical success factors. Your app will be deleted if it crashes repeatedly, if it is poorly designed, or does not deliver what it says on the tin. Test your app, test it again, use crash-reporting and user-analytics services and keep it up to date, implementing new features and listening to user feedback.

Q6: Is it better to try to innovate with a never-seen app, or is it better to be a follower?

Neither is easy and both can work. The advantage of being a follower is that you learn from others’ mistakes and failures. You may for example see what is not so good or what is missing from an app and fill the gap, or extend it into another market. The downside is that by the time you do it, others will probably be trying to do it too, so there will be more competition. You don’t just need a better app, you also need better execution, i.e. a better business model and marketing, in order to topple the leader.

On the other hand, a new, innovative idea can take you a long way before the competition catches up (although never at a safe distance) but it is more difficult to create a niche and then expand it.

[tweetable]While most developers develop apps they want to use themselves, this should not be the only criterion for developing your ideas[/tweetable]. At the very least, discussing with users, friends or researching the market can get you a long way.

Those developers that extend tried and tested ideas into new markets are usually more successful. That doesn’t mean that you can just copy an app; you have to adapt the business model to the new market at the very least. In the app economy innovation is not limited to technology but extends to business models too.

Successful developers grow by extending to new verticals

Comments? More advice? Feel free to start the conversation.

Andreas Pappas

Follow me on twitter @PappasAndreas

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
APIs Languages

Websites vs Web apps: What the experts think

websites-vs-webapps

Definitions of web sites vs. apps

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

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

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

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

The difference between Web sites and Web apps

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

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

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

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

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

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

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

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

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

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

Creation versus Consumption

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

Linkability

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

User Experience

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

Architecture

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

Should you be building web apps or web sites?

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

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

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

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

The ‘app-ification’ of the Web

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

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

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

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.

Categories
Tools

Rise of the Mega SDK Vendors in Mobile

transformer

Many would argue that the mobile platform consolidation in the form of today’s Apple / Google duopoly is a good thing for developers; less choice, but two mature platforms and a billion-smartphones addressable market. Despite the platform consolidation, developers face real challenges not just in developing, but also in prototyping, designing, marketing, selling and supporting apps.

The quality bar for apps is increasing; apps need to incorporate more functionality in a slicker UI, a sexier package (graphical assets and messaging), as well as through the right marketing channels and at the right price, which is usually free-to-try. App consumers are demanding, expecting utility, convenience and easy of use – all at a low or free price point with monetization shifting from paid downloads to advertising and in-app purchases. Enterprise apps have to talk to legacy systems, be an effective part of a company’s business strategy, enhance brand image, while being secure, reliable and cost efficient to develop and maintain.

To support the community of 500,000+ mobile developers globally, a new “SDK economy” has emerged to cater to the needs of mobile developers. A storm of over 500 SDK startups and Enterprise IT incumbents, have emerged since 2009 to help developers in everything from app prototyping and debugging, to user analytics, planning tools, and customer support. These days developers can choose from a gazillion tools to monetize their apps, test, monitor app performance, manage security, study user behaviour, cross-promote apps to attract & engage users, and manage API use and simplify use of cloud services.

Today most of the supporting infrastructure for app developers resides, within 3rd party developer tools, rather than within the platform itself. This SDK economy has become the critical infrastructure underneath the app economy.

Growth and consolidation in the SDK economy

The SDK economy has seen an impressive amount of growth and consolidation in the last 4 years. It’s also an economy that’s intensely suffering in terms of monetisation.

The very first SDKs or tools for mobile developers were App store analytics (tracking sales & downloads) from the likes of Distimo and App Annie. Then came ad networks (mobile-centric like AdMob, acquired by Google), later followed by web ad networks expanding to in-app advertising, with ad networks and servers now in abundant supply. Cross platform tools followed soon after, helping develop apps for more platforms, from a single code base. Led by PhoneGap and Appcelerator, the supply of CPTs has exceeded 50 vendors, practically making this area of the tools economy a red ocean.

Looking for investment opportunities, VCs began investing in the companies that support Enterprise and Consumer mobile app development. The VC capital created value but it also changed developer perceptions of value, by forcing tool vendors to offer base products for free. It also led to a string of acquisitions (see below), as covered in VisionMobile’s Developer Economics Q1 2013 report.

Table: Mergers and Acquisitions in Mobile Developer Tools

Company Product & type Acquired by Date
Aptana Development environment Appcelerator Jan-11
Metismo Bedrock Java-to-native source code translator Software AG May-11
TapJS Game hosting platform and API AppMobi Jun-11
TapLynx App factory Push IO Jun-11
RhoMobile Rhodes enterprise apps framework Motorola Solutions Jul-11
Particle Code HTML development tools Appcelerator Oct-11
Nitobi Makers of PhoneGap Adobe Oct-11
Strobe Web app framework and app management platform Facebook Nov-11
Usergrid Backend-as-a-Service Apigee Jan-12
Cocoafish Post-download app services Appcelerator Feb-12
Worklight Enterprise app platform IBM Feb-12
Chomp App store search and discovery Apple Feb-12
TestFlight Beta testing Burstly Mar-12
Trestle Back-end-as-a-service Flurry Jul-12
Appstatics App performance trackingservice Appsfire Jul-12
Instaops User analytics Apigee Aug-12
Cabana A tool to turn Facebook pages to mobile apps Twitter Oct-12
Nodeable Big data processing Appcelerator Nov-12
Crashlytics Mobile crash reporting Twitter Jan-13
Wavii Natural Language Processing Google April-13
Parse Mobile Backend as a Service Facebook April-13
Handmark/ OneLouder App Store & Mobile app advertising platform Sprint Nextel May-13
Proxomo Software Mobile backend technology Lucent Mobile May-13
Appshed Cross platform tool & App Factory IDG Group May-13
IrisCouch Mobile Backend as a Service Nodejitsu May-13
Aepona API exposure and monetization platform Intel May-13
Mashery API management and monetization Intel May-13
Staq Game management platform PlayHaven May-13

There are three reasons behind the consolidation of the SDK economy:

  1. Capital changing the perception of value. VC capital allowed tool vendors to offer developer products for free to accelerate user acquisition.
  2. The need to subsidise developer onboarding. Developers are always the side of a mobile platform that Apple, Google, Microsoft or BlackBerry will need to subsidise. As a result platform-provided tools will be usually free and 3rd party tools will be prime acquisition targets for platforms themselves.
  3. Catering to adjacent developer needs. There are substantial benefits to developers by integrating functionality across tools (e.g. ad networks with user analytics or crash reporting with performance management), which inevitably leads to acquisitions on tools that are adjacent in the developer journey. Catering to adjacent developer needs also helps tool vendors attract and, most importantly, retain their user base.

Who stands to survive and win in this ongoing consolidation of the SDK economy? As is already evident from the earlier M&A list, consolidation will become clustered around where developer money is flowing into: App Marketing Services & Enterprise Mobile Services.

App Marketing Services

Mobile Advertising is expected to be a 20B market by 2015. Traditional ad networks have already ported their existing products – banner advertising – over to mobile in the form of in-app advertising. This model doesn’t work well yet in mobile and is a factor in why traditional ad networks are not yet profitable.

One VC backed company, Flurry, followed a completely different path to capture app marketing revenue. Flurry recognized developers would first worry about the challenges of developing their app(s) and then worry about monetization. Flurry offered developers a host of tools (many of them free) to develop and track their app usage, built a relationship of trust with their developers, emerged as a leader in the mobile services market, and then launched a range of products that will help developers monetize their apps.

Flurry considered the developer journey and built a spectrum of solutions to engage developers from the beginning to the end of that journey:

  • Analytics: a free service to measure actual use of the application
  • AppCloud (free): a back-end as a service
  • AppSpot: helping developers monetise, once an app has achieved traction
  • AppCircle: where developers can re-engage, promote and reach out to more users

Flurry is capturing the lucrative app monetization dollars because VC funding gave them a head start. With strategic acquisitions like TrestleApp (a backend service startup that helps developers minimise backend coding) and giving away their analytics for free, Flurry is building the first true mobile, data driven (Big Data) ad network.

Other companies are understanding this formula and making a play for App Marketing Services. Burst.ly acquired TestFlight earlier this year in a bid to become the vertical solution that covers all developers’ needs. Similarly, Facebook wanted to reinforce its relationship with developers and did so by acquiring Parse, a BaaS service. This acquisition reflects a growing trend where non-mobile companies see developers as platforms rather than customers, and developer tools as routes for customer acquisition, rather than feature enhancement.

Enterprise Mobile Services

Enterprise IT needs are different from consumer app needs. In enterprise apps, companies are less concerned with advertising or virtual good purchases and care more about security, stability, predictability and scaling down costs of mobile development and maintenance. Enterprise apps take performance, security and systems integration much more seriously than virality, direct monetization and high engagement.

So which mobile tools do enterprises need? User analytics, app performance analytics, crash reporting, integration with existing business logic (connectors with SAP, Oracle, IBM), identity management, data security, and own app store distribution, to name a few.

In enterprise IT, the incumbent back-end systems players like SAP, IBM and Oracle have been in the space for years and are very well positioned to ride the enterprise mobility wave. They stand as a formidable wall, deterring smaller vendors from entering the enterprise mobility market because they “own” the back-end and related ecosystems (including solution providers and integrators) within the largest companies. Mobilising those “owned” back-ends by 3rd parties is expensive because of the licensing schemes imposed by the incumbent back-end vendors.

At the same time, a wave of smaller, more nimble vendors is making a play at enterprise mobility. Appcelerator, after failing to effectively monetize their cross-platform tools, is now making a vertical stack play, much like Amazon AWS, for mobile. They help developers of any platform access traditional services, such as user management, object persistence, push notifications and analytics via API calls to their cloud services or on-premise installations of their suite. Apigee announced a new product aiming at Mobile, offering user analytics, performance management, crash reporting and network analytics. All of these players clearly want to offer much more than a product that focuses on a tiny vertical or niche market. On the server side, there are tools like Splunk, which give insights into how an app is performing, identify bottlenecks and discover patterns. These tools don’t exist yet in Mobile, and big players, like New Relic, just entered this space. At the same time, the back-end incumbents are strengthening their mobile play. IBM has laid out a mobile strategy that wants to bring in Mobile as part of a more traditional IT strategy. The recent acquisition of Tealeaf aims at helping traditional business better understand and analyze their mobile audiences.

Consolidation is already playing out within enterprise mobile services.

As the mobile market heats up, we agree that consolidation will likely result, as larger vendors look to shore up their mobile service offerings. Operational tools, especially those that deliver critical capabilities for monitoring the performance of mobile platforms and the web infrastructures upon which they rely, will become a strategic area of focus in this process. At the end of the day, any vendor who wishes to emerge as a key player in this arena must effectively monitor the whole application environment – transactions, mobile devices, network response, real user experiences, application servers, database connections and more.
— Jim Gochee, SVP Products, New Relic

Tool vendors who stick to single functionality – be it prototyping or internationalisation or customer support – will become either niche players with a small but profitable market segment or zombie companies, surviving with minimal profitability and, given the Series A crunch, they will drive consolidation to new heights in 2013.

The rise of the Mega SDKs

The consolidation of the SDK economy will continue to accelerate leading to the rise of the Mega SDKs, along the two clusters:

  1. App Marketing Services
    Winners will be those who build developer trust with end-to-end app development support, monetizing all channels that can maximise revenues or reach (e.g. ad networks, cross-promo networks, user analytics).
  2. Enterprise Mobile Services
    Winners will be those helping developers write across more screens, manage more users, and better understand users (e.g. cross-platform tools, BaaS, app performance management, API management).

Competition in the marketing tools will force companies to offer more and more for free, making it difficult for smaller startups to compete with the breadth of tools and the scale of companies like Flurry and Facebook. In the enterprise IT world, we should expect new titans to emerge or incumbents like IBM to enter and become the Amazon Web Services of mobile.

Categories
Business

How to price your app

To matter on the App Store, your app needs to be priced at 99¢, right? Or does it?

Making money from your app is really difficult. Pricing is intuitively an important part of the potential of any app. Price too high, and you price yourself out of the market, but price too low, and you’re leaving preciously needed money on the table.

Michael Jurewitz comes to the rescue! In a five part blog post series, the Apple veteran explains the ins and outs of app pricing, tackling crucial issues like differentiation, pricing power, price elasticity and a practical plan to optimise prices based on your app’s data. Our favorite take-away? Solve a difficult and important problem. Then charge what your software is worth. A must read for every developer who seeks to rise above the app poverty line.

The posts are based on a talk  from the Çingleton and NSConference events.

Michael Jurewitz – Çingleton 2012 from Çingleton on Vimeo.

Categories
Business

How better app quality results in more downloads and revenue

While the link between app quality and app success is quite clear to most developers, it’s always good to throw in some actual data. Happy to oblige.

A very nice visualization of the US iOS App Store over  at App Store Rankings shows that a 4.5-star app gets downloaded on average 3.7x more often than a 3.5-star app (265K downloads versus 71K). Our own research has shown that developers that use performance or user analytics tools to improve their apps generate about 3x as much revenue on average.

Higher revenues for developers using dev tools

The team over at Appurify have added another piece of the puzzle. They analyzed the top 100 free apps in the App Store as of May 2013 to investigate the impact of common performance issues (e.g., crashing, lagging, and slow load times) on app reviews. Analysis components included: number of total reviews; number of “most critical” reviews; number of “most critical” reviews attributable to performance; keyword counts for frequently-occurring descriptors including “crash,” “fail,” “laggy,”  “battery,” and “slow”.  A clear majority of 1-star reviews featured reports of poor app performance.

Likewise, an analysis of 25 million individual app reviews showed that the most frequently-used words in 1-star reviews were mostly tied to poor performance (e.g., work, time, fix) and lacked the positive performance-related descriptors in 5-star reviews (e.g., easy, great, fun).

 

appurify-analysis
Source: Appurify. Republished with permission.

The action point for developers is clear. Here are some tools that you might use to improve your app’s quality.

[sectors ids=’102,100,106,36′]

 

Categories
Business

Engagement drives In-App Purchases for games, says Apsalar

Today’s most successful developers are giving their apps away in the app store for free, and, if done correctly, it’s an effective monetization model. At the end of October, of the top 15 grossing apps in the Apple app store, 14 of them are completely free.

This model can be both lucrative (when done correctly) and nerve-wracking, since companies are spending time and resources developing and marketing a product that they subsequently give away for free.

Fortunately for developers thinking about making a game, Apsalar’s Big Data Lab has gathered insights on some 400M unique active devices to help developers make better decisions and figure out what genres of game app developers should be making more of in order to maximize revenue.

For this report, we examined data on millions of in-app purchases. Our goal is to try and inform developers with knowledge on which game categories are most effective at driving in-app purchases and how engagement correlates to purchase events.

Strategy, Trivia & Adventure most effective at driving IAP

IAP_1

Our data shows Strategy, Trivia, Adventure, Family, and Role Playing games have the highest propensity for in-app purchases. Also noteworthy is the significant drop-off between the top 5 and the bottom 5 categories, as the “Simulation” category has generated about half as many in-app purchases as the “role-playing games” category. One more interesting data point on the above is how low “Action” games rank in terms of in-app purchases. The shift from predominantly casual games on mobile to more hardcore games (i.e., Infinity Blade, Rage of Bahamut, etc.) has driven some companies, who previously pioneered casual games to consider building a hardcore, action game. This data suggests that companies looking to expand beyond casual games should actually consider strategic, role-playing games as viable alternatives.

The next piece of data we looked into was average daily session length by app category. This data shows us how long users have been spending on average per day inside these games.

IAP_2

The sweet spot in terms of engagement is around 2 minutes. Interestingly, while arcade games have an extremely high average daily session length (as seen in the previous graph), they generate a relatively low number of in-app purchases.  One possibility may be that these games actually monetize best not by the freemium model, but by a business model known as paymium. In the paymium model, developers have users download free versions of their games then generate revenue by upgrading their users to, for instance, a $.99 or $2.99 paid product.

Strong correlation between IAP and engagement

The graph below presents a consistent picture between engagement and monetization, except for 2 game categories:

  • Arcade- High engagement with low monetization
  • Trivia- Relatively low engagement with very high monetization

IAP_4

The graph shows almost a straight correlation for all the data points, except for Arcade and Trivia, noted above. Trivia doesn’t appear to be an outlier though. That category generates a healthy level of in-app purchases but is still in a high engagement quadrant. The outlier is Arcade. This category has similar engagement to Trivia, Role-playing and Family (three categories that are high in in-app purchases), yet is at the bottom of in-app purchases.

A key observation is that there is no game category falling in the top left quadrant (i.e. low engagement + high in-app purchases). Which means that game developers have no chance of generating in-app purchases without high engagement.

So the key takeaway for developers using the freemium model is that it’s still critical to first focus on building a great, engaging game in one of the categories where in-app purchases are highest. Once developers have managed to do that and have engaged users, offering in-app purchases such as special items and unique gifts is a great way to take a free app and turn it into meaningful revenue.

This post first appeared on the Apsalar blog.

Categories
Business Tips

How to beat 2/3rds of app competitors

Our mission here at Developer Economics is to help developers create a better app business. A recent survey from App Promo highlights the pain points once again, and offers some hints about the solution.

Let’s start with the bad news…

4 out of 5 developers admit that their app doesn’t make enough money to be considered a standalone business. 2 out of 3 doesn’t break even. This confirms our results from the Developer Economics 2013 report, where 67% of developers who want to earn money live under the App Poverty line (revenues of less than $500 per month).

Despite these disconcerting numbers, and despite developers indicating discovery, making money and turning the app into a business as the main challenges, most developers undervalue the importance of marketing their applications. According to the App Promo survey, 2 out of 3 developers don’t have a marketing budget, and a quarter of developers doesn’t market their app at all.

And yet there is hope. A full 81% of developers said that they would not abandon their app. App Promo found that the survivors (experienced developers with apps that are over 3 years in the market) have succeeded in creating an interesting app business. They report revenues earned to date of over half a million, 100% of them breaks even and 78% considers their app successful enough for a standalone business. And yes, they do market their apps: over half of the respondents in this group has marketing budgets of over $1000 per month.

App Promo’s results also include differences between platforms, the use of various revenue models and marketing techniques, and more. The full results can be downloaded here.

AP_DevThatCould_2