Author: Mark Wilcox

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

Categories
Business

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
Business

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

North American app developer trends

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
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
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.

Categories
Business

Is the Indie App Opportunity Gone?

The app stores created an opportunity for any developer to build their own products and reach a global audience with them. For some developers this offered the promise of an independent app business, giving them creative control of their work and hopefully a comfortable income. Recently there have been lots of posts (great summary list here) from current and former independent app developers about the state of the market and how much harder it is to earn a living from your own apps. If it’s tough for established indie developers then is it still possible to get started? We’ll look at how the market has changed and share some data on the revenues of over 500 solopreneurs and small indie developers versus their bigger rivals.

indie_game

The indie developer gold rush

[tweetable]A key advantage of small indie app developers is their agility[/tweetable]. They can shift their strategy to take advantage of new opportunities incredibly quickly. The success story that may have started the iOS app gold rush was built before there was an official SDK or App Store. Steve Demeter was working on ATM software for a bank and built the game Trism in his spare time, initially releasing it for free to the jailbreak community. When the App Store launched it was initially a $5 paid download that earned $250,000 in profits in the first two months. Demeter quit his day job to become one of the first full-time iOS indie app developers. Trism was reduced to $3 to stay competitive but went on to sell around 3 million copies. Four months of evenings and weekends, just a few weeks equivalent in full time development, earned a life-changing amount of money.

It’s the overnight success stories like these that continue to drive lottery-like behaviour from some developers. Playing for the outside chance of winning big. Even the media coverage at the time noted the increasing competition with more than 1500 iPhone games available in the App Store! Today’s developers would love so few apps to compete against; there are now hundreds of times as many.

Raising the bar

By 2011 life-changing solo developer success on the app store looked rather different. A $5 app created in a matter of weeks wouldn’t stand a chance. Andreas Illiger is a gifted musician, artist and coder. His Tiny Wings took 7 months of full time effort to create and sold for just $0.99. The increased scale of the platform meant he was able to sell more than 10 million copies. In 2014 it’s debatable whether a solo developer will ever repeat the feat. Monument Valley looks like the modern benchmark for a chart topping paid game title but developer UsTwo primarily serves clients in three countries and has over 100 staff in the London studio that created the game. Sirvo’s Threes! is a better comparison yet it was created by three people over a 14-month period (not full time). Threes! was almost immediately copied with numerous free alternatives to the $1.99 original springing up. Whilst Tiny Wings enjoyed a year as a top 10 game and another two inside the top 50, Threes! is already in danger of heading out of the top 100. [tweetable]There’s just so much free-to-play competition[/tweetable]. Making a more complex game to differentiate from the crowd is just beyond the scope of most small independent developers.

Not just games

Those examples have focussed on games and it’s tempting to think non-game apps might be a different story. However, consider that our data shows only 33% of developers are making games. Those developers collectively earn over 80% of store revenues across iOS and Android. So [tweetable]67% of developers are competing for less than 20% of store revenues[/tweetable].

Lets take a look at what Hunters (our name for developers that are aiming for direct revenues from their apps) can expect to earn at different company sizes.

As you can see, iOS is still a much healthier place for an indie app developer to be than Android but unless your cost of living is very low then the chances of making a comfortable living aren’t great. The bigger developers are taking over the top charts. [tweetable]If you’re outside the top app charts then it’s incredibly hard to get noticed[/tweetable]. Some of the successful smaller developers in our survey already have established apps with a strong history of downloads and ratings that keeps them high in the search results. If you’re just starting out, is it still possible to join them?

Find the right sized niche

The key difference with non-game apps is that they don’t all compete for the same attention. If your indie developer dream is to build the app you really want to use and be richly rewarded for it, you’d better have a fairly unusual problem that you want solved. Jared Sinclair’s Unread is the cautionary tale for those wanting to build for other technology lovers like themselves. An RSS reader (or client for any popular internet activity), however beautifully executed, has to compete with a vast array of free alternatives. Many of those other apps will have been built by hobbyists with no need to make any revenue at all. Anyone wanting to succeed as an indie developer today needs to think like a small business. Trying to compete with hobbyists is as futile as trying to compete with Google.

The right sized niche for an independent app is one that’s small enough not to be interesting to much bigger competitors but big enough to earn a living. Even winning the niche is not going to support a big team. The best niches will need specialist knowledge or intellectual property that make them both unattractive to hobbyists and defensible. Ben Thompson provides a great case study of Pleco, a Chinese dictionary app with some high-value in-app purchases. This example has two key advantages worth replicating: unique licensed content and a natural channel to market outside of the app stores.

What about getting rich?

If that sounds more like hard work than the indie developer dream of becoming an overnight app millionaire, it is. It’s also many, many times more likely to succeed. [tweetable]If you want to be an app millionaire then build contract apps for businesses and grow a team[/tweetable]. Then build some products for enterprise customers in niches that won’t attract immediate competition from much better funded rivals. Or get some venture capital and think really big! If you prefer the dream of being a millionaire, stick to building apps in your spare time. Better yet, buy a lottery ticket, it’s much less effort for about the same odds.

Categories
Business

The European App Economy 2014: Europe is losing ground to Asia

We have just published a research note with an update to last year’s an European App Economy report. The good news is that Europe’s app economy still accounts for 19% of global revenues and is growing strongly at a 12% annual rate. The bad news is that the rest of the world, particularly Asia, is growing much faster. The global app economy is growing at 27% annually and the share of revenues captured by developers in the EU28 is falling. We estimate that around 1 million European jobs have been created by the app economy so far. If policymakers want to see this job creation continue then there’s a lot more they could do to support developers attempting to create businesses.

European-App-Economy-2014_final

A $16.5 billion market

In our App Economy Forecasts 2013-2016 report we estimated that apps and app related products and services would generate $86 billion in revenues globally in 2014. The 19% share of this generated by European developers will contribute $16.5 billion to EU28 GDP this year. This is many times more revenue than is generated directly in the app stores. However, the EU is home to the top 2 app store earners globally in Supercell (Finland) and King (UK) – masters of the Free-to-Play games market. At the same time, European policymakers are some of the most vocal in attempts to enhance consumer protection with respect to the Free-to-Play model. So far there is only strong encouragement to reform practices around cost transparency but this could (justifiably) lead to regulation if insufficient voluntary action is taken. Significant changes in this area would undoubtedly impact the revenues of Europe’s most high profile app market success stories.

1 million jobs

We estimate that the number of direct European app economy jobs is up 26% from 2013 to 667,000, this breaks down as 406,000 professional developers and 261,000 non-technical roles in app-related business. Using a conservative multiplier we also estimate another 333,000 jobs have been created indirectly by the app economy in the EU28 for a total of 1 million jobs. A large fraction of these jobs are in software services companies taking the low risk route to profitability building apps on a contract basis. Contract software development is the most popular revenue model in Europe, favoured by 31% of developers. This may be partially due to the relative lack of seed capital for startup ventures in the region along with a relatively high cost of living versus most global competitors, making bootstrapping products more difficult.

2a

Slower growth

Although the European app economy is growing at less than half the global rate, some loss of share was unavoidable. Europe was very quick to reach high levels of smartphone penetration and most of the device sales growth is in developing markets. A significant fraction of demand for apps will always be filled by local developers with better market knowledge. As smartphone penetration increases in developing countries their local app economies are growing rapidly. European developers are well placed to export to English-speaking markets and South America but it’s not so easy for them to succeed in Asia. It’s likely that developers based in the EU will need specialist support or local partners to maximise app export opportunities in some of the fastest growing markets.

The enterprise opportunity

As smartphones reach saturation, businesses will play an increasing role in the growth of the app economy in Europe. In our Business and Productivity Apps report we forecast that this sector would experience rapid growth, reaching $58 billion globally by 2016. We have identified 5 areas where app developers and startups can add value in the business & enterprise app sector:

  • Vertical market specialisation
  • Productivity/BYO apps
  • Mobile SaaS
  • Bespoke enterprise apps
  • Mobile application and device management

While European developers are well placed to win bespoke enterprise app development business, they may struggle to compete with better funded rivals from other regions for the larger opportunities. Starting a technology business has never required less capital but scaling an enterprise software business is incredibly expensive to do quickly. The biggest mobile SaaS, application management and vertical market opportunities are likely to be venture capital fuelled land grabs. To ensure that Europe makes maximum gains from the future growth of the app economy, policymakers need to do all they can to keep app entrepreneurs from relocating to Silicon Valley in order to access the expertise and capital they need to compete.

Categories
Business Platforms Tools

State of the Developer Nation: The App Economy Consolidates Before the Next Gold Rush

app economy

Our 7th Developer Economics survey broke all records again, reaching more than 10,000 app developers from 137 different countries. The full report with the survey findings has just been published and is available for free download!

The view of the app economy that they collectively provide is one of consolidation. Developers are focusing their attention on fewer platforms and app revenues are becoming increasingly concentrated amongst the top publishers. Consolidation in the developers tools sector may also be partly responsible for the decline we see in tools usage. This is also reflected by the platforms, with BlackBerry moving their focus away from consumer smartphones and Microsoft killing their recently acquired Asha and Nokia X platforms to double down on Windows Phone. Fortunately there are several indicators that the next gold rush is just getting started.

Platform Wars in the App Economy

On a global level the platform wars are ending with iOS claiming the majority of the high-end device market and Android winning almost everywhere else. This results in [tweetable]Android leading in developer mindshare at 70% with iOS a clear second with 51% of developers targeting the platform[/tweetable]. However, we’ve been tracking this metric since 2010 and there is a new pattern. [tweetable]Windows Phone was the only platform to gain developer mindshare, rising steadily to 28%[/tweetable], despite failing to gain device market share. Although Android and iOS lost developer mindshare, this was not fewer developers prioritising either platform, rather more developers are now choosing sides. The average number of platforms a developer targets has fallen from 2.9 to 2.2 over the last 12 months, with more than 40% only targeting a single platform.

DE2014Q3_Mindshare

BlackBerry 10 is rapidly leaking developer mindshare, down to 11%, having failed to gain traction with consumers. Meanwhile, it’s now becoming increasingly clear that [tweetable]the future of HTML5 lies beyond the browser[/tweetable]. Although HTML5 is used by 42% of developers as a technology for app development, only 15% still target mobile browsers as a distribution platform.

A surprisingly high 47% of iOS developers and 42% of Android developers are using something other than the native language on their platforms. While hybrid apps are the most popular non-native option for building Android and iOS apps, they’re only used by 13% of developers. Hybrid apps are HTML5 apps with a native wrapper, typically created by tools such as Cordova.

DE2014Q3_NativeMyths

App Revenues

The majority of app businesses are not sustainable at current revenue levels. [tweetable]50% of iOS developers and 64% of Android developers are below the “app poverty line” of $500 per app per month[/tweetable]. 24% of developers interested in making money earn nothing at all. A further 23% make less than $100 per app per month. The overall app economy, including all revenue sources not just the app stores, is still growing but the revenues are highly concentrated. At the top end of the revenue scale there are just 1.6% of developers with apps earning more than $500k per month, collectively they earn multiples of the other 98.4% combined.

DE2014Q3_iOS_vs_Android_Revenues

State of the Game Developer Nation

Games dominate app store revenues, yet most games developers struggle. [tweetable]33% of developers make games but 57% of those games make less than $500 per month[/tweetable]. Experience breeds success in the games market. The more games a developer has shipped the more likely they are to be financially successful. However, 70% of games developers have shipped less than 4 titles.

Games is a multi-platform world with the average games developer targeting 3 platforms versus 1.75 platforms for non-games developers. Multi-platform games benefit from cross-platform game development tools with Unity by far the most popular, used by 47% of developers. The next paid tool, Adobe Air, comes a distant second at 15%. Apple and Google’s latest graphics technologies launch a battle for the richest gaming experiences. Third party game development tools like Unity and the Unreal Engine will be key to developers exploiting these capabilities.

DE2014Q3_Game_Dev_Tools

Tools of the App Developer Trade

Third-party tools are a critical part of successful app businesses. There’s a strong correlation between tool use and revenues, the more tools a developer uses, the more money they make. We successfully predicted the rise of the Mega-SDK, where consolidation amongst tools companies allows developers to integrate multiple tool categories from a single vendor. Despite this, tool use is declining, partly due to the rapid influx of new mobile developers. These new developers are typically not aware of the tools that are available and thus reduce the average usage levels. 26% of developers that are interested in making money don’t use any third party tools, up from 14% just 12 months ago.

DE2014Q3_Tool_Popularity

The most popular category of tool is Ad Networks, with 30% of developers using them. However, this is one of the few tool categories that is not associated with higher than average revenues. More experienced and successful developers show a preference for Cloud Computing platforms, such as Amazon Web Services or Microsoft Azure, with 40% of those with 6+ years experience in mobile apps adopting them.

Enterprise Apps – The Next Gold Rush

[tweetable]Enterprise apps are already the safest bet in the app economy and they’re only just getting started[/tweetable]. 67% of mobile app developers primarily target consumers and 11% target professionals directly. The 16% of developers who target enterprises are twice as likely to be earning over $5k per app per month and almost 3 times as likely to earn more than $25k per app per month.

DE2014Q3_Enterprise_vs_Consumer

Penetration of enterprises with mobile devices and solutions is already broad but not yet deep. Currently iOS appears to be winning the battle for enterprise adoption and revenues. Yet many developers are focusing on the wrong platform with 10% more enterprise developers targeting Android than iOS. Although enterprise apps have been a historical strength for them, Microsoft and BlackBerry are seeing very weak adoption for their new platforms amongst enterprise developers due to lack of demand from enterprises.

This battle is in the very early stages. Microsoft is re-focussing on their core competence in productivity software while Apple and Google move rapidly to embrace enterprises. Google’s integration of Samsung’s Knox platform into the Android platform is a major step forward. Meanwhile Apple’s new partnership with IBM gives them a strong proposition in all the major vertical markets. These moves will undoubtedly drive greater adoption of mobile technology in enterprises and create countless opportunities for developers to help re-think the way we work.

For more information, download the full Developer Economics Q3 2014: State of the Developer Nation report and check out the war between the European and the Asian app economy.

 

Categories
Platforms

Building a business not just an app? Start with the revenue model

The number of app developers using business models that don’t rely on app store payments is increasing. In some cases this is sophisticated app developers adapting to the market. In many cases it’s simply a greater number of existing businesses starting to use apps as a channel to reach potential customers. We can use the data from our Q1 Developer Economics survey to examine which strategies carry the most risk and which have the greatest chances of success. Could you use one of the more successful models for your next app?

business models - mobile platforms

We asked developers to tell us all of the revenue models they use and also whether their business was loss making, breaking even, making a slight profit, or generating comfortable profits. Revenue model popularity and a sample of profit & loss distributions are shown below.

Build apps for other people

[tweetable]Contracting is the most popular revenue model and also the one associated with the second lowest probability of making a loss[/tweetable] and third highest probability of comfortable profits. Of course, contract work also has strictly limited upside – it’s not really possible to build a scalable business around contract work without becoming a global giant consulting company. That said, the [tweetable]majority of developers would be better off if they spent most of their time on contract work rather than their own apps[/tweetable].

App store payments and advertisers

The next most popular revenue models, in-app advertising, paid downloads, in-app purchases and freemium are all relying on directly monetising an app. Together they are the four most risky models with the lowest chances of profit. [tweetable]Paid downloads are the least successful revenue model[/tweetable]. Although easy to implement there are very few cases where offering a straight paid download will create a financial success. Even on iOS, despite a still growing user base, the paid download market appears to be contracting fairly rapidly in the face of free app alternatives with in-app purchases. Despite the advantages of the in-app purchase model, it’s still quite far behind other models.

Selling services

Subscriptions are the next most popular and also relatively low risk and successful. However, implementing subscription based services is usually more complex than selling apps or virtual goods. Many subscription based businesses are simply using an app to sell subscription content. Another interesting possibility for developers in this area is to resell generic cloud services by adding value on top. As very basic (and already well served) examples, re-sell storage by adding document collaboration or photo management features on top.

Providing services that app developers can resell is one model for those selling developer services. Others include tools or services that help developers design, build, market or monetise their apps. This is one of the lower risk models with a good probability of profit. It follows the classic advice that when there’s a gold rush, the best thing to do is sell picks and shovels. There are still plenty of opportunities in this space (where are all the tools that help me prototype animations?) but also others with too much competition (some BaaS providers are already shutting down).

Selling stuff

[tweetable]Apps that make money through e-Commerce are the most successful in terms of making comfortable profits [/tweetable]and have by far the lowest risk of making a loss. Most developers using this model had existing e-Commerce businesses and have just added mobile apps as another sales channel. There are some startups with mobile first commerce apps though. More than 50% of developers using this model make comfortable profits related to their apps, so the cost of building apps is more than paid for by sales through them.

Affiliate and CPI programs allow developers to sell other people’s stuff. Using an affiliate program could be selling products related to your app through Amazon. Alternatively, a travel guide app might integrate a flight search SDK that provides a native search experience within their app – the developer gets paid whenever anyone books a flight. Affiliate programs were very popular on the web and their native counterparts are likely to be as well. CPI programs are for selling other developers apps, or at least getting users to install them. The top free-to-play games have extremely high ARPU and as they try to grow rapidly it makes sense for them to pay almost anything less than their ARPU for a new user (since new users boost chart ranking and thus organic installs). Other apps are a good place to advertise apps, so this is likely to be quite a lucrative option until either there’s an oversupply of quality advertising inventory or a crackdown on free-to-play games.

Royalties or licensing

We skipped per-device royalties or licensing in the middle of those last two. Overall this doesn’t have much lower risk than relying on the app stores or ads. However, this is inherently a higher risk strategy with bigger rewards for success. It usually involves building a product for large companies or even OEMs. The downside is that the number of direct customers in the target market is usually quite small. This is usually a model for those with great connections, a lot of funding, or both.

Build a business, not just an app

The app stores made it really easy for developers to sell software to a very large audience for the first time. With over a million apps each for iOS and Android, that is no longer the case. Discovery is hard and larger, more sophisticated organisations are dominating the top charts. If you have a great idea for an app, see if you can find a great revenue model to fit it. If not, try to come up with another idea. Outside of the VC-funded startups, developers that succeed will be the ones that think about where their revenue will come from before they’ve started building the app.

For more information of the success recipe of mobile apps, check out our App Economy Profits report.

Categories
Languages

Understanding Swift: 5 things app developers should know

The most surprising thing to come out of Apple’s WWDC event this year was a new programming language for iOS and Mac development – Swift. To the sceptical this might not seem like anything more than a way to entice more new developers to build apps exclusively for Apple platforms and lock them in. While investment in developer tools is always partly about making a platform attractive to developers, this move has far more benefits and strategic implications.

Swift-de

1. What is Swift?

Swift is a statically typed, compiled language, interoperable with the Objective-C and C code that are currently used to build Apple’s platforms and the native apps that run on them. However, it also has the feel and features of more modern scripting languages. In creating Swift, Apple has attempted to give developers the best of both worlds, the performance of native code but the convenience and productivity of a scripting language.

2. Faster, Safer and Less Code

In fact, Apple claims that Swift is faster than Objective-C, yet at the same time developers are freed from the burden of explicitly declaring types (they’re inferred), or manually managing memory (it uses automatic reference counting). With features such as “optionals” (a generic way of checking if things exist before using them) and type safety (no default attempt at an implicit cast), the compiler is able to prevent many of the worst bugs that crop up in the C family of languages while reducing the amount of code that has to be written and maintained. Another productivity enhancing change from the legacy of C is the elimination of header files, keeping interface definitions and implementations in one place.

3. Interactive

Although reducing the amount of code required to perform simple tasks is productivity enhancing on its own, even greater benefits are obtained by reducing feedback cycles. In the same way that a simulator allows more rapid testing of new code and ideas than building for a device and installing, live coding environments provide almost instant feedback as the code is written. Such tools are not traditionally available to compiled languages but Apple has created “Playgrounds” for Swift. These don’t provide live coding for an entire app but allow developers to experiment with new algorithms or bits of UI in such an environment before copying them into an app. Similarly, whilst being able to inspect variables in a debugger is useful, it’s even better to be able to interact with an app while it’s running. Swift provides a REPL (Read-Eval-Print-Loop) for this, much like the debug console for JavaScript in most browser development tools.

4. Functional friendly

The language also has functions (and closures) as first class objects with a much more readable syntax than Objective-C’s blocks, making it easier to apply functional programming techniques. This could be particularly helpful for fans of Functional Reactive Programming (FRP) – a programming paradigm that has been gaining in popularity for app development amongst a lot of smart developers. It helps to eliminate complexity when dealing with things like user input and asynchronous network communication – two key areas for most mobile apps. A team at GitHub actually created an FRP library for Objective-C, called ReactiveCocoa, which is extremely well thought out but forced into the most painful syntax by the language.

5. What’s the catch?

Sounds a bit too good to be true, right? Being a compiled language and using reference counting, rather than a garbage collector, developers are still responsible for avoiding memory leaks due to strong reference cycles. These happen when two objects refer to one another, directly or via a chain of other objects. So, while the language may be beginner friendly, it makes it fairly easy to write code that leaks memory. To avoid this, developers need to understand how the memory is managed for them and how to break these cycles. It’s not horribly complex but it’s a long way from not having to worry about memory management at all. That said, most iOS apps will get away with leaking a bit of memory – usually the device will just silently kill them in the background when the memory is required for another app.

Being compatible with C and Objective-C makes Swift a fairly big language – there are quite a lot of concepts and bits of syntax to learn for a new developer, rather than one coming from an Objective-C background. Also, as a type safe language, Swift is going to be much less forgiving to the novice that would prefer the compiler just figured out what they meant when comparing the integer 1 with the floating point value 1.0 or the string “1”.

Swift is currently an iOS & Mac only proprietary language. Unlike Objective-C, which has an open source compiler and runtime (used by Apportable) there’s not likely to be any way to use the code on Android or other platforms. However, most developers wanting a cross-platform approach are unlikely to have started with Objective-C anyway, so this is not really creating significant extra lock-in. It might just persuade some developers choosing a cross-platform tool to target iOS because it’s easier, to create a fully native app instead.

Why does it matter?

First, more developers. Although modern Objective-C has a lot of good points, it’s an evolution of a very old language. Syntactically it’s quite different from most other modern languages – it borrowed from Smalltalk while the rest of the world followed C/C++. This creates a barrier to entry for developers in other languages because the code initially looks alien. Additionally, any language that has pointers is a hard sell and steep learning curve for complete beginners. Swift fixes those things and should make developing for Apple products attractive to an even wider audience.

Second, more productive developers. Greater productivity means lower cost of development and/or shorter time to market. The combination of more rapid development and lower fragmentation versus Android should help to keep iOS as the first platform developers target, even as its market share continues to shrink through the faster growth of Android globally. This is very important if Apple intends to stay exclusively at the premium end of the market.

Last but not least, happy developers. Although several cynical commentators have latched onto the proprietary language lock-in angle, it seems rather unlikely that giving developers a new language to learn is going to lock them into developing for a platform when the barrier to exit is, well, learning a new language! Instead consider that Apple is primarily aiming to retain developers through loyalty rather than lock-in with this particular move. It should not be underestimated how much good tools can contribute to the enjoyment of daily development work. If Swift can deliver on its promises then other platforms will have to be that much more attractive to tempt the best developers away.