Month: March 2014

Categories
Business

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

successful game developers

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

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

Halfbrick Studios (Fruit Ninja)

Image via Flickr by Rosenfeld Media
Image via Flickr by Rosenfeld Media

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

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

OMGPop (Draw Something)

Image via Flickr by ljguitar
Image via Flickr by ljguitar

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

.GEARS Studio (Flappy Bird)

Image via Flickr by naka_hide
Image via Flickr by naka_hide

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

King Digital Entertainment (Candy Crush Saga)

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

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

Rovio Entertainment (Angry Birds)

Image via Flickr by Garrett Heath
Image via Flickr by Garrett Heath

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

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

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

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

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

Categories
Tools

Finding the Right BaaS

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

find-the-right-baas

What is BaaS?

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

Which BaaS is Right For Me?

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

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

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

Feature Analysis

Storage

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

Push Notifications

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

Usage Analytics

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

Dashboard/UI

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

User Administration & Social Integration

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

Custom Code Integration

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

Options?

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

Parse

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

Firebase

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

Telerik Backend Services

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

StackMob

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

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

So Much More Awaits

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

Categories
Tools

Which App Stores Should You Use?

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

app-stores-you-should-use

To publish, or not to publish?

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

Apple is where the money is

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

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

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

More stores = more money?

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

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

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

Where to publish next?

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

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

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

Conclusion

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

Categories
Languages

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

App security 101

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

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

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

1. Insecure Data Storage:

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

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

Specific guidelines for iOS developers:

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

For Android devs:

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

2. Weak Server Side Controls

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

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

3. Insufficient Transport Layer Protection:

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

For iOS developers:

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

For Android developers:

  • You should set the AllowAllHostnameVerifier parameter to prohibit accepting all certificates

4. Client Side Injection

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

For iOS developers:

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

Android developers:

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

5. Poor Authorization and Authentication

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

6. Improper Session Handling

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

7. Security Decisions Via Untrusted Inputs

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

8. Side Channel Data Leakage

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

iOS developers:

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

9. Broken Cryptography

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

10. Sensitive Information Disclosure

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

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

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

For more insights, get in touch.

– George

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

Categories
Business

Mobile Gaming’s Dirty Secret

mobile gaming and revenues

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

Mobile Gaming's Dirty Secret

Spectacular Growth

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

Increasingly Freemium

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

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

Winners Take All

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

Who’s Paying, How Much and Why?

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

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

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

What Next?

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

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