Month: November 2013

Categories
Languages

How to succeed with HTML5

Although the debate on HTML5 versus native apps seems to be favouring native apps currently, particularly in terms of user experience and performance, average developer revenues tell a very different story. Our survey data shows the mean average revenue for developers who consider HTML5 for mobile devices their primary platform is the highest of all platforms, just over twice that of the next nearest (iOS)*. However, the rewards are very unevenly shared, with the median average revenue for the same developers under half that of their iOS counterparts. Diving into the data we can see significant differences in revenue depending on how mobile apps built with web technologies are delivered to users and the categories they target. Understanding these differences could improve your chances of succeeding with HTML5.

html5

Apps but not App Store sales

The majority of developers using HTML5 in their businesses still prefer to deliver it via the browser, either as traditional websites, or more complex web apps. The range of deployment options for developers using web technology and their relative popularity is shown in the chart below. The data throughout this post is filtered to only include developers whose organisations earn between $1 per month and $5 million per month. There are a large number of hobbyists with no revenue who are excluded and we also exclude a small percentage of super-high earners who create large distortions in the averages.

It turns out this browser-centric preference, despite the protests of the open web advocates, is bad for business – at least in the short term. On average (mean and median) [tweetable]developers deploying their code as standalone apps earn 50% more than those delivering via the browser[/tweetable]. If we exclude apps for platform native web frameworks (e.g. Firefox OS and BlackBerry WebWorks) because these are only available on niche platforms, then the advantage rises to 70% (mean, or 100% median). If we also only look at those developers who consider HTML5 their primary platform then the difference is larger still (mean revenue per person per month of ~$77.5k for app delivery versus $21.5k for browser delivery).

A popular misconception is that the web has poor monetisation and app stores solved this. However, as we’ve shown previously, [tweetable]the more developers rely on app stores for revenue, the less they make[/tweetable]. Web developers are no exception, in fact, avoiding reliance on app store monetisation is one of the keys to their success. Amongst developers using HTML5 for mobile devices as their primary platform who gave us a revenue breakdown, 65% had no revenue at all from app stores and of those that did, a further 65% generated less than 50% of their revenue from app stores. Contrast this with those targeting iOS as their primary platform – 67% of them generate some of their revenue from app stores and for 50% of those it was more than 50% of their total. So where do these web developers make their money? A much wider range of sources – more contract work than most platforms, many more sales outside of app stores and also e-commerce.

The right tool for the job

It’s also clear that HTML5 is not suited for all types of app and while in the case of enterprise clients it seems browser based delivery is still slightly preferred, an app delivery method opens up many more opportunities. The interactive graph below compares revenues by category for browser and app based delivery methods.

Outside the Enterprise software and Maps & Navigation categories, the revenues are at least an order of magnitude higher for app based delivery in this subset of popular categories. The outsized revenues earned by business productivity software developers suggest that the consumerization of IT is making significant inroads into the enterprise and even the comfortable revenues of those who focus on (mobile) browser based delivery for enterprise clients may not last.

Although we shouldn’t underestimate the impact that the relative maturity of many web businesses versus native mobile competitors has on the above figures, web technology seems very far from dead as a way to capture value in the mobile software market. Our data does suggest that those who want thrive in the age of mobile should embrace the consumer preference for apps rather than rely purely on the browser to deliver their services.

– Mark

A brief note on the figures presented in the article:

* Calculated as a mean revenue per person involved in app development and excluding organisations with $0 revenue per month or more than $5 million revenue per month. This is attempting to narrow our inquiry to real app businesses rather than hobbyist developers whilst excluding a small number of outliers that distort the averages. As such this is not comparable with our published reports based on market size estimates for all developers, including hobbyists, students etc. Average revenues on iOS are still the highest if we include all developers.

Categories
Business

Are you using the right app revenue model?

The most popular revenue models appear to be those that are easiest to implement. The developers using them tend to have lower revenues. This may be due to greater competition or it might just be a result of less sophisticated app businesses producing less valuable apps. There are some interesting differences between platforms but [tweetable]subscriptions appear to be a relatively untapped gold mine everywhere[/tweetable], although maybe not for everyone.

VMMoneyNote2_800

Revenue models versus average revenues

Our research shows some significant variation in average developer revenues depending upon the revenue models being employed. An investigation of the relative popularity of revenue models versus revenue generated across the major platforms produces some useful input for app development strategy and planning. Unsurprisingly, the simplest revenue models to implement, like paid downloads and in-app advertising, tend to be the most popular. The often repeated stereotype that “Android users don’t pay for apps” also leads to a strong preference for ad-supported apps on Android, while iOS developers prefer paid downloads. Slightly more surprising is that although Android has a larger user base who seem less inclined to pay up front for their apps, freemium and other in-app purchase schemes are less popular than on iOS. It would seem that on average [tweetable]iOS developers are more sophisticated in their approach to the app business[/tweetable].

Revenue distribution

When considering revenues it’s important to note that the distribution of revenues in the app business is highly concentrated at the top and there are a lot of hobbyists who earn nothing. We exclude most hobbyists, those who’ve not started earning revenue yet, the mega-rich chart toppers and large publishers from our analysis by only counting developers with between $1 per month and $5 million per month in revenues here. Even so, there is a fairly large “middle class” of smaller independent developers with a lot of users and high revenues. As such there’s a massive difference between mean and median revenues even in this subset.

The revenues shown in the chart above don’t necessarily all come from the platform or revenue model they are linked to – [tweetable]developers use multiple revenue models and multiple platforms[/tweetable]. For example, amongst developers who target iOS first the in-app advertising model appears to do much better than for those who target Android. Although iOS advertising rates are higher, this isn’t the primary cause, since very few of our iOS respondents derived most of their revenue from ads. The actual reason is that many of those using ads also used a freemium upgrade model (presumably paying to remove the ads and possibly add features) and derived a significant fraction of their revenue from that also. The same strategy does not appear to work as well on Android. Although not entirely accurate, we’ll refer to revenues by platform and revenue model as a shorthand in the rest of this post because it’s a reasonable approximation in most cases.

Less popular, more people, more revenue

Interpretation caveats aside, one thing that seems clear from this data is: [tweetable]the more popular the revenue model, the less successful the developers using it[/tweetable]. The exception here is contract work, which shows much higher revenues on iOS and lower on Android relative to its popularity. Although there’s some evidence that contract development rates for iOS are slightly higher, the difference is mostly due to where the platforms are most popular with developers. Otherwise, most revenue models show slightly higher mean revenues on Android but significantly lower median revenues. There’s also a link between the average number of people involved in app development in an organisation and the revenue model. More people involved, may signal more complex development for the associated apps. The fact that this is also associated with increased revenue is possibly related to using the extra development complexity (or team size) on a more sophisticated revenue model. It is not the case that more people involved results in higher average revenues per person in general. In fact, there is a very strong peak in mean revenue per person for organisations with 6-10 people involved in development – there are probably some significant efficiency losses above this size.

The subscriptions gold mine

Across both Android and iOS, [tweetable]subscriptions generate by far the highest mean revenues[/tweetable]. Median revenues for subscriptions are also higher than every revenue model except contract development. At the same time, only just over 10% of developers use a subscription model and the average number of people involved is lower than for all but the simplest revenue models. Mean monthly subscription revenues for Android-first developers are 3 times higher than for their iOS-first counterparts. It seems that Android users not paying doesn’t apply to subscriptions. However, median monthly subscription revenues on Android are less than half those on iOS, so there are a smaller number of very big winners with Android-first subscription businesses.

Should more developers be trying to build subscription-based businesses? Almost certainly yes, but they’re not for everyone. While 53% of developers using the paid download model and 45% of those using in-app advertising are in 1-person companies, that’s only the case for 20% of subscription businesses. In fact 53% of the subscription businesses in our survey had more than 5 people, not all of which are directly involved in app development. This is because many popular subscriptions include continuously updated content and there’s significantly more work (and cost) involved in providing ongoing content for subscribers. Our survey has also shown that money is not a primary motivator for lots of developers and managing the content side of the business may not be something they’d want to be involved with. For entrepreneurs looking to build successful app businesses, the subscription model is definitely worthy of further investigation.

– Mark

Categories
Tools

Pros and Cons of the Top 5 Cross-Platform Tools

As the market temperature for cross-platform tools (CPTs) continues its steep climb into hotter territory, it’s understandable why many feel we are witnessing a mobile fragmentation that is perhaps much larger and more significant than the recent wars waged over the desktop. If this fragmentation tells us anything, it’s that [tweetable]cross-platform tools for mobile development are often not a “one-size-fits-all” solution[/tweetable] – and that there are numerous veteran users of these tools that do not believe the problem has been solved as well as it could be….yet. In our Developer Economics Q1 2013 report, the breakdown of the top CPTs looks like this:

18-01

How many of these tools do you know? Test your skills in the new Developer Economics Survey and win awesome prizes.

As you’d expect, each approach comes with trade-offs. Let’s examine the top five cross-platform tools (PhoneGap, Appcelerator, Adobe AIR, Sencha, Qt), as identified in our research, and list out the more salient pros and cons of each. This is not an exhaustive list, of course, as each platform can’t be explored in depth in one post alone. Want toexplore more cross-platform tools we’ve identified? Check out the CPT section on our ToolFinder tool atlas

Apache Cordova/PhoneGap

Apache Cordova (known by many as “PhoneGap“) holds the top slot in developer mindshare. Cordova/PhoneGap developers write their mobile applications using HTML, JavaScript and CSS. These assets run in a “WebView” inside a native application container on the target platform. It is, conceptually, a web application packaged within a native application container where your JavaScript has access to device-level APIs that normal web applications would not (more on that below).

The name “PhoneGap” is quite possibly one of the more recognizable names in this space. Originally created by Nitobi, the name was changed to “Apache Cordova” when it was donated to the Apache Software Foundation. Adobe purchased Nitobi – including rights to the PhoneGap name – and now distributes Cordova under that name.

Pros

  • Regardless of server side platform & language experience, a significant number of developers have experience with HTML, JavaScript and CSS. Apache Cordova allows developers to immediately leverage these existing skills. The value of this can’t be overstated – as it reduces training and can enable a quick-to-market stance in companies ready to adopt it.
  • Cordova apps install just like a native application, and are able to leverage app store discoverability.
  • Cordova follows a plugin architecture, which means that access to native device APIs can be extended in a modular way. There are a lot Cordova/PhoneGap plugins to choose from – enabling developers to focus on the web-based skills they already have. (This is a weakness as well, as we’ll see in a moment.)
  • Cordova is open source and free, so there are no licensing costs (also a potential weakness, mentioned below).
  • Cordova/PhoneGap solutions existed in this space early on, and have matured to the point where value-add offerings on top of the basic CPT are the norm. For example, both Adobe’s PhoneGap Build and Telerik’s Icenium enable developers to build for supported target platforms in the cloud, without local SDKs (meaning non-Mac users can build iOS applications). In addition to Icenium’s cloud build services, Telerik also provides Kendo UI Mobile (an MVVM framework targeted for performance on mobile), app analytics via EQATEC and a Backend-as-a-Service (BaaS) offering named Everlive. Adobe has integrated PhoneGap Build capabilities into Brackets (a web based IDE) and Dreamweaver.

Cons

  • Of course, being free is no guarantee of success. In fact, the emergence of PhoneGap Build and Icenium are clear demonstrations that a “bare bones” Apache Cordova is woefully incomplete. The strength of being open source – and leveraging the talents of a wide array of contributors – is both a blessing and curse. If you need to extend your app with a custom Cordova/PhoneGap plugin, odds are you will find one. Yet it may be out of date and not support the target platforms you need.
  • The plugin architecture works well if you can find the plugins you need or if your web developers are capable of changing gears to write their own custom plugin(s) as needed. However, odds are that you chose Cordova, in part, to avoid the need for specialized native platform skills.
  • The performance of Cordova/PhoneGap apps has often been criticized. Native UI will always outperform a hybrid solution, but improvements in device hardware and WebView implementations have narrowed the gap. Your web developers will need to pay close attention to performance, which means their knowledge of profiling tools as well as which web UI frameworks are mobile-friendly is essential.

Appcelerator

Appcelerator’s Titanium provides a unified (across devices) JavaScript API, coupled with native-platform-specific features. Developers write JavaScript and utilize a UI abstraction (the Alloy MVC framework) that results in the use of native UI components, greatly aiding UI performance compared to other hybrid options.

Pros

  • The use of native UI components is a performance win, and the Alloy framework attempts to normalize UI across platforms.
  • The use of JavaScript to normalize code across platforms enables you to leverage existing skills on multiple target platforms.
  • Appcelerator provides value-adds such as a Backend-as-a-Service (BaaS), app analytics and a marketplace for 3rd party components.

Cons

  • Developers are required to manage target platform SDKs locally. It’s highly recommended for your team to establish a controlled build environment/CI process if you choose to manage SDKs locally, especially if you target multiple platforms. SDK version & build-related issues can be a horrific time sink, when you really need your team delivering features.
  • Normalizing the UI across platforms, while arguably a “pro”, is also a “con” in that your team will need to train on a proprietary technology to gain skills that are not directly transferrable outside Titanium.

Adobe AIR

Adobe AIR is “a cross-operating-system runtime that lets developers combine HTML, JavaScript, Adobe Flash® and Flex technologies, and ActionScript® to deploy rich Internet applications (RIAs) on a broad range of devices including desktop computers, netbooks, tablets, smartphones, and TVs.” The problem with that description is that you cannot use HTML & JavaScript to write Adobe AIR applications for mobile applications (Flash/ActionScript skills need only apply).

Pros

  • Adobe AIR has impressive reach – running on a wide array of desktop and mobile devices. In addition, if you plan to have a more involved/animated UI (and don’t plan to use a native approach), using AIR over a HTML/JavaScript/CSS approach may help.
  • Most Flash/ActionScript developers consider the IDE tooling for these technologies as mature.

Cons

  • The “elephant in the room” for many mobile developers is the fact that Adobe purchased Nitobi (and the rights to the PhoneGap name), clearly signaling to many that AIR may not be a long term strategy for mobile development. This combined with the rapid decline of Flash erodes the confidence many developers might otherwise have in choosing AIR.

Sencha

Sencha Touch is an HTML5 mobile application framework for building web applications that look and feel like native applications. Apps built with Sencha Touch can be used with Apache Cordova/PhoneGap or Sencha’s native packager – either which will package the application in a native container and enable access to select device-level APIs unavailable to traditional web apps.

Pros

  • Sencha have produced a larger quite of interoperable products, from “Sencha Architect” (a visual HTML5 app builder) and “Sencha Touch Charts” (for data visualization) to IDE integration with the Sencha Eclipse Plugin and an secure Enterprise app deployment story with Sencha Space.
  • Sencha Touch offers an MVC style architecture, a library of UI components, an extensible API and UI themes among other features.
  • Native packaging is possible via Apache Cordova/PhoneGap or Sencha’s SDK.

Cons

  • Mobile apps written with Sencha Touch can suffer from the same performance pains as Cordova/PhoneGap apps if developers aren’t disciplined in writing efficient JavaScript and DOM structure(s).
  • Many developers already have established opinions and experience with preferred frameworks for building HTML5/JavaScript/CSS based apps. Sencha’s emphasis on its own stack will be perceived as vendor lock-in.
  • Extending a Sencha Touch app with access to additional native APIs will likely involve writing custom Apache Cordova/PhoneGap plugins. This will require specialized platform skills (or training to acquire them).

Qt

Qt (“Cute”) is a cross-platform development tool that targets a number of embedded, desktop and mobile platforms. Developers write using “QML“, touted as a “CSS & JavaScript like language”, and apps are backed with an extensive set of C++ libraries, and utilize graphics/UI components written in C++. [UPDATE: As clarified by @qtproject, “Qt exists as a free and open source version from @qtproject and a commercial offering on top, from @QtbyDigia“]

Pros

  • Qt provides a substantial set of libraries containing intuitive APIs for things like threading, networking, animations and more.
  • Qt’s IDE tooling (Qt Creator IDE & Qt Designer) appear to be solid development tools, and code profiling is available in QML Profiler.
  • Qt Linguist enables translation and internationalization in applications – giving you the support of multiple languages within your app (in a single binary).

Cons [updated thanks to new information from Digia]

  • Qt’s tools are advertised as a “complete tool chain”, and QML is a proprietary language specific to Qt’s stack. Committing to this approach could be seen by many companies as ‘platform lock-in’, given that most businesses are seeking to re-use existing skill sets when adopting a CPT, not fragment skills further. (The leap from JavaScript to QML may not be as far as a leap from web-based skills to Objective-C, for example – each team just needs to evaluate what it can handle).
  • [Updated] Originally we listed pricing as a “con”, since full commercial support could exceed €4,000 (this includes plug-in development, platform development, device modification as well as unlimited support and updates). The cost of this kind of support is significantly higher than support costs for the other CPTs we’ve looked at. However, Digia reached out with a link to the recently announced Qt Mobile Edition. According to Digia the monthly fee will be $149 (approximately €110) and will launch in the coming weeks after the release of Qt 5.2.  This pricing level puts Qt’s mobile development costs more in line with the alternatives we’ve discussed. (It’s also important to note that Qt supports an open source LGPL v2.1 license.)

Reality: You’ll Probably Use More Than One

In our Developer Economics 2013 report, we noted the following:

Developers most often use several cross-platform tools; on average CPT developers will use 1.91 CPTs, confirming the lack of maturity and niche nature of cross platform tools much like we observed in our dedicated CPT survey just over a year ago. Moreover, we found that one in four developers will use more than three cross platform tools.

What CPT(s) do you plan to investigate or adopt? Check out the full list of CPTs we’ve identified.

 

Which of these are your favourites?  Test your skills in the new Developer Economics Survey and win awesome prizes.