Categories
Business

Are Freemium Apps Killing Game Developers?

The rise of freemium games has been ferociously quick and it continues to accelerate at an incredible pace. It’s estimated that adults now spend, on average, 5 hours and 46 minutes online and on their mobile devices. Time spent online has now surpassed time spend watching TV.

Blog002_Final

With more consumers than ever playing games on their mobile devices, developers have had to “evolve” to find the most efficient ways to monetise their potential customers and, from a revenue perspective, [tweetable]the ‘freemium’ model has almost completely killed ‘paid-for’ games[/tweetable].

Putting morals and ethics aside, the freemium route is absolutely genius. Freemium, especially on mobile, can generate vast amounts of profit for developers who manage to create popular applications.

When we ask the question, “are freemium apps killing game developers?”, it always generates an interesting debate. Let’s understand why.

What are freemium apps?

The term freemium can be defined as:

“A business model that provides a game to players free of charge, but charges a premium fee for special features, powers, or content.”

Take a look at the App Store whilst reading this post and you will see the overwhelming majority of top grossing applications are free to download.

freemium-business-model-3

To developers, these applications would be classed as “freemium” apps, but the majority of users who download these type of applications believe the developer is making it as difficult as possible to progress within the application in order for you to purchase ‘upgrades’, ‘coins’ or ‘power-ups’ that allow you to progress within the application.

freemium-business-model

Freemium applications started as an experiment, but very quickly became mainstream. In fact, it was reported last year that 76% of all iPhone app revenue came from in-app purchases.

From a developer’s perspective, freemium games are the preferred route. It’s where the majority of download volume exists and the highest earning revenue streams can be found. Most importantly, their prospective customers’ mindset has shifted. If you are not a ‘free’ game or application, you will have a much harder time selling yourself.

When you speak to independent game developers, they will tell you that more and more revenue could be generated from a free-to-download application. Take an example of a subscription-based game which might charge $20 a month to play. Only a few people might ever be willing to spend that – but far more would be willing to spend 10% of that on a freemium type game. The reality is, when you look at the metrics, there is little to no comparison. Free apps with in-app purchases are potentially much more lucrative.

On the other hand, there may be customers who, even if they were spending $20 a month on a game, would be willing to spend even more if they had the opportunity to. Legacy games never offered that type of flexibility, but things have changed and the top games developers are reaping the rewards.

The thought of ‘what if?’ really did start a new line of thinking. A line of thinking that eventually took the freemium model mainstream.

Why is Freemium seen as bad?

When you look at games from a hardcore gamers point of view, with the above scenarios in mind, you soon realise that the freemium trend is a real negative for them and their style of playing.

[tweetable]The core underlying aspect of freemium games is that you have to pay to continue playing[/tweetable]. Rather than pay a one off fee for a game which would take even the most dedicated gamer a while to complete, there are now deliberate parts of a game or application that force you to spend money in order to overcome a problem.

Roadblocks deliberately placed by a developer force a gamer to spend if they want to continue progressing. It’s this understanding, which has led to many negative reviews of freemium games and the mobile gaming industry in general.

When it comes to developing, freemium games are, arguably, easier for much larger game publishers to make, because these types of games require much more iteration than a traditional paid-for game might demand.

This means that the true independents have a higher barrier to entry than they did before. People expect a lot for free, and if you are not monitoring your audience with a deep level of detail, it’s very difficult to understand when the best time to monetise might be.

Example of the freemium model

Examples of the freemium model taking place inside a game can be found in many different scenarios:

Energy bars are everywhere. The new ‘World of Warriors’ game and ‘Clash of Clans’ from Supercell are good examples of energy meters. In both games, you have ‘food’ and various other ‘elixirs’ which are essentially energy meters. If you have ‘0’ food, you can’t play until it recharges. Regardless of what shape these roadblocks come in, they all serve an identical function: to slow down a player’s progress.

Mobile games would also appear to be getting easier and easier. The majority of these games would not work if a gamer could engage with them and play them for an hour at a time.

Energy meters and time constraints mean that you can only really play an app in small chunks. Unless you pay.

Naturally, a percentage of all users don’t want to wait for their timers to be refilled, so they will pay to get passed what was intended to be a roadblock.

In older, more traditional games, if the player was stuck at a specific part of the game, they would work hard to try and find a solution to the problem they face. However, now if you run into a problem, no matter the quality of the gamer, to get past what might once have been a complex problem – you can pay.

Another very common freemium model is charging for virtual items.

It’s difficult for game developers to understand what is a fair price to charge for various virtual items, but developers are now moving towards simpler monetisation tactics. For example, skipping a level or buying a considerable item which gets them past what was supposed to be a difficult level.

The problem with this is that items like ‘level skipping’ could be free, because it doesn’t actually cost the developer anything to offer hints.

If you compare this with a game we all know, Call Of Duty, giving a player the opportunity to buy new weapons or customise a character has cost the game developer/designer time and money.

Are freemium games killing developers?

Whilst consumers have obviously voted with their wallets that freemium games and applications are what they want to buy, some of us at Tapdaq believe that this has squeezed independent developers into a corner they might not necessarily have wanted to end up in.

There is no doubt about it, I think it’s harder to devote time into creating a game which is long and complex simply because of the natural shift to more casual gaming.

As with all markets, there are two sides to it. In this particular market, you have developers and you have players. If game players are so anti freemium games, then they need to do their bit. They need to start spending money on items which actually cost the developer resources to make, as opposed to buying hints and level-skipping upgrades which defeat the object of playing the game in the first place. They need to value the mobile gaming experience.

New freemium games come out every week in today’s quickly evolving mobile gaming market. This is a business model that, for the foreseeable future, will impact the games we all play. Therefore, game players need to go out and support games that are fair as well as fun to play. Players passionate about game sustainability must vote with their wallets as well as their words.

Looking at the graph below, freemium is proving to be great for developers, but it might have adverse effects, and who knows when we might start to see diminishing returns.

Freemium still has a large share of the market, but it’s unlikely to make you rich.Freemium still has a large share of the market, but it’s unlikely to make you rich.

I think we’ll continue to see larger game developers dominate the top grossing in various app stores for the foreseeable future, and I don’t think freemium as a business model for games gives a fair platform for genuine independent studios to thrive. However, individuals and small studios who create games are usually far more dynamic and should adapt to evolution faster than larger corporations.

So, is freemium killing developers? The answer is, we can’t be sure yet. One thing is certain, though,the industry will continue to be driven by its customers and customer perceptions of “free” games. Recent events have shown that there is a split between those who are happy to pay for games and additional content within them, and those who expect the game or updates to be free.

A winner for preferred business model has not yet emerged on the mobile platforms, and it is very possible that mobile gaming will evolve in a similar vein to its desktop/console brethren – with games adopting different monetisation methods based on their audience, content and personal preferences.

Let me know what you think in the comments below.

Categories
Tools

Popular ICEs for mobile hybrid app development

If you want to target multiple mobile platforms without having to maintain a separate code base for each one of them, mobile hybrid apps is one way to go. What mobile hybrid apps won’t do, though, is relieve you of the need to manage and use multiple tools, e.g. building your app for a specific mobile platform requires installing the platform’s native SDK on your machine.

popular-ice2

ICEs are here to take this headache away. ICE stands for Integrated Cloud Environment and it’s essentially an IDE that does some of its work in the Cloud. A typical ICE for mobile hybrid app development provides you with tools to design, write, test, debug and profile your app. It also allows you to configure the build settings of your app, manage its signing keys and compile it for various platforms.

[tweetable]One of the most popular features of ICEs is building your app in the Cloud[/tweetable] – they grab your code, upload it to the Cloud, build it and come back with the produced app bundle(s). Since the build process no longer takes place on your machine, there is no need for you to install any native SDKs. Apart from building, ICEs may also use the Cloud for storing your app or for pushing it to a device for testing purposes.

A mobile hybrid app development ICE traditionally comes with a companion mobile app that can be downloaded for free from all major app stores. This companion app acts as a container for your own app (your app runs inside it, so you not need to install the former on the device) and also provides some extra functionality (e.g. checking for new builds of your app).

So, here are four of the most popular ICEs for mobile hybrid app development (PhoneGap Build is not really an ICE as we’ll explain later on). But before diving into the details, the following tables provide a handy overview of these tools.

Tool Owner Free? Type
AppBuilder Telerik No Desktop-based (Microsoft Windows), Browser-based
Intel XDK Intel Corporation Yes Desktop-based (Microsoft Windows, Ubuntu Linux, Apple OS X)
Monaca Asial Corporation Yes * Browser-based
PhoneGap Build Adobe Yes * Browser-based

* A free subscription plan is offered (among others).

AppBuilder Intel XDK Monaca PhoneGap Build
Code editor
Drag-and-drop tool(s)
Source version control
Collaboration
Device simulator
On-device debugging
On-device profiling
Builds
Companion app

AppBuilder

With AppBuilder (previously known as Icenium) you can develop your app in collaboration with other members of your team, using both a code editor and a drag-and-drop tool (experimental and limited to apps that use Kendo UI).

AppBuilder allows you to test your app on a built-in device simulator, on native emulators installed on your machine, as well as on real devices (both connected and remote). In the case of real devices, you can either install your app or run it inside the AppBuilder companion app.

While your app runs on the simulator or on a connected device, you can debug it using the bundled debugger that’s based on Web Inspector. AppBuilder also allows you to automatically reload your app as you make any changes to its source code.

❢ AppBuilder offers Cloud-based storage and version control for your apps.

app-builder

Intel XDK

Intel XDK contains a bundle of tools: a code editor that is based on Brackets, two drag-and-drop tools that help you design your user interface (one supports App Framework, Bootstrap, jQuery Mobile and Topcoat, while the other is limited to App Framework), and a device simulator that is based on Apache Ripple.

In addition, Intel XDK allows you to test your app on real devices that are connected to your machine or are in the same wireless network as your machine. In both cases, you need to have App Preview (Intel XDK’s companion app) installed on your device. Similarly to Telerik’s AppBuilder, Intel XDK automatically reloads your app (if you’re using an Android handset) as soon as you make changes to the source code.

With Intel XDK you can also debug and profile a running app. On the device simulator you can use a debugger that is based on Chrome Developer Tools (CDT). On a real connected Android device (with both App Preview and App Preview Crosswalk installed on it), you can use weinre (WEb INspector REmote) and a built-in profiler that helps you identify hot-spots in your Javascript code.

❢ Intel XDK supports live layout editing. While your app is running on a connected Android or iOS device, you can preview the result of the changes you make to your HTML and CSS files as soon as you hit save.

intel-xdk

Monaca

Monaca allows you to collaborate with other testers and developers on developing your app. You can chat with them as you write code, and share your thoughts, as well as screenshots of your running app, while debugging it on a real device.

With Monaca, you can preview your app in a browser (with different device screen sizes and orientations) or run it on real devices inside Monaca Debugger (the companion app of Monaca). In both cases your app gets automatically reloaded every time you make changes to the code and save them.

You can debug your application in preview mode, using the debugger that comes with your browser. Alternatively you can debug on a real device, using Monaca Debug Panel, a tool based on Web Inspector. Some debugging features are also available on the real device; for example, you can view the source of the current page or inspect the application log.

❢ Monaca stores your code in the Cloud, and you can access it at any time and from any place using WebDAV.

monaca

PhoneGap Build

PhoneGap Build is not really an ICE, but rather a build service that works in the Cloud. It pulls the source code of your app from either a .zip file or a (private or public) Git repository, and then allows you select the platforms you want to build your app on. Throughout the building and testing process, PhoneGap Build enables you to collaborate with testers and developers from your team.

PhoneGap Build allows you to build debug-enabled and/or “hydrated” versions of your app. With debug-enabled builds you can remotely debug your app using weinre, whereas new hydrated builds can be automatically pushed to the devices and replace older ones.

❢ PhoneGap Build does not store the passwords for your signing keys for more than one hour since the last time you used them.

phonegap

To sum up

Mobile hybrid apps allow you to target multiple mobile platforms with less code, in less time, and with fewer programming languages. ICEs for mobile hybrid app development move parts of the development process in the Cloud (e.g. they build your app there), thereby adding one more benefit to the above list: fewer tools.

There are several reasons for trying out an ICE – the choices differ according to what you’re trying to achieve. If you enjoy writing code on the Web, you can use Monaca, while if you want to spend less time on writing code, AppBuilder’s and Intel XDK’s drag-and-drop tools might make your life easier. Keep in mind that using an ICE does not require abandoning your current editor or IDE – you can use any editor or IDE you like and then import your code into an ICE to test, debug or build your project. Finally, there are some cool features in this post that might have caught your eye – e.g. Intel XDK’s remote profiler or Monaca’s collaboration tools. So, get started with an ICE – and let us know what you think!

Update Dec 15, 2014: Monaca kindly informed us they also provide full debugging functionality via USB, using Chrome on Android and Safari on iOS devices.

Categories
Business

How to make money with apps

A major theme in our State of the Developer Nation reports is an increasingly gloomy picture of typical developer revenues. [tweetable]The vast majority of developers make very little money from their apps[/tweetable]. However, there are a lot of developers out there and a decent fraction of them make a good living, some are building thriving businesses on the app stores and a few at the top are even creating multi-billion dollar companies. So, what’s different about the developers that are succeeding financially versus those that are living in app poverty?

chapter3

Are you making money from your app? Let us know and you might discover new tools that can make you even more profitable. Start here.

There are two major risks when analysing groups of successful individuals or companies to try to work out why they succeed when others fail; the first is survivorship bias – ignoring the many failures that may have done exactly the same things, the second is confusing correlation with causation. In the latter case there are many things that developers do because they have a successful app, like porting it to lots of other platforms, that are completely unrelated to how they became successful in the first place. [tweetable]There isn’t a magic formula for success on the app stores[/tweetable] but we can try to avoid falling into these traps by looking at factors that might increase your chances of success.

In our last report we showed two major factors that correlate with higher revenues, targeting enterprises rather than consumers and using 3rd party tools. The former is almost certainly a direct cause of financial success, the later is probably indirectly related, tool use indicates a more sophisticated approach to app development as a business. There are many more factors that can make quite a significant difference to the chances of financial success with apps, so lets take a look at some of them.

As our benchmark we’ll use the rather modest (but challenging) goal of making more than $5k per app per month. This is a revenue level that would allow a single app to support a developer in the US or Western Europe but is below a typical employed developer salary in those places. In some countries it would support a whole team living very comfortably. How much more likely are developers to be earning above this level depending on which platforms, categories and device types they target or what revenue models they use?

Platforms

It’s been widely reported that iOS is still ahead of Android for revenues but there are suggestions that Android is closing the gap. Looking at overall revenues from the platform or the earnings of the very top developers, this may be the case. Some even earn more on Android than iOS. However, revenue is more concentrated at the top on Android than iOS, so the chances of earning above the $5k per app per month level are still much higher for those who primarily target iOS. Despite the decreasing popularity, targeting the mobile browser is quite far ahead of building Android apps too. In this case though, many targeting the mobile browser may already have successful desktop web businesses, so this might not be so easy to replicate for those starting new businesses. Windows Phone and BlackBerry 10 are both offering very low chances of a decent financial return as primary platforms. Note that this doesn’t imply that there’s no revenue available on either of these platforms, it could all be going to apps that succeeded on other platforms first and then ported.

App categories

It’s no surprise to see enterprise apps and business and productivity software at the top of the high earning app category charts. What’s more interesting is the “other” category between them. Developers who seek out and dominate niches outside the standard app categories are doing very well; it’s not the route to a billion dollar company but it’s a smart strategy for a small business. Despite the many reports of fitness trackers ending up unused in drawers after a few months, health and fitness related apps are doing quite well. It’ll be worth watching how the major platforms health and fitness data platforms impact this category. The success of the communications and social networking category at this revenue level is slightly counter-intuitive, this is a category with significant network effects favouring a few big winners. It seems that this is such popular use case for mobile devices that there’s room for a lot of developers to add value. To contrast with these, the categories at the bottom of the list are Kids (16%), Games (17%) and Education (17%). These bottom categories are pulled down by their popularity with hobbyists, giving full-time professionals targeting these categories a lot of free competition.

Device types

Smart TVs and set-top boxes are a surprise leader in terms of device types to target first. Only a tiny fraction of developers in our survey had these as their primary target, so this isn’t a reliable sample. It’s hard to get visible on TV platforms and you usually need content, so this might not be a strategy to emulate. The Internet of Things is also unexpected at number 2 considering how immature the market is. It may be the case that hardware sales are involved in many of the higher revenue earning businesses here, in which case there are much higher costs associated than for pure software businesses. While smartphones are a massively more popular primary target than tablets, the chances of an app earning above the $5k per month level are quite a lot higher on tablets. There are likely to be several factors involved here; less competition, more tablet apps targeting enterprises and with the reliance on free apps making most of their money from a small fraction of users, it can pay to provide an optimum experience for the heavy users on a larger form factor. This last point is valid right up to the highest revenue levels – Supercell have built their games tablet first with a scaled down experience on smartphones.

Revenue models

At the top of the revenue model tree is per device royalties or licensing fees.This is likely to be a mixture of enterprise apps and successful apps that have managed to get pre-installs on devices. This is a highly desirable revenue source but certainly not available to all apps. The next best is contract work at 30% of developers earning more than $5k per app per month. Contracting gives a decent chance of making higher revenues but of course the app belongs to whoever it is built for, so the upside is also very limited. At the same time this is by far the lowest risk model, with twice the chance of making more than $5k per app per month than the worst model, advertising. Subscriptions and e-commerce are tied for third place at 29% and affiliate and CPI programs are not far behind at 28%. These models are often harder to implement but our data suggests that the effort is likely to be worth it if they can fit the app concept.

Finally, an interesting comparison towards the bottom end of the revenue model scale is paid downloads (18%) versus free apps with in-app purchases (19%). There is very little difference between the two revenue models at this level of revenue. This is a very strong contrast with the total amount of revenue earned through each of those models. This probably reflects the fact that getting a freemium model with in-app purchases to work is difficult – there’s a very big risk of just giving a free app to a massive majority of users and getting no more paying users than for an equivalent paid app.

Conclusion and warning

There are a number of different ways you can target your apps and select your revenue model to increase your chances of financial success. What we haven’t analysed here is how these combine. Some of them probably won’t, for example, tablet first and iOS first is a good combination, but tablet first and Android first probably isn’t. Our analysis in the State of the Developer Nation report has also shown that some of these combine in an additive way, for example, building enterprise apps for iOS has very high chances of financial success.

 

Take the Developer Economics Survey, test your skills and compare them to the global average. You can work on those skills that need improvement and become more competitive. Cool, right?

Categories
APIs

What the logs don’t tell you

In a world that is increasingly dominated by mobile applications and cloud services, APIs are becoming crucial to developers and service providers alike. But what are developers actually getting? And is this what service providers think they provide?

error-logs

Developers

Developers want to use APIs that extend their service without having to either build the technology themselves or comply with required legislation or security (think payments or anything to do with storing large amounts of personal details).

[tweetable]Developers want simple, scalable, well-documented APIs that are as reliable as possible[/tweetable]. They do not want API they use to make their service unreliable, buggy or slow, i.e. make them look bad. Poorly-performing APIs can harm a developer’s reputation but also the API provider’s, should the branding of an API be visible to the world (think Twitter, Facebook, Instagram).

API Providers

API providers grant access to a service or services through the use of public or private APIs; a private API being a service that is not for public consumption for privacy or security reasons. Why grant access at all? To allow developers to use services and functionality that they do not have to build themselves and provide stickiness to an existing user base. Salesforce has done an amazing job of allowing third-party developers to use and extend the functionality that is provided and has even allowed developers to build a thriving apps and plugin community.

API providers look to balance the load on their servers that may also be dealing with other services. They are trying to provide minimum response times whilst maintaining the access and integrity of the data and the service for the developers.

Schrodinger’s API, it both works and doesn’t work at the same time

Here lies the problem; when an app that relies on an API performs badly whose fault is it? Is the app performing how the developer expected or is the API not responding and thus slowing the service? I[tweetable]t is very easy for the API provider to believe that just because the green light is on that the API is working[/tweetable]. Many systems behave completely different from the theoretical under load, when exposed to extreme conditions or elements beyond normal operation or even users doing unexpected things to the API.

Logs

System logs, either from servers, application monitoring tools or other conventional developer operating systems are excellent at hiding things because there is usually a lot of data to digest and identifying the issues from the noise can be nearly impossible.

Some examples include:

Averages – Whilst an average latency of 300ms may look ok its not if you are still getting a number of calls that take 10 seconds. To understand whether or not your slow performaning outliers are an issue means you have to look at the distribution of latencies and the frequency of the outliers.

Errors rates – hopefully these are low. Even a low error rate in a popular API can represent a huge issue. Consider an API that deals with 2 billion transactions a day at 0.2% error rate still has 4 million failed calls a day.

Logs only measure calls – If the API is not frequently used then the logs are not going to tell you anything. If the bulk of transactions are say only done on a Friday but the services failed on a Thursday then the detail will not be in the logs. Only frequent monitoring will notify you of issues before they hit your users.

Basically what the logs don’t tell you is how APIs work end to end, in different geographic regions and what the end-to-end latencies are when using real transactions.

Some simple rules

Monitoring is for life not just for Christmas.

An API that is switched on may not stay on but may be on every time you check.

The reliability of an API is inversely proportional to the number of people using it and the number of developers trying to do things that may break it.

The use of server logs is a function of user base and the amount of data being recorded.

Test the API like it would be used in the wild, end-to-end across a range of cloud services and apps. In this instance cloud services means hosting platforms like Google Apps Engine, Amazon Web Services and Azure to name a few.

Key question to ask is whether the servers are being tested for performance or the API and the impact on users and the overall experience?

As a developer and a user of services it’s the experience that matters. Poor experience equals poor brand perception, which leads to trying a different API or app, losing the client whether it’s a developer or a guy with an iPhone migrating onto the next app.

Things to consider when testing

Where is the data being served and where are your users?

An app that works in San Francisco when the server farm is in Mountain View may show differences when the same server farm has to serve the app in Europe. Test the API from different locations.

I got a HTTP200 response that means everything is fine, right?

Whilst most of us have seen HTTP 404’s, page not found, we also know HTTP 200 indicates an OK response from the server. The challenge comes from when a HTTP 200 means that things are not OK. For example, in order to avoid browser problems, some APIs only return HTTP 200 with an error message which needs to be parsed. Alternatively, the API might be returning invalid content which could cause an App to fail.

API search function comparison

facebook-vs-twitter-latency

In the above figure it can be seen that the average latency for search using the Facebook and Twitter API is approximately 2 seconds apart with Twitter being the faster and less erratic. Whilst we can only guess at what is happening in the background the reality is Facebook Graph Search appears to be less responsive to anyone using this feature in an app.

Regional server response variation

facebook-api-geo-latency

The above figure shows Facebook Get response across 6 regions globally. It can be seen that Asia and particularly Japan are poor cousins when it comes to regional performance. This behavior has been viewed with other APIs that have been tested in this way.

Caching data

search-caching-impact

The above figure shows the effect of caching on server response. After caching was implemented on the server it can be seen that response improved, even during refreshes (the spikes) overall performance was up.

Server issues

dropbox-api-latency

The above figure shows intermittent server issues over time. This can be indicative of load balancing issues or a problem with a server in a server cluster.

What is the future?

[tweetable]The number of APIs is only going to increase and developers are likely to rely on 3rd party services more and more[/tweetable]. It is also likely that more than one API from more than one provider will be used in an app. How can we mitigate against the response of one API compared to another? We see a need for intelligence in the app that can let that user know that something may be awry with the service trying to be accessed. This should be utilized as part of the UI flow to warn that ‘hey looks like is not responding, please bear with us’. This would be enabled by pinging the monitoring service to determine if there are any issues reported or the app being alerted automatically on a fail scenario that is outside pre-determined boundaries.

Intelligence in the monitoring will also lead to better understanding of the results and give a heads up to the API providers when issues occur or when the data is showing that a server is about to fail and allow providers to avoid downtime.

Disclaimer: Data was provided by APImetrics.io who focus on API Performance measurement, testing and analytics. John Cooper is advisory board member at APImetrics

Categories
Business

North American App Developer Trends 2014: Insights into the app economy powerhouse

North America plays a very central part in the app economy. Firstly, it is home to the companies that create all of the leading mobile platforms. These include some of the largest developer communities.  Secondly, it is the largest creator of app revenues. We estimate that in 2013, North American app developer trends contributed 42% of the world’s app economy. Developer mindshare in the region is also considered particularly valuable by OEMs and tools vendors. This is due to the disproportionate global shares of both venture capital and media coverage focussed on the region. North America is often the starting point for new developer trends with high smartphone penetration and relatively mature 4G networks.

07-NA-App-Economy 1200x900

For those that seek to understand developer trends and preferences in North America we have created a new report which compares the region to the rest of the world. The report covers developer mindshare for platforms, languages and tools. It also includes revenues and deeper dives into enterprise and game developer markets.

North America App Developer Trends report: Questions answered

  • Why are developers in North America more likely to target mobile browsers than those in the rest of the world?
  • Android mindshare is higher than iOS in North America. But by how much?
  • Despite lower mindshare, iOS is prioritised by more North American developers than Android. But how many?
  • How much more revenue does a developer in North America earn on average than one elsewhere in the world?
  • How is that extra revenue distributed amongst the developer population and across platforms?
  • Which revenue models are most popular and which are the most successful in North America?
  • Enterprise developers in the region make significantly more revenue than those targeting consumers. How many times greater is the average revenue?
  • Which revenue models do these enterprise developers favour? What’s their share of the total revenue pie?
  • Games are also monetised differently than other apps. Which are the most popular revenue models for North American game developers?
  • Ad networks are the most popular category of tool globally but not in North America. What’s more popular there?
  • What’s the breakdown of developer tool usage across platforms in the region?

The North American App Developer Trends 2014 report includes many more insights and explanations of key trends. If you need to know more about developers in the region then this report is for you.

Categories
Platforms

Cross Platform Apps – Qt vs. HTML5

Although building a separate native app per platform is currently proving to be the most successful approach for mass market consumer apps, there are still a lot of situations where it makes more sense to go cross-platform. In this article we’ll look at the most popular option, hybrid web apps built with HTML5, versus an up-and-coming challenger, Qt.

Cover_2

How do you build web apps? Take the Developer Economics Survey and let us know. Cool prizes await you.

Why Qt?

Those who know the history of Qt may be surprised to see it described as “up and coming”. Qt was originally designed for building cross-platform desktop apps, it’s creators started working on it in 1994! However, Qt became interesting for mobile development after Nokia bought Trolltech, the company developing Qt at the time, and invested heavily into making it the ideal toolkit for building mobile apps. Unfortunately, Nokia was making this strategic decision shortly before the iPhone launched (the acquisition was completed afterwards). This changed the game from building apps for devices with numeric keypads and Qwerty keyboards, to large touch-screen based devices. The former Trolltech engineers recognised that they needed a very different way of creating apps for Nokia’s offering to compete.

When Steve Jobs said that the iPhone was 5 years ahead of the competition at launch, he was not far wrong. Android had managed to close some of that gap, probably due to executives at Google having some advanced warning about the iPhone. Unfortunately, Nokia eventually gave up on it’s own Qt based devices in favour of Windows Phone as the software efforts were taking too long and they were falling a long way behind in the ecosystem wars. They sold Qt to one of their major services company suppliers – Digia – who have recently established a fully-owned separate entity for the product, The Qt Company. Only after being fully disentangled from Nokia has Qt been able to return to its roots as a cross-platform framework and start supporting the major mobile platforms. However, in the mean time, others had seen the great foundation for mobile apps that Nokia’s investment created. As a result the BlackBerry 10, Jolla Sailfish, Ubuntu Mobile and Tizen platforms all have Qt as a core framework.

From a personal perspective, I re-wrote a popular iOS game for Symbian using Qt in early 2011. The UI design and general debugging tools were a bit immature at the time but it was one of the simplest learning curves and most pleasant development experiences I’ve had on any platform (note: I was not paid to say that), even though the core of Qt is using the less than developer friendly but high performance C++. I was able to achieve smooth 60fps performance on some rather low-spec hardware. It was easy enough to learn their new UI technology, Qt Quick, and build the menu screens for the game with it in a couple of days.

Why HTML5, or why not?

HTML5 is the most popular option for developers building cross-platform mobile apps, however, it appears to be falling out of favour a little. Web browsers and web views are available on every platform and web developers are able to transfer their skills from building websites to building mobile apps. Open source frameworks like Cordova (PhoneGap) allow developers using HTML5 to access additional mobile specific functionality and make it easy to package apps in a native format for each platform. The added bonus is that you can usually have a version of your app on the web as well as in the app stores for minimal additional effort. HTML5 is generally more productive for building UI centric applications than native apps. There is also an embarrassment of riches when it comes to libraries and frameworks for building mobile web apps. Hybrid web apps are in the privileged position (on iOS at least) of being able to update their code directly, avoiding the App Store review process for all but major changes.

Slide12

Given its ubiquity and large developer base, why isn’t HTML5 the default cross-platform approach? [tweetable]Despite many advantages, hybrid web app developers have been struggling with performance[/tweetable] (partly due to crippled or outdated webview implementations, an issue which has been fixed in the latest versions of iOS & Android, although this will take a while to penetrate the entire installed base). There is also an issue with varying levels of support for standards across mobile browsers (again, this is something that’s improving but not entirely fixed yet). Web technologies have also not really been designed for the highly animated UIs that are now expected by mobile users. This is something that the much hyped Famo.us framework aims to resolve.

A number of very high profile consumer startups have publicly switched from web hybrid to native mobile app approaches. The most common reason stated for these switches has been lack of adequate tooling. It’s certainly possible to make web apps perform well on mobile devices within their limited memory budgets but with the current state of debugging and profiling tools, that’s still not an easy thing to do compared to producing native apps. This said, not all apps need flawless UI animations and we’re not comparing HTML5 with native, so lets look at how it goes head to head with Qt.

Qt vs. HTML5 – Pros & Cons

Supported platforms:

  • HTML5 is supported almost everywhere.
  • Qt is supported on all major platforms (and minor ones that happen to use it for their UI).

Although in theory you can target more platforms with HTML5, this is not how most developers are using it in the real world. [tweetable]HTML5 developers are increasingly abandoning the browser and building hybrid apps[/tweetable]. Most mobile developers are targeting some subset of Android, iOS, Windows Phone, Windows 8 and BlackBerry 10. Qt supports all of these and more. In fact, in practice our data shows that Qt developers actually target fractionally more platforms on average than HTML5 developers. As a result, this is basically a tie for most developers with a significant advantage to HTML5 for those who really want to run their software everywhere (feature phones, Smart TVs etc.).

Slide24

Learning curve:
This one depends whether you’re already a web developer. If you are, learning to build mobile web apps is probably easier than learning Qt. However, if you’re new to either then Qt has significant advantages in terms of having one framework to learn rather than 10s of them to choose from before you even start. Qt also has great documentation, which isn’t necessarily true for all web frameworks. In a fair contest, this is a clear win for Qt.

Openness:

  • HTML5 is open standards based and there are multiple open source implementations.
  • Qt is open source but dual licensed and effectively controlled by a single vendor.

Clearly HTML5 is more open than Qt. This isn’t always an advantage. The process of creating standards and getting multiple vendors to implement them is slow, Qt can be more agile. If you really need something fixed or a new feature added in open source you can do it yourself or pay someone to do it. If you need to support Internet Explorer and there’s an issue with it, you have to work around or wait for Microsoft. Then again, there’s no vendor lock-in with HTML5 and the web isn’t going anywhere. Someone else could buy Qt and take it in a direction that doesn’t align with your goals. Or they could just put the price up beyond your budget. HTML5 has the edge but it’s not a clear win.

Cost:

  • Building for HTML5 is free. There are some non-essential paid tools that can help.
  • Qt requires a commercial license for most commercial use on mobile.

Qt’s open source licenses are not compatible with distribution on most app stores. Although the iOS port of Qt is developed in open source, you need a commercial license to ship apps in the store. The lowest cost subscription that allows developing mobile apps for the iOS & Android stores with Qt is $25/month. HTML5 wins.

Cross-platform compatibility:

  • HTML5 has multiple independent implementations of a standard.
  • Qt has one vendor implementing the same runtime on multiple platforms.

Multiple implementations, with several in open source and a large community reporting on and working around compatibility issues makes for a very robust platform. Even so, having a single vendor making sure all platforms behave in the same way is almost always better for compatibility of your app. Qt wins.

Performance:

  • HTML5’s DOM was not built for modern mobile apps.
  • Qt Quick’s (QML) scene graph is built directly on top of OpenGL ES.

Both environments use JavaScript. However, with Qt it’s much easier to drop down to native code if you really need native platform functionality or performance. The performance penalties for switching between JavaScript and native code are much lower with Qt. The biggest difference however, is graphics performance. People looking for serious graphics performance with HTML5 resort to complex schemes to avoid touching the DOM as much as possible. Building the entire UI on top of WebGL seems like the most promising path to future performance, now that WebGL has much wider support (Apple adding this in iOS8 is key). Qt has a massive advantage here, it also has more extensive animation options than CSS3 for web app developers.

Native user experience:

  • With HTML5 you rely on either a 3rd party framework like Ionic or building your own clones of native interface elements.
  • With Qt you can use components that clone native interface elements, or use real native UI calls.

Being able to call native APIs in Qt potentially gives it the advantage here but in reality this loses cross-platform compatibility. In practice neither option is really well suited to situations where you need a genuinely native user experience. Both can emulate one adequately for a subset of possible apps. In general it’s best to use a cross-platform approach where a fully custom UI is needed, or a native look and feel is not essential.

Conclusions

Comparing across these metrics, Qt has a slight edge over HTML5. However, there are other metrics you could use that would give the opposite result. In practice the technology needs to be selected to fit the project. Both options have merits and if you’re an HTML5 developer who’s not already familiar with Qt’s offerings, they’re worth a look. I also didn’t mention that Qt apps can display HTML5 content in a webview, meaning that it doesn’t have to be one or the other, it can be both.

 

Which one do you prefer? Take the Developer Economics Survey and let us know.

Categories
Business

What Does Native Stand For In Native Advertising

Native advertising is not a recent buzzword.

[tweetable]Native advertising has been around for quite some time in the print and digital world[/tweetable]. Keyword-based search ads on a search results page, or an advertorial in a newspaper supplement are examples of such ads. But it’s only in the recent past that we have seen native advertising on mobile phones really take off. Traditionally, mobile advertising was limited to banner and interstitial ads but these ad formats compromised user experience. Native ads are a step-up from traditional ad formats and are designed to offer an in-context experience to the user.

Native-Content-Ads-1

What Makes Advertising Native

For an ad to be native, these are 3 things that matter – content, form and function.

  • Content: Does the ad unit have content that resembles the rest of the content on the page or does it stick out like a sore thumb?
  • Form: Does an ad become part of the content screen that the user generally takes notice of, or will it be a part of his blind spot?
  • Function: Does the ad unit match the functionality of the rest of the content or elements of the app in which it is displayed?

Native ads are deeply integrated into the mobile app. They mimic the look and feel of the content stream in which they are placed. This is completely different from traditional ad formats like banners, which due to their sticky position at the top or bottom of the screen have become a victim of banner blindness.

Native-Content-Ads-2

Consider a news app which has a feed with each news item consisting of a headline and an accompanying thumbnail. The content, form and function framework for native ads will then look like the following:

  • Content A native ad in this app should look similar to news feed, which means it should contain a headline and a thumbnail.
  • Form The visual elements of the native ad should be the same as that of a news feed. For example, if the thumbnail of every news item has a border, so should the thumbnail of the native ad.
  • Function If the news app requires users to scroll for news feed, then any native ad in this news app should also scroll along with the rest of the content.

Native ads sound great, but do they work

While the desktop world boasted of 1 – 2 percent Click-Through Rates (CTR) on native ads, mobile users seem to be more welcoming of this new ad experience. [tweetable]CTRs on native ads are 8X higher than traditional formats and advertisers are seeing 6X higher conversions[/tweetable] [source: InMobi network].

According to research by IPG Media, consumers looked at native ads 53% more frequently than display ads. The study also showed that users visual attention for native ads was nearly equivalent to the visual engagement of original editorial content.

Getting creative with Native Ads

There are a numbers of ways in which publishers can use native ads. The most commonly used ones are the app wall, carousel, chat list, content stream, content wall and news feed.

App wall

app wall

Carousel

carousel

Chat list

chat-list

Content stream

content-stream

Content wall

content-wall

News Feed

newsfeed

What to look out for while adopting native ads

Native ads are still relatively new to the mobile space and the level of customization offered varies amongst ad networks. Choosing the right ad network is therefore very critical when it comes to using native ads in your app.

Up until recently, native ads were implemented only by publishers with big teams, on a case by case basis with special effort required for every advertiser that they integrated with. The ease of integration offered by an ad network in terms of minimal programming overhead is another aspect to consider when integrating native ads.

Scale is the third thing you should look out for when monetizing your app with native ads. This wasn’t very scalable though. With more ad networks embracing the self-serve model, it is now possible to integrate native ads in your app without significant effort and in a relatively short time.

Focus on the user

The mantra behind native advertising is placing the user’s experience at the center. If not done well, native ads could boomerang on a developer’s monetization efforts. Editorial content and sponsored content (native ads) need to be clearly demarcated. Convention is to mark every native ad unit as an “Ad” or “Sponsored” content to ensure that users aren’t ‘tricked’ into clicking a native ad. As long as publishers and advertisers keep the user’s interests in mind, native advertising is set to transform mobile advertising.

Categories
Tools

Why Developers Should Embrace User Analytics

In our latest Developer Economics survey we were really surprised to see a dramatic fall in the level of adoption of User Analytics tools. A year ago they were the most popular category of third party tool with 38% of mobile developers telling us they used them. This time, only 21% of developers said the same thing. Why has there been such a significant drop? Are the hordes of new developers flocking to mobile just unaware of what’s available? Is all analytics being tainted by the spying scandals? Why does it matter?

user-analytics

The new mobile developer tsunami

At WWDC this June, Apple said that they’d gained almost 50% more developers in the last year. The vast majority of those will be iOS developers (rather than OS X and Safari). Android has been growing even faster in terms of new apps, so it’s likely there was even greater growth in the mobile developer population there. Windows Phone also saw significant growth in developer adoption. With so many new developers getting started building mobile apps we’d expect that they’re not all aware of the tools available to help. However, the reduction in user analytics adoption was greater than for other tools, indeed some tools categories saw increased adoption. So, although lack of awareness is clearly a contributing factor it’s not the whole story.

Tracking behaviours, not people

Information on government spying activities leaked by Edward Snowden has turned sentiment amongst many of the technically aware against digital surveillance. Perhaps some developers feel they shouldn’t be spying on their users’ actions? [tweetable]Does adding analytics to your app violate user privacy? Not usually.[/tweetable] User analytics tools are primarily for examining correlations between user behaviours and changes in the product or its marketing. If you make changes to a sign-up screen you need to see if it improves the fraction of users who sign up. If you’re trying to convert free users into paying users, it’s vital to analyse which changes in design or pricing result in greater revenues. Even to improve a paid up front or entirely free app, understanding what users do when they’re using it is incredibly valuable. As long as you’re not collecting personally identifying data and associating it with activity then it’s hard to see this as spying. Even segmenting users for behavioural targeting of functionality or advertising seems harmless as long as they’re anonymous. When analytics providers aggregate data across apps to build up user profiles for advertising, that may cross the creepy line for some. If this bothers you then choose an analytics provider appropriately, or collect your own data. If it doesn’t then having a privacy policy that clearly states who sees what data and what it’s used for is the responsible thing to do.

Coding blind

[tweetable]Updating and iterating on apps without analytics is apparently incredibly common[/tweetable]. It’s unlikely that all of these developers are regularly running user testing panels to get detailed feedback. Is everyone coding blind? To avoid constant app updates which would annoy users (and not even be possible with the review cycle on iOS) developers need to include multiple changes in every new version. If user sign-ups or revenue goes down after an update, how can you tell what went wrong? If things improve, which changes helped? Which parts of your app do people use the most? Are you working on improving features that no-one is using anyway? Without some kind of analytics, how do you find the answers to these questions? Might you be wasting a lot of effort?

Just integrating a third party analytics tool isn’t enough to answer these questions either. Apps need to be instrumented to log analytics events for every major action in the application and how long users spend on various activities. Beyond that, to really understand the effects of changes, users need to be analysed as cohorts – groups that started using the app around the same time. The value of an app to its users may increase or decrease over time and users who have got used to a UI are more likely to be unhappy with any changes. For an app that’s just starting to grow a user base, a change that causes it to lose 10% of existing users might still be positive if it increases revenues from new users. To know the real effects of some changes, it’s necessary to analyse specific sets of events as funnels. For example, in a registration or purchase process, increasing the number of people that start the process is no good if the number that end up completing it is reduced because they feel misled.

Tool choices

Developers that decide to embrace analytics have a lot of choices, however, the market is quite polarised. By far the most popular tools are Google Analytics and Flurry. These are (mostly) free. Google Analytics has the advantage with Android developers because it is integrated with Google Play, allowing direct tracking through the acquisition and download process into usage. It does have a (very high) limit on usage. If your app gets incredibly successful you’ll have to use the premium tier, which has a flat annual fee of $150k. Flurry on the other hand is free at every scale, although not as advanced as Google Analytics in terms of segmentation, funnels and visualisation of data. Both services are collecting data across apps, effectively to sell to advertisers.

There’s also a premium-only market with better support for cohort analysis, funnels, segmentation and visualisation. Paid offerings also link the analytics direct to actions, allowing automated real-time messaging to users, or the sending of push notifications to specific groups. Mixpanel and Localytics are two examples of tools in this space. These premium tools are also designed to be a lot more usable by non-technical staff, allowing a marketing team to analyse and react to analytics without always needing help from the development team. These tools have a fairly low user or datapoint count for a free tier and then start charging hundreds of dollars per month for successful apps. However, this means that they don’t sell the data from your app to anyone else.

A third option is the relatively little known Amazon Mobile Analytics solution. So far it’s relatively basic on the analysis front and doesn’t have the prettiest interface. However, you can collect 100 million events per month for free and beyond the free tier it’s just $1 per million events. By contrast, Mixpanel charge $2,000 per month for 20 million events. Amazon don’t share your data with anyone or report on it (no word on whether they use it internally for their own purposes).

Give it a try

Thinking about your apps as places to experiment and measure how the users react takes a change of mindset. If you’re not just building apps for fun then this shift can make a massive difference to your success.

If you’ve had a major change in results because of something you discovered using analytics, share your story with us in the comments.

Categories
Business Platforms

The 3 key Apple Watch features that nobody talks about. Yet.

[If Apple wants to create a new, large product category out of smart watches, they need to create mass-market demand for their new product. What are the 3 most important features that will define the future of the Apple Watch? The ones that enable developers to innovate on top of these devices and create demand for smart watches.]

apple-watch-09

“We believe this product will redefine what people expect from its category. … It is the next chapter in Apple’s story.” With these words, Tim Cook made it very clear that the Apple Watch is more than just an excellent product. As with the iPod, the iPhone and the iPad before it, the Apple Watch aims to shape the future of wearables and create a whole new market reality.

As it stands, the Apple Watch v1 is a nicely designed timepiece, an engineering wonder, but competition will be fierce. Since fashion is about self-expression, by definition, there will be no single winner.

If Apple wants to create something bigger than fashion accessories, the Watch needs to be a functional tool. If it’s a tool, [tweetable]Apple must answer a fundamental question: what is a smart watch for?[/tweetable]

https://twitter.com/brianshall/status/509405381857013760
https://twitter.com/BenedictEvans/status/509431691207659520

Will notifications become the killer app for smart watches? Unlikely. Not only is it unclear that we really want more interruptions, but it’s a bit of a dead-end for innovation. There can only be so many improvements in notifications, and only so many companies making those improvements.

If Apple wants to create a new, large product category out of smart watches, they need to become something much more that a timepiece with notifications and sensors. Something that allows people to do things that were not possible before. How Apple can do this? By following the same path that worked so well for iPhone and iPad: Tap into the limitless innovation power of co-creators to discover new use cases and possibilities we cannot imagine today.

The most important features of the Apple Watch going forward are the ones that enable developers to innovate on top of these devices and create demand for Apple’s smart watches. What are these features?

WatchKit

WatchKit

The straightforward way to expand the functionality of the watch is the WatchKit SDK, which allows developers to create “watch apps”. Other smart watch players like Android Wear, Pebble and Razer have made similar capabilities for developers. Developers are already showing strong interest in smartwatches. For example, the developer program of Pebble boasts 20,000+ developers and thousands of apps,.

HealthKit

The Apple Watch has a strong emphasis on embedded sensors for fitness and wellness. On the launch event, the company dedicated an entire section on it. Tim Cook: “This is a very important area for me and a very important area for Apple.”

But a few sensors and apps do not make a platform. The real potential lies in the HealthKit SDK that Apple launched at its WWDC event earlier this year. While its not technically a feature of the watch itself, it is this SDK that can take the device’s functionality and expand it in a whole new way to monitor activity and other wellness data . Could it be that the category that Apple wants to redefine is not the watch, but wellness and healthcare (in the broadest sense of the word)?

Certainly several other companies seem to go after that opportunity. Among them Google (Google Fit), Validic, Samsung (SAMI), Human API and most recently Jawbone (Jawbone UP API).

Identity

Like the Nymi wristband, the Apple Watch has all the technology in it to identify you personally. Apple has already demonstrated how digital identity combined with the Apple Watch can be used to make payments or even open hotel doors. (The clever integration with the new Apple Pay can drive adoption for both.) However, the possibilities are much broader. Biometric identification can be the end of not only passwords, but other kinds of ID as well. Another product category for Apple to redefine and absorb into its iOS universe?

Digital identity is a key control point for many digital leaders, including the likes of Google, Facebook, Twitter, LinkedIn and Salesforce. They are all actively working to hold your identity information and build your online persona on their platform. For Apple, the importance of identity is also evident in their deepening integration between devices and in their introduction of fingerprint sensors in all new phones.

Users first

What is a smart watch useful for? Beyond fashion and self-expression, a new kind of health monitoring and identity are prime candidates for the title of killer use case. Apple is going at it with their proven recipe for launching digital ecosystems: users-first. Apple starts by releasing a well-designed device for hardcore fans with a lot of value built in by default. Once there is a critical mass of users, Apple connects them with developers, who create real mass-market demand for the product.

It will take the ingenuity of a community of developers to explore all the possibilities and create a category killer, and Apple knows it very well.

Categories
Tools

Top Game Development Tools: Pros and Cons

According to our survey, a surprisingly high [tweetable]29% of games developers are primarily building their apps without a third party engine[/tweetable]*. They have either written their own engines, or are building everything from scratch. Large games studios very often build their own engines and tools, or customise open source solutions to suit their own internal processes and workflow. However, two of the most popular developer segments going for this option are Hobbyists and Explorers. It doesn’t make much sense for part-time game developers, or even small studios, to spend a lot of time working on their own tools rather than building games. In this post I’ll take a look at some of the most popular tools they could be using instead.

TOP-MOBILE-GAMES-TOOLS-FINAL

Which are your favourite tools for games development? Let us know in our new Developer Economics Survey and you might win an Occulus Rift Pro and other hot prizes.

Unity – the people’s champion!

unity

As developer tools go, Unity is incredibly successful. A massive [tweetable]47% of developers in our survey use Unity for some of their projects and 29% use it as their primary development tool[/tweetable]. This is not just Hobbyists taking advantage of the free licensing options, Unity is more popular with professionals in general and most popular with the Hunters (53% of them) who are trying to earn their living from the app stores.

 

Unity supports both 2D & 3D game development, which is quite unusual for a game engine. That said, Unity was really designed for 3D games with 2D support bolted on afterwards; the 2D features were initially just for building menus and other 2D screens needed in a 3D game, to avoid the need for an external tool. The features were quite generic and developers started building games with them; probably due to the broad cross-platform support. To their credit, Unity have supported this and continue to invest in the area.

Supported languages

Three development languages are officially supported: C#, UnityScript (basically JavaScript with type annotations) and Boo. The last of these, Boo is not widely used and probably best avoided. Given its name, you’d be forgiven for thinking that UnityScript is the main development language, it’s not. The Unity community has widely adopted C# and you’ll find the majority of plugins and examples use it. If you prefer JavaScript and only have a very simple project in mind then UnityScript is a good option. Once you start using plugins written in C# that potentially need to call back into your UnityScript you’ll find issues with compilation order and wish you’d gone with C# from the beginning.

Pros

Unity has a lot of great features:

  • Unity has a very strong community of asset and plugin creators – there’s lots of free and reasonable priced content available.
  • Unity’s visual editing tools are excellent and the editor can be extended with plugins.
  • It supports a wide range of asset formats and converts automatically to optimal formats for the target platform.
  • It supports a very wide range of platforms, mobile, desktop, web and console.
  • Deployment to multiple platforms is very easy to manage.
  • The 3D engine produces high quality results without any complex configuration (I’ve personally written a licensed game with Unity that Apple has featured in lots of countries).
  • There is a free license that covers the majority of features.
  • Paid licenses are very affordable for most professional developers, available on subscription for $75 per platform currently (some platforms are free).

Cons

There are a few issues which are worth considering before choosing to go with Unity:

  • Collaboration is difficult. Unity has an expensive asset server product to help teams collaborate. If you don’t use it, sharing code and assets between team members can be painful. The best option is to enable and use external source control but there are several binary files (which don’t need to be) that can’t be merged and updating assets often causes them to break things in scenes, losing connections to scripts and other objects.
  • Performance is not great – until very recently Unity ran almost entirely in a single thread and made almost no use of the extra cores in most mobile devices – this is improving in Unity 5. The compilers are not at all well optimised for the ARM processors in almost all mobile devices – Unity have decided to transpile to C++ and use LLVM to get a more optimised build rather than solve this problem directly in future releases.
  • The engine source code is not available. Even paying users don’t get to see the Unity source code, which means if you come across a bug in the engine you have to wait for them to fix it or work around it. It’s always going to be more critical for you than it is for them. This also limits the ways in which you can extend or customise the engine.

Overall, Unity is a great choice, particularly for solo developers who aren’t trying to push the limits of what the platforms can do.

Cocos2d – perfect for casual games

cocos2d

Cocos2d is, as the name suggests, a 2D games engine. It originated around the same time as the iPhone SDK and quickly switched to Objective-C, growing in popularity as the best free and open source option for mobile games. However, Apple released their own highly performance optimised 2D engine for Objective-C developers called SpriteKit. That, along with the rise of Android, has caused the focus of Cocos2d development to shift towards the cross-platform Cocos2d-x branch written in C++. The Cocos2d family of engines is the most popular open source option in the world, used by 19% of game developers in our survey and by 8% as their primary tool.

Supported languages

There are different versions of Cocos2d available in Objective-C, C++, C#, Java, JavaScript and Ruby. As mentioned above, the C++ version is the most actively maintained, it also has the widest range of supported platforms. There are also scripting language bindings to the C++ version in both Lua and JavaScript, enabling developers to write in their preferred scripting language but get the full native performance of the underlying engine.

Pros

As with most thriving open source products, there’s a lot to like about Cocos2d:

  • Broad range of supported platforms, particularly mobile ones.
  • Free and open source (MIT license).
  • Wide range of extensions, tools and open source code available.
  • Lots of community created examples and learning resources.
  • Large peer support community.
  • Hardware accelerated graphics and good performance.
  • Audio support (in most versions).

Cons

Nothing’s perfect, here are a few issues with Cocos2d:

  • There’s no large commercial entity providing support and bug fixes. It’s great that you can fix it yourself, or hire someone who knows how. The community might even fix your issue for free but sometimes when a big project hits a bug or performance issue close to a deadline you just want to be able to pay someone to make it go away.
  • The APIs are somewhat unorthodox. The history of the project is such that it started in Python and moved to Objective-C very early. The Objective-C wasn’t exactly following standard practices and then that got ported to C++, retaining the Objective-C idioms.
  • It doesn’t do much to encourage good structure. Some developers like frameworks that don’t impose a style on their apps but Cocos2d goes a bit far. It’s possible to write code that’s hard to maintain in any system but it’s easy to find examples of Cocos2d games with really long functions and a lot of global state.

OK, the cons are nit-picking and more warnings that really negative points. After all, poorly structured code and unusual APIs are not exactly barriers to success. I’ve ported a game from iOS that was written with Cocos2d (the Objective-C version, before the C++ variant existed) and almost one giant method with tens of global variables. At one time it was the number 1 paid download on iOS in several countries. Cocos2d-x is an excellent choice for a 2D game.

Adobe AIR – what remains of Flash

Adobe AIR

In 2007 Adobe seemed to be winning the casual games runtime battle, with Flash having become the defacto standard for games on the web and Flash Lite almost ubiquitous on more advanced mobile devices. Then the iPhone came along and Steve Jobs said it wasn’t going to support Flash. This knife wound wasn’t immediately fatal but Flash has been slowly bleeding to death ever since. By 2011 Adobe eventually produced a version of AIR that compiled Flash to native iOS apps but by then the damage was done. Android initially supported Flash, poorly, in the browser but Adobe eventually gave in and stopped developing the browser plugin to focus on AIR. There are still a lot of Flash developers in the world, 15% of mobile game developers use it and 6% of them as their primary tool. It’s also still, just about, the only way to target rich gaming experiences to the majority of the world’s desktop web browsers. Adobe is now focussing on tools for HTML5 developers and Flash/AIR has not really evolved in a long time. Given this background, I won’t focus on detailed technical pros and cons as with the other tools.

Supported languages

Adobe AIR applications are developed in Flash, coded using ActionScript. There’s an integrated web view which can be targeted with HTML, CSS and JavaScript. It’s also possible to build native extensions for AIR apps, individually for each targeted platform.

Pros

Flash is still a capable environment for simple 2D games. If you already know Flash it’s one of the fastest ways to build a mobile game.

Cons

The platform is a dead end. I couldn’t recommend anyone who doesn’t already know Flash to learn it. Those who are fans of ActionScript but don’t like HTML5 should probably look at Haxe.

Unreal Engine 4 – the AAA king goes mass market

Unreal-Engine

The Unreal Engine has a long history as one of the top 3D games engines for PC and console platforms. The 3rd generation of the engine supported mobile platforms but it was really only for hobbyist developers tinkering with their limited UDK or the multi-million dollar licensees of the engine for console games porting their titles to mobile devices. In March this year, Epic Games released the Unreal Engine 4 to anyone for $19/month plus 5% revenue share. This offering includes full access to the engine source code and their suite of tools. This change was not long enough before our survey was launched to see significant adoption by developers but 13% were using it with only 3% as their primary tool.

Supported languages

The Unreal Engine is written in C++ and that’s the only supported development language. However, it’s possible to do a lot of development without writing any code using Blueprints – a visual programming environment where nodes are connected with lines.

Pros

The Unreal Engine is AAA game quality:

  • Incredible performance. The Unreal Engine was demoed using Apple’s new Metal graphics interface at WWDC. It can produce the most realistic graphics ever seen on an iOS device. The same will be true for (high end) Android devices.
  • They have state of the art tools for all aspects of game development.
  • Full source access enables extension, customisation and engine bug fixing.
  • The pricing model is an excellent match for the high risks of failure on the App Store.

Cons

The Unreal Engine is designed for professionals:

  • Development is in C++, not a beginner friendly language.
  • The learning curve for the tools and engine is significant, greater than Unity.
  • The engine has limited support for older devices.
  • The pricing model is very expensive for a successful title, unless you expect significant success and use the engine under a different licensing model.

The Unreal Engine is an excellent option for high quality 3D games on high end mobile devices but it won’t be for everyone. I expect to see increasing adoption across the next couple of years. If you’d like a free 3D engine with scripting language support it might be worth checking out Project Anarchy by Havok. It’s effectively subsidised by Intel (owners of Havok) for mobile devices. There’s a co-marketing option in the license and you have to build an x86 variant if you build for Android (or Tizen, if that ever happens), otherwise it’s completely free, only the PC version is paid.

* Apple’s SpriteKit on iOS is actually a fully functional 2D game engine but as it’s part of the platform, developers may legitimately have said they were only using native code. If this is popular then it may significantly reduce the 29% figure.

Which are the best and worst aspects of each tool? Here’s your chance to have your say. Take the survey.