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

Benefits and Challenges of HTML5 App and Game Cross-Platform Development

HTML5 web app development had its ups and downs but it is undeniably one of the most promising technologies for the upcoming years. The best example can be found on desktop systems, where users are spending more time inside a browser than ever before.

HTML5

Hundreds of traditionally native apps are turning into web apps as they provide advantages like interoperability, ubiquity and cross-platform. The features added in the new HTML5 standard allow a much more dynamic web content and the development of applications never before imaginable on the web, such as videogames, one of the most performance and resource demanding type of app. But this cross-platform promise is still in the making and it is key for developers to understand the benefits and challenges before committing to a fully web based approach. In this web Vs native controversy it is important to remember that [tweetable]the adoption of a technology should always be driven by the needs of the project to be developed[/tweetable].

Benefits

In order to provide the most accurate view of the status of web based project development and make the right decision, let’ summarize the benefits of the web first to identify the opportunities it offers.

Cross-platform

This is the main feature why developers have originally turned into web technologies looking to fulfil the promise of coding once and deploy everywhere. As some of the other advantages of the web, cross-platform is in its nature, as it is meant to run on any device (hardware) and operating system (software). The web can be accessed from a PC, Mac, laptop, desktop, mobile device, smart watch, car and even home appliance. We know one thing for sure about any futuristic new device: it will be able to access the web.

Content on demand

Many developers do not identify this feature as a benefit because they take it for granted as, once again, is in the nature of the web. But [tweetable]being able to provide content on user demand is one of the biggest benefits the web puts on the table[/tweetable]. Applications can easily vary and adapt with none or little effort from the developer perspective and new paradigms and user cases can be easily accomplished, like promoting the use of an app or a new feature while communicating with others. The messaging app Kik is a great example of an application that is showing the benefits of on demand web applications as provides its users with the option to run apps and games without having to leave the messaging environment.

Full technology stack

This is a feature that goes hand in hand with cross-platform as its goal is to ease the process of building a product for developers. Web technologies can be used full stack, from client to server, thanks to platforms like Node.js. Many products need a desktop based UI/UX and their mobile versions could be developed using the same technologies and reusing plenty of the same code. Same thing happens in the server side as many data structures and even algorithms can be reused speeding up development cycles, lowering possible mistakes and bugs and increasing maintainability in the long run.

Based on open standards

This is more important than meets the eye. There have been various technologies in the past that made the cross-platform promise but did not completely deliver. Amongst other reasons, they failed because of being closed and tied to a specific company. Open standards allow both vendors and developers to contribute and improve the final product. This is one of the key success factors of the web. There is no head controlling it so it can evolve according to the needs and interests of many.

Supported by big companies

The web is supported by the biggest technology companies in the world like Google, Amazon, Microsoft, Facebook, Samsung or Apple. Most well known and used browsers are developed by some of these companies that also are part of the standardization committee. This support is a good example of why the web is here to stay and why it will continue gaining momentum as a development platform.

Big developer community

The web is also driven by its developer community, one of the biggest as it involves front-end and back-end developers that are always providing new tools and support. Mobile is the frontier to conquer but there is no doubt the web has won on desktop environments. There is no company, product or service that doesn’t have presence on the web both directly or indirectly. This whole ecosystem of applications is developed by a thriving community of developers that not only need to understand the backend side of the equation but also how browsers and client side technologies work.

WebGL

This feature might change the perception of the web for both apps and games. It provides access to high end graphics and to a more interactive web crossing the boundaries of 2D to enter the third dimension (and even improving the 2D experience with hardware accelerated graphics). All the big browsers support it out of the box now as the last two players, Internet Explorer and Safari, have finally committed themselves to promote it too.

The list of the benefits of the web could even be longer. After reading this set of features, the web could be the first (and maybe the only!) option when it comes to implement a project: be everywhere, anytime and with the the option of using the same technology full stack. But the truth is that web technologies are not widely used in many scenarios (specially when it comes to mobile).

Challenges

Let’s review the main challenges that developers need to overcome and some tips on how to do it.

Cross-platform is more than devices and operating systems

It also involves markets, stores, destination sites, … deployment targets in the end.[tweetable] The holy grail of code once and deploy everywhere comes at a price: handling the particularities of each deployment scenario[/tweetable] can be tricky. Developers need to create accounts, understand the packaging details on each platform, install and learn how to use the tools provided, etc. There are some solutions in the market based on cloud services to be able to configure and deploy a product to different targets with simple to use interfaces taking all these burdens out of developers shoulders. Some examples of this kind of services are Intel’s XDK, Adobe’s PhoneGap Build and Ludei’s CocoonJS.

Cross-platform does not really mean same code or user interface/user experience

It is important that developers understand that cross-platform does not mean the same exact app will mandatorily be the one that will end up going to the different markets. Mobile devices have some inherent particularities like the different input method (touch screens) and limited screen resolutions that must be taken into account. Also, users on mobile are used to different set of interaction paradigms especially when it comes to social media integration or access to native features. [tweetable]A good advice is to think on mobile first if mobile is key for the product[/tweetable]. Mobile device memory, performance and feature limitations should also be taken into account. Having good tools for rapid prototyping, testing and debugging is also key. Many HTML5 app development frameworks provide tools for what is called responsive design. However, this challenge is still less of a problem compared to developing an app in different technologies (web for the desktop, Objective-C for iOS, Java for Android, C# for Windows Phone, …).

Browser feature fragmentation

Yes, the web is an open standard and that is a benefit, but the adoption of these standards rely on browser vendors that have their own agendas, as they are private companies in the end. Standardization takes time too and it is important to take that into account if a feature is a must inside a project. This situation leads to an API and feature fragmentation that has hurt the web application development from the origin of the internet (remember Internet Explorer Vs Netscape “browser wars”). Use of prefixes, incomplete or different implementation of some of the APIs, promotion of non standard ways of handling certain situations are just some of the examples of this challenge developers have to face. Vendors are improving their old day practices and the auto update of the browsers has helped a lot in order to allow users to benefit from the latest additions in a daily manner. There are also initiatives to mitigate the negative side-effects of these practices like some open source libraries to ease the handling of supposedly standard features, e.g. Modernizr. Still, this might be a challenge for some developers. On mobile, this problem is magnified as mobile operating systems (specially Android) and browsing technologies are still in their infancy. Technologies like Ludei’s WebView+ or Intel’s Crosswalk help overcoming this problems as they offer a unified execution environment regardless the Android operating system version. One less headache for developers.

Low performance, especially on mobile

Execution speed has been one of the main problems holding HTML5 back as a widely used cross-platform app and game development technology. Mobile has been the platform where this problem has been more notorious as mobile devices have more limited processing power. As hardware has evolved, the performance gap between mobile devices and desktop computers is shrinking. Improvements on browsing technologies has also helped on solving this issue. Still, the biggest problem related to performance is, once again, due to fragmentation. To be able to develop a native web application, the system webview element is used. The issue with the webview is that it’s tied to the OS version, so that the user needs to update the OS for the webview to get new features and updates. Android fragmentation makes the webview a poor choice when it comes to deploying HTML5-native hybrid apps. But there are solutions to this problem. Once again, projects like Crosswalk and Ludei provide a huge improvement in order to solve the performance issue. Actually, Ludei provides multiple options (WebView+ and Canvas+) to help on this matter depending on the type of project (a general purpose app or a canvas based game). The bottom line is that there are solutions for the performance problem that prove that HTML5 can be a good execution environment for cross-platform apps and games.

Access to the native features on each platform

The web, as many other technologies before it, because of its cross-platform nature could be limited in its access to platform-specific features. This is a fact and in many cases, a limitation. Either way, the huge support that the web has over the whole technology community makes it a primary target for the adoption of new products and technologies. Good examples of this are devices like the Leap Motion controller or the Oculus Rift VR Head Mounted Display. Thanks to new APIs like websockets, these completely over the edge technologies are present from day one on the web. A similar situation arise on mobile with an increasing need to access hardware features and many of the interesting APIs only available in the OS/native level. The good news are that browsing technologies are rapidly adopting these important features. Moreover, thanks to hybrid approaches, there are JS to native bindings that allow accessing any native feature from a web app. Cordova is the de facto standard for building these bindings called plugins. Literally, there is no limit on what can be accessed: In-App Payment APIs, Push Notifications, Advertisement SDKs, Social Network SDKs, and a long etcetera.

[tweetable]The benefits of HTML5 and the web are undeniable; the web is here to stay[/tweetable]. The devices of the future might support software languages like C, Java, Swift or a new language we’ve yet to see – but the common denominator will always be the web, a technology that has brought us together and has enabled a much richer communication and access to information. The true strength of the web and HTML5, its most recent standard, lies in its ubiquitousness and its flexibility. HTML5 has advantages and limitations, and knowing how to leverage the former and overcome the latter is what sets apart good from bad engineering teams. It’s just a matter of choosing the right tool for the right job.

Categories
Platforms

Smartphone Market Share And Usage By Country – Apr-May 2014

Worldwide Smartphone Usage Share

My argument was that market share patterns by country could give us a better understanding of these trends. While market share of shipments is certainly a leading indicator for install base (and consequently, usage), it only gives us a part of the story. Contrasting regional market share and usage share (as a proxy for install base) may give us an even better understanding.

As always, I’ve sourced the figures for shipment market share from Kantar while usage share figures are from Statcounter. Usage share (or browsing share) isn’t an ideal proxy for install base as it could be skewed towards higher end devices. However, the trends in usage share could give us a fairly good understanding of the underlying install base. For example, the chart above shows that Android’s usage share has been growing while that for the iPhone has declined slightly. This should be expected as Android’s shipments and install base have been growing much faster than those for the iPhone.

Now, let’s take a look at the trends in each region:

Mature Markets: US, Australia, Japan and Europe

US: Android Gains on iPhone after Unsubsidized Plans Take Hold

US Smartphone Market Share

US Smartphone Usage Share

The market share chart shows that AT&T’s foray into unsubsidized smartphone plans in late-2013 had a measurable impact on the iPhone. As a result, the iPhone has seen steep YoY market share declines. We can see this pattern in the usage share chart as well. Android and iPhone usage patterns were diverging until late-2013, when they began to converge again. Meanwhile, both charts show that Windows Phone has been unable to penetrate the US market.

Australia: Android Usage Grows

Australia Smartphone Market Share

Australia Smartphone Usage Share

Android has held the market share lead in a fairly cyclical market for a few years now. Over this period, it has made steady gains in usage share. Windows Phone’s market share has been hovering around 5-7% for a year now, but it has barely made a dent on usage. This could mean that Windows Phone devices are being used as feature phone replacements.

Japan: iPhone Extends Lead

Japan Smartphone Market Share

Japan Smartphone Usage Share

As I’ve explained before, Japan is one of the only remaining markets in the world that follows a purely opaque pricing structure for smartphones. This pricing model, combined with a distribution partnership with NTT DoCoMo, gave the iPhone a huge market share boost. As we can see, this has had a major impact on iPhone usage as well.

UK: Android Makes Steady Gains

UK Smartphone Market Share

UK Smartphone Usage Share

As I’ve explained before, market share patterns in the UK seem to be stabilizing with lower cyclicality. Usage share patterns have remained stable as well, with Android gradually catching up with the iPhone. Interestingly, Blackberry owned a significant share of usage even after 2012 but Android gradually ate into its base. Windows Phone remains a bit player, but at least its usage share doesn’t scream “feature phone replacement”.

Germany: Android Dominates

Germany Smartphone Market Share

Germany Smartphone Usage Share

Android’s market share in Germany has grown steadily over the past few years. As a result, its usage share overtook that of the iPhone in mid-2012 and now holds a dominant position. This had a significant impact on the iPhone’s performance. Windows Phone’s market share has hovered at around 7%, but it has struggled to make an impact on usage.

France: Android Leads Shipments, Overtakes iPhone in Usage Share

France Smartphone Market Share

France Smartphone Usage Share

Android’s market share has remained stable over the past year, while the iPhone has remained cyclical. Android’s shipment supremacy has led to a direct impact on the install base which caused Android’s usage to overtake the iPhone’s earlier this year. Meanwhile, Windows Phone’s market share seems to have had a meaningful impact on usage.

Italy: Android Leads, Windows Phone Tails Off

Italy Smartphone Market Share

Italy Smartphone Usage Share

As in Germany, Android has made steady gains to become the leading platform in both market share and usage. The iPhone has seen steep declines on both metrics as was also challenged by Windows Phone. However, Windows Phone shipments, and consequently usage, have tailed off over the past few months.

Spain: Android Becomes the Default Platform

Spain Smartphone Market Share

Spain Smartphone Usage Share

This one seems self-explanatory.

Emerging Markets: China and Latin America

China: Android and iPhone Remain Steady

China Smartphone Market Share

China Smartphone Usage Share

Market share patterns in China have stabilized as the market seems to have moved out of hyper growth. Over this period, Android and the iPhone have feasted on legacy platforms like Symbian. As the market matures, we may see more direct competition between these two platforms. Interestingly, the iPhone’s partnership with China Mobile seems to have had no impact on these patterns.

Mexico: Android Replaces Blackberry

Mexico Smartphone Market Share

Mexico Smartphone Usage Share

Mexico is the only market on this list where Blackberry held a market share lead at some point in the last two years. However, this market share lead did not translate into usage which suggests that they were primarily used as feature phones.

Over the past couple of years, Android has taken a dominant position in market share and usage. The iPhone’s share of usage has declined over time, but still seems out-sized compared to its market share. Finally, Windows Phone seems to have a measurable, but not significant, presence on both metrics.

Brazil: Android in the Lead

Brazil Smartphone Market Share

Brazil Smartphone Usage Share

As in Mexico, Android holds a dominating position in both market share and usage while iPhone usage remains far higher than its market share. Windows Phone has a small presence, but it seems muted compared to other Latin American countries.

Argentina: Android Leaves Other Platforms Behind

Argentina Smartphone Market Share

Argentina Smartphone Usage Share

Android’s performance in Argentina seems to be dominant enough to create an oddly stable usage share pattern. Windows Phone is the second leading platform on both metrics, but remains far behind the leader.

Categories
APIs

Permissions in Mobile Ad SDKs

If you’ve ever tried to integrate a mobile ad SDK into your application, then you’ve definitely had to declare a few permission for it to work. Permissions in mobile platforms such as Android and iOS have been baked in from day one as a mean to control what applications could do or access on your phone, preventing despicable people getting access to your most personal and sensitive data. In this article, we will review what permissions are required to integrate 10 of the most popular mobile ad SDKs out there.

de-illustration-cropped

For the sake of clarity and consistency, we will use the Android SDK permissions. Since most of these mobile ad networks mirror their Android and iOS SDKs this is an acceptable simplification, so without further ado, let’s jump right in.

table_permissions-1024x767

The Internet Permission

This is a no-brainer really. If any ad SDK is going to be able to serve real-time ads, then it has to be able to communicate with an adserver over the internet. It’s no surprise then that all 10/10 SDKs require this permission.

The Network State Permission

Accessing the network state simply means identifying if the device is connected to the internet. If the answer to this question is yes, then this permission can also be used to identify if the connection is through a WiFi or a Cellular connection. This is the second most common permission across our sample with 7/10 SDKs requiring this permission and another 2 listing it as optional.

Access WiFi State Permissions

Using this permission is another way to check if a user is connected to WiFi or not but is clearly not the most popular method as only 2 SDK mark this as required with another 3 making it optional.

Read Phone State Permission

A less popular permission as only 3 SDKs require this but nevertheless all three make this a requirement.

Access Coarse/Fine Location Permissions

This is a very important set of permissions. Traditionally location has played a key role in advertising but has an especially increasing importance in digital mobile advertising. It comes then as no surprise that 7/10 SDKs are interested in this permission. There is a clear trend here that these permissions are mainly optional permissions because they can be considered as more “intrusive” by users so developers tend to avoid them if not using them already. On the other side, including location info with an ad request can usually boost potential by a great deal so this situation can present a great dilemma.

Other Permissions

While the permissions mentioned above are the most popular ones, you may encounter some less frequent ones like write to external storage or even record audio. Throughout the 10 SDKs mentioned in this article, we measure 12 distinct permissions which is not a very big number considering that the Android OS has more than 100 available to declare.

Most SDKs that we have reviewed for this article have very reasonable permission requirements. Ultimately, it’s up to the app developers to find the sweet spot on what they will allow these SDKs to collect and if they are willing to introduce new permissions in their apps just for this. On the other hand, by doing so, app developers can realise a substantial boost in earnings due to more targeted and relevant ads, which can be a great thing for the end-users as well!

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
Tools

How to choose a good mobile ad network

You probably have already tried a handful of mobile ad networks, spending the good part of a day every time to integrate them and have experienced so far both feelings of disappointment and satisfaction. If it helps, you are not the only one.

shutterstock_113952028

The road to building a successful app business is not an easy one and you have to constantly experiment with new ad networks and technologies to find the one that best matches your app’s unique needs.

It doesn’t have to be a painful experience though and here are 5 different angles to look at a mobile ad network before you decide to invest your time and give it a try.

Angle #1 – Fill Rate

MobileGoogleAnalytics

A quick look at your mobile analytics provider will show the countries or regions the majority of your users are coming from.

Geography: If most of your users are coming from North America, for example, you should actively search for mobile ad networks that have a high fill rate in this region otherwise you will not be making money at your full potential.

Consistency: This is slightly tricky to evaluate beforehand, but aim for a monetization partner that in the last 3 months had consistently high fill rates in the regions you are most interested.

Many in-app advertising solutions have developed mediation technologies and partnerships with ad exchanges to combat these issues and while touting near 100% global fill rate, make sure you evaluate on hard numbers and not just marketing talk.

Angle #2 – eCPM

Choosing a mobile ad network based only on its average eCPM has a caveat because eCPM measures performance on a relative basis. Only when combined with the fill rate and your estimated monthly ad requests you can get a good sense of your expected earnings in absolute terms.

Have in mind that there are many factors that will cause significant fluctuations on eCPM, including the seasonality of advertising campaigns and the quality of traffic you send from your apps. You should anticipate fluctuations, especially if you are working with a single mobile ad network, and use the network’s average eCPM to get an “order-of-magnitude” feeling on what to expect.

Angle #3 – User Experience

AvocarrotScreenshot

People who download a free app are well-aware that it has to be funded somehow and they expect that the app might include a form of advertising.

App developers, however, have a choice whether they want to deliver a spammy user experience or interrupt the normal user flow to display ads and by choosing to do so they consciously take the risk that user retention can fall dramatically.

If quality user experience is important to your app, some mobile ad networks are more flexible than others and have started embracing native advertising technologies to offer developers more control on how and where ads get displayed.

Angle #4 – Technology

You can also evaluate a mobile ad network based on its technology.

SDK: A lightweight SDK that has been battle-tested enough will ensure your app’s performance will not be impaired at any time.

Dashboard: A fully-featured dashboard can enable thorough monitoring and effortless fine tuning which helps in both maximizing your revenues and increasing transparency.

Ad Server: This component is the most difficult to evaluate but among others, low-latency infrastructure and yield optimization algorithms are the backbone for a good eCPM, so you can use that as a proxy.

Angle #5 – Payment Options

We’ve covered previously the different payment options offered by major mobile ad networks and is important to be familiar with them well in advance in order to avoid unpleasant surprises.

Payment methods: Mobile ad networks often support a limited number of payment methods and you have to make sure your individual circumstances can be covered before you start integration.

Payment schedule: This is usually not a deal breaker, but some networks offer a faster payment schedule than others.

Sum Up

Experimenting with various solutions to find the ones that best match your needs is critical for a successful app monetization strategy but due to the sheer volume of mobile ad networks out there it can get quickly overwhelming.

Avocarrot have explored here 5 different dimensions that can hopefully help you get a well-rounded picture of any mobile ad network you come across and quickly decide whether or not you will invest some of your time to give it a try.

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.

Categories
Platforms

Confessions of a BlackBerry developer

The BlackBerry developer initiative

It’s been almost 2 years since the first beta release of the BlackBerry 10 SDK. Back then, RIM decided to launch the “happy developer” initiative, which was comprised of two parts. The first was targeted at some of the largest software houses and the second, at the long tail of developers. The first part was successful, since most of the big software houses are now supporting BlackBerry10 either by building native apps or by porting their existing Android apps into BlackBerry World.

confession-of-blackberry-developer

The second part of the initiative, which was aimed at indie developers and hobbyists, is a different story. It seems to me that BlackBerry tried their best, shipping beta devices all over the world, getting the developer relations team on the road, in order to help developers face-to-face, giving incentives like the 10k$ commitment (money that was delivered every month, just as promised), and, most importantly, engaging with all developer communities or individuals from around the world 24/7.

The need for change

BlackBerry went through some difficult times during the past 2-3 years. The company seemed to be unable to get it right, and the negative media attention wasn’t helping. The BlackBerry 10 launch was not as successful as the company would have liked.. The legacy BlackBerry devices were outselling BlackBerry 10 devices quarter after quarter,..
A change was sorely needed in the company’s direction and plans. Cue John Chen. Once Chen was named CEO he brought a whole new set of ideas to BlackBerry, and a new plan of action.
Success comes after a company becomes viable and profitable at the same time. Under the new leadership, BlackBerry started adhering to timetables and deadlines and showing all signs of following a specific plan.

There’s just one thing that did not change, and that’s their commitment to developers. Yes, they are shorter on staff (the developer relations team was merged into another team under Martyn Mallick), the VP of Developer Relations, Alec Saunders, is now in charge of QNX cloud, aka Project ION. But the tools are still getting updates, and the roadmap, which is more important in my opinion, is active, showing that there is a plan for the BlackBerry 10 platform. BB 10.3 is now just around the corner new devices are on the way, and the future looks a little brighter for a company that went through hard times but now looks ready for a comeback!

dev_optimism_chart

There’s also been a change in the central message that BlackBerry is attempting to communicate to developers. When BlackBerry 10 was first introduced, this message was “Flow-Connect-Extend”. It was all about the core basics of the new platform.

For the 10.2 update the message was changed to “Adapt-Sense-Understand”. BlackBerry had more features available for developers, such as headless mode (i.e. apps running in the background), and use of geolocation in apps. Now this message has changed once again, and it’s all about the Internet of Things (project ION). We still don’t know too many details, but it has to do with big data in a secure environment (QNX cloud) that can be used by developers to create a whole new breed of apps.

The decision

Back to reality. As a developer targeting BlackBerry 10 myself, I realize that publishing an app is a twofold process.
The first step is developing the app. BlackBerry offers a completely risk-free environment, with fully engaged support and tool options. During the past couple of years, the SDK has been updated many times, each cycle an improvement over the previous one.

The second part is what comes after publishing the app. This is where success/time spent in part 1, takes place. Success means different things to different people. It might be measured in terms of money earned, number of downloads or even a high rating for their app in the BlackBerry World app store. The truth is that developers don’t have many tools at their disposal to reach their goal, whatever that may be, and BlackBerry’s current status in the top markets is not helping improve this situation..

But what about the countries and regions in which BlackBerry is still a best-selling handset manufacturer, such as Indonesia, South Africa, Nigeria and the Middle East? It might not be as easy as it sounds to target specific markets. Let’s take a look at the distribution of downloads and revenues around the globe (I’m using my own app as an example).

Downloads-2014-05-19
Downloads vs. Revenue maps of a freemium app with more than 125k downloads (May 2013 – May 2014)

Revenue-2014-05-19

It’s clear that BlackBerry has to improve its standing in major markets. Many think the main reason for low device sales in key countries is the lack of apps – but maybe it’s actually the other way around. Perhaps we have a formula that looks something like this: device sales -> more users -> more profit for developers -> more developers -> more apps
At the end of the day, engaging with BlackBerry is going to be a personal decision. There are some important parameters still missing from the BlackBerry platform, which might be keeping many developers from migrating to, or at least adopting, BB 10. A lot of these parameters, however, are not strictly related to actual development, i.e. coding.

But developers should keep two important factors in mind: BlackBerry 10 is still one of the newest OSs out there, which means there’s a lot of room for growth. Also – BlackBerry still is, and will continue to be, a leader in enterprise solutions, which is translated as a strong brand name. This combination indicates that there’s potential for BB10.

If I were to give developers some advice on whether to adopt the platform, I would say go for it. Built it or bring it – i.e. either go native or bring over your Android app. The tables may turn sooner than you think.

Categories
Languages

Is HTML5 about to make a comeback?

The web is losing and apps are winning. At least that’s what the most recent data from Flurry says – 86% of time on mobile devices is spent in an app other than the browser, up from 80% last year. Does that really mean the web is losing? What about apps built with HTML5? Is the implementation technology more important than the distribution mechanism? Why should anyone care? A number of new tools and frameworks are maturing that should make it much easier to build great mobile sites and apps with HTML5. Could they stop the shift from web to native apps, or even reverse it?

is-html5-about-to-make-a-comeback-650px

Why the web is losing on mobile

Modern web browsers and standards were designed for a desktop computing environment and they built upon a base that was designed for sharing linked documents. Mobile computing environments have capabilities and constraints that desktops don’t. Native mobile app platforms were designed for building highly interactive, animated, apps utilising hardware graphics acceleration. The result is that apps running in a mobile browser are disadvantaged in terms of performance, user experience and access to device functionality versus their native counterparts.

The app is the new browser bookmark. People have favourite services and sources of information or entertainment even though a great deal of substitution is possible in most cases. Providers have to compete on user experience and that creates a bias towards native apps. You want to check the weather every day? You don’t search for a weather forecast every time, or find a favourite weather site and bookmark it, you download a weather app. Need to catch up with your friends on a social network? You don’t open the browser, type a URL or go to a bookmark and wait for the latest updates to download, you get update notifications pushed to you by the native social network app, or when you open the app it has already downloaded the latest content in the background. For frequently accessed apps, the native versions have much less friction, as well as a nicer user experience.

What about hybrid apps?

Delivering a web app in a native wrapper allows it to access device functionality and reduce some regular usage friction. However, it doesn’t fix performance (indeed on iOS it makes it worse), nor make it easier to deliver a great user experience. Another problem with delivering a packaged web app that uses a system WebView is that the functionality of the WebView itself can change with OS updates. Android recently switched to a new Chromium-based WebView and broke or crippled lots of hybrid apps. The flip-side to this problem is that WebViews upgrade slower than browsers; on Android the WebView is currently tied to OS upgrades (which are still lacking from most manufacturers) while the Chrome browser continuously auto-updates. This means it’s a long time before it’s feasible to start using new standards added to the browser specifically to tackle mobile issues. A hybrid app is also still subject to app store reviews and policies. It may be possible to update functionality without an app update in the store but the platform owner still controls what developers can and can’t do.

Another popular complaint about hybrid (and native) apps is the loss of ability to cross-link versus the web. I believe that Facebook’s recent App Links project puts all native apps (including hybrids) about on a par with web apps here. It may be possible to link to any web page but many modern web apps only have a single page. What’s actually needed with a web app rather than a web site is the ability to link to app states. This is only possible if the developer enables it by setting up routing for URLs to app states – native apps can already do this and App Links solves the “what if the app isn’t installed” problem with web fallbacks or store links. If platform providers enhance app interoperability then native (and hybrid) apps could significantly exceed the capabilities of the web here.

Engagement versus ease of access

As discussed above, any content or services you access frequently create less friction by providing native apps. Less friction enables more engagement and a virtuous cycle of greater usage. On the other hand, new or infrequently accessed content and services have extremely high friction if you need to download an app before you can do anything else. Here the web has significant advantages over native apps. The companies who really don’t get this are the ones that have a full screen popup asking you to download their app every time you visit their website on a compatible device! Another way to look at the Flurry stats linked at the top of the article is this: exclude games (which have almost always been native for performance) and social networking (which falls firmly into the frequent access category, plus a lot of the time will be using an in-app browser anyway) and the browser still has more than a third of the remaining mobile usage time. That doesn’t sound quite so bad.

New frameworks fill the gaps

With the threat of being relegated to the “infrequently accessed” category of apps, the web development community has not been sitting around doing nothing. A new framework recently into public beta, famo.us, attempts to solve the major performance problem for animated web app UIs. Their current approach is a series of clever hacks involving minimal manipulation of a very flat DOM structure. However their JavaScript APIs will also render to WebGL in future (when it’s sufficiently widely available, ahem, Apple). The approach is promising and the demos are impressive. Currently their homepage (on both my retina iPad Mini and Nexus 4) kinetic scrolls with a stutter that makes my 2006 Symbian device look slick, so there’s a way to go before they’re ready to come out of beta. Note that using Famo.us JavaScript APIs starts to make building web apps look more like creating a native app.

Another framework close to its 1.0 release is Meteor, a new way to create real-time web apps very rapidly. They fix common issues with the responsiveness of web apps out of the box – having to poll the server for new data and wait for it to update the UI after user interaction. The latter is achieved with a technique called latency compensation (UI is updated with local data immediately, then fixed if the server returns something different). The former is down to having long-running bi-directional connections between client and server rather than a more traditional RESTful API. Meteor actually supports native client apps too but with the ease of creating the web front end it would be unusual for developers not to have both web and native options if they go down that route.

Although there are lots of new and interesting frameworks in development I’ll highlight just one more that’s in a fairly mature beta stage. Ionic is a framework designed specifically for building hybrid apps. It’s built for performance and to provide common UI components and interactions out of the box so it’s easy to make an app with a native feeling user experience. The default styling is very similar to, although deliberately not exactly like, iOS 7. The major disadvantage to this approach is that while it works on recent iOS and Android versions you lose the broader cross-platform and device compatibility. It’s not for building mobile websites or desktop web apps. As such Ionic is building on HTML5 purely as an implementation technology and abandoning the browser. However, as it’s still running in a WebView developers retain the privileged position of being allowed to download new code on iOS.

Native user experience

I listed performance and user experience as two separate issues for a good reason. Despite all the great efforts at resolving performance issues for web apps, native user experience is not just about performance. For some apps it’s natural to take over the full screen and provide an immersive user experience. Games fall into this category, unfortunately they’re also the category of app most in need of full native performance. The majority on non-game apps use some standard platform components and need to follow platform user experience conventions. This makes it easy for users to learn how a new app works; navigation and controls work in the same way as most of their other apps. In this sense when we say “native” user experience we mean aligned with the platform culture and conventions rather than compiled to native binary code. The folks at Ionic are right not to mimic iOS 7 too closely. The more native looking an app’s UI, the more users will expect it to behave exactly like one (and get frustrated when it doesn’t always). A phenomenal amount of effort is required to make an app look and feel just like a native one when it’s not actually using native controls. Even if this can be achieved, the platform will change and the app won’t, making it stand out like a sore thumb until it can be updated (again at significant effort). This is an issue for all cross-platform environments that have their own rendering engine rather than wrapping native controls.

What the technology wants

Marc Andreessen famously said that the eventual application model on mobile will be the web application model, because the technology wants it to work that way. Having every app stored on a remote server and the latest version always updated to the device when it becomes available is a superior model to downloading and periodically updating local apps. This technological advantage applies almost equally to hybrid apps, assuming the native wrapper rarely needs changing. Native apps that automatically update is a step in the right direction but doesn’t aid lean development practices like split testing and continuous deployment. The latter are so valuable in figuring out what to build quickly that there are plenty of entrepreneurs and businesses out there who would build mobile apps with the web model if they were good enough for their customers.

The next wave?

Consumer apps that don’t have highly desirable unique content or features are going to have to compete on user experience for the foreseeable future. For most that will mean native apps. However, building native apps is significantly more expensive than building cross-platform web apps. Not all of the people who pay for apps are going to prioritise user experience. The next generation of software for large enterprises right down to small businesses is going to need a much better user experience than the last but the current state of web technology is probably good enough.

Revenues from consumer mobile software may look quite attractive but the bulk is in Free-to-Play games and is highly concentrated amongst a handful of publishers. The majority of the growth in that market is in Asia. A more interesting opportunity for many developers may be the only slightly smaller but faster growing Software-as-a-Service (SaaS) market for businesses. As mobile devices become increasingly essential in our work lives as well as our personal lives, maybe we’ll see more of that total usage time in business and productivity apps.

Conclusion

So, is HTML5 about to make a comeback? In a way. If the first wave of mobile computing adoption was primarily about consumers, the next wave will see many more businesses getting serious about using mobile devices to enhance productivity and collaboration. I suspect the use of HTML5 in business apps to be much more successful than in the consumer space. Possibly we’ll see a return to the browser but for now the hybrid app looks more likely. General purpose business apps like time and resource tracking or project management will have large enough user bases to justify native client apps, although of course they’ll need web access too. The more specialised the app, the more likely it is to be a hybrid app than a fully native one.

Categories
Platforms

Which top platforms are easiest to develop for?

In the mobile software world, developers are considered vital to the health of platforms, of which they have several to choose from. Platform owners have to work very hard to make sure their SDKs and tools are easy to use. Too much friction, too little documentation or too steep a learning curve can drive developers away. Which platforms are the easiest to develop for? More importantly, does ease of development translate into popularity? Or is it just a hygiene factor?

platform

A lesson from history

Mobile platforms have not always tried to make things easier for developers. Before the iPhone, Symbian dominated the smartphone market and had a policy of making developers jump through hoops to ensure both the resource efficiency of apps and the security of the platform. Nokia tried to add a developer friendly layer on top of the OS with Qt but it was too little too late to capture developer attention, even with an existing large installed base. So, a terrible developer experience can ruin a platform’s chances but does greater ease of development lead to success?

Interpret with caution

In our last developer economics survey we asked developers how easy it was to use a common set of APIs on their primary platform. Before diving into the data, there are some caveats:

  1. Comparison between platforms is slightly unfair because the API categories are broad and not all platforms will enable access to the same level of functionality
  2. Not all developers target multiple platforms, so some do not have a good basis for determining ease of use (although purely subjective ratings are still valid for comparison)
  3. The APIs that were included in the survey primarily focus on native functionality, so this comparison in somewhat unfair on HTML5
  4. The APIs do not include UI functionality and building the UI is a significant part of the work in most mobile apps.

Bearing those points in mind, below is what developers think of their platforms.

Easy != Popular

Our data shows that the challenger platforms, BlackBerry 10 and Windows Phone are the easiest to develop for, with BlackBerry 10 having a slight lead. In the middle are the leading platforms, iOS and Android, with iOS fractionally easier to develop for overall but with Android having several APIs where it leads.

In a distant last place we have HTML5, suggesting that it’s still very difficult to build apps that take advantage of uniquely mobile features with web technologies. In this regard it’s interesting that the recently appointed CTO of Mozilla, Andreas Gal has this to say:

“For Mozilla, anything that the Web can’t do, or anything that the Web is not faster and better at than native technologies, is a bug. We should file it in our Bugzilla system, so we can start writing a patch to fix it.”

There appear to be a few more entries for their Bugzilla system above. Web technology has matured a long way and makes it very easy to develop web sites across a wide range of screens – mobile apps are not the same thing and pose a different set of challenges.

To answer the question we posed at the beginning, it seems that ease of development is mostly a hygiene factor. The top platforms are not the easiest to develop for. BlackBerry 10 seems to have surprisingly high levels of continuing loyalty amongst developers despite the very poor sales for the platform to date, so perhaps there is some value in creating an environment developers really love to work with rather than one that is simply not painfully difficult.

The next frontier?

As we move towards a world of connected sensors everywhere and wearable devices are being hyped as the next big thing, an interesting sidenote is that Bluetooth was rated as the hardest API to use by developers across all platforms. After years of failing to reach its potential, Bluetooth is emerging as one of the key technologies enabling smartphones to talk to wearables and other external devices without sufficient power to maintain their own permanent internet connection. Perhaps this is an area for all platforms to consider revisiting, or an opportunity for an Internet of Things platform provider to abstract away the details.