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.

Categories
Platforms

Is Android First Really a Myth?

Popular perception in the tech press is that iOS gets all the best apps first. With Android market share beginning to dwarf that of iOS globally, there’s lots of speculation around when developers will switch to Android first. Our data shows iOS is still the priority for startups in the U.S. but that doesn’t necessarily apply outside the high-growth consumer app market, or elsewhere around the globe.

VM_76_transformers

The importance of platform priority

Just over a week ago, Steve Cheney wrote the very widely shared “Why Android First is a Myth”. The post makes some well-reasoned points about an important issue for the future of the smartphone market. One of the things that makes iOS attractive to a significant subset of early adopters is that it gets most apps ahead of other platforms, sometimes exclusively. [tweetable]If most developers start targeting Android ahead of iOS then those users will switch platforms, taking their app and service spending with them[/tweetable]. Where the early adopters go, most of the rest of the market will eventually follow. As such, developer priorities are considered an early indicator of platform fortunes, particularly at the high end. So if, as Steve suggests, iOS is set to dominate Android in this area for many years yet then Apple will keep making the bulk of the profit in the smartphone market. So is he right?

Silicon Valley doesn’t dominate apps globally

The major problem with the “Why Android First is a Myth” argument is that it is incredibly Silicon-Valley-centric. Whilst the two major smartphone platforms may be developed in Silicon Valley and dominate globally, the content and services used on them does not follow that pattern. Although there are lots of apps in common between U.S. and European app store top charts, there’s still plenty of highly ranked local content in most countries. Looking at the top grossing charts of massive smartphone markets like South Korea, Japan & China, U.S. users would struggle to recognise the name of any publisher (major exceptions being Supercell and King.com from Finland and the U.K. respectively). Not only is the assumption that the apps that make a platform attractive are going to come from the U.S. (or even “the West”) flawed, the assumption that they’ll primarily come from “sophisticated startups” is as well.

Mobile messaging services provide a good example. While VC funded startups may be the way many new services get built in the U.S., WhatsApp being a typical case, the global competition is rather different. KakaoTalk comes from a startup of sorts, although founded by a former CEO of Korea’s internet giant NHN, while LINE came from the Japanese subsidiary of that same Korean internet giant. WeChat comes from Tencent, China’s largest internet company and one of the biggest in the world. It’s more than just how the apps get funded and built though, it’s the types of apps too. The breadth and depth of the app offering on a platform is essential to have all the apps that are important to any individual user, whether it be an app from their bank or niche apps catering to their interests. Otherwise the Windows Phone strategy of paying for the most popular apps to be ported would be a lot more successful. As Paul Graham says, VC funded startups are all about growth, so they have to address issues that they believe are relevant to very large markets. They don’t build more niche or local apps and they don’t build the essential extensions of existing services to mobile devices. This suggests that the platform preferences of a much wider range of developers are important, not just the “sophisticated” startup developers.

Global platform preferences

With this in mind, VisionMobile has a great source of data for monitoring this important platform priority trend. Our regular Developer Economics surveys ask thousands of developers to rank the platforms they use in priority order. Just looking at the data from the last survey on which platforms are most frequently cited as primary by developers in each country we can see strong geographic patterns.

[tweetable]In almost all countries there are a significant fraction of developers who treat Android as their primary platform[/tweetable] and overall the number of developers with iOS and Android as primary platform is almost exactly even. This is biased by a large number of Hobbyists and Explorers* who overwhelmingly prefer Android, largely because it costs less to get started and the platform is more open. As such, iOS still leads by a decent margin (39% vs 32%) amongst those full time developers trying to build or grow businesses. However, this is not true everywhere with South America being dominated by mobile web developers and most of Asia ruled by Android. Europe is fairly evenly split between the two platforms. Most countries’ developer populations follow local user preferences with a slight bias towards iOS. A major exception is Russia, where iOS penetration is low but developers have an unusually high preference for the platform – this is not just outsourced development either; good technical education, a low cost of living and access to affluent global markets seems to be a great combination for smaller independent developers too.

What about startups?

Finally, if we’re purely talking about startups (or Gold Seekers in our segmentation) then iOS is clearly preferred to Android in North America. Out of those with iOS or Android as their primary platform, 70% are iOS first versus the 30% starting with Android. By the same metric, Asia has a 66% majority of Android first startups and Europe is split 50/50. Although our data set for this particular segment might not be large enough to be comprehensive, it’s clear that “Android First” developers are far from mythical!

If you work in a startup cluster and don’t agree with our numbers then please leave us a comment.

* Explorers are part time mobile app developers with a different day job – for more information on developer segments and their preferences see our segmentation report.

Categories
Tools

App Industry Picks & Shovels: How to succeed with mobile developer tools

developer tools

In the great app store gold rush of the last 5 years a lot of vendors of virtual picks and shovels have set up shop, hoping to cash in on the boom regardless of which individual developers succeed in a fiercely competitive market. Having surveyed developers on their tool choices and revenues, we can see how popular these third party tools and services are. We can also reveal whether those buying the virtual picks tend to do better than those who opt for the virtual shovels, or whether you really need both developer tools.

Print

With great opportunity comes great complexity

As the expected level of quality and functionality in mobile apps is increasing, the monetisation strategies are also getting more complex. [tweetable]In order to succeed, most developers need advanced tools to manage quality in a world of fragmentation[/tweetable]. To optimise revenue models beyond the simple paid download, systems to acquire and analyse the behaviour of users are also essential. Most developers turn to third parties to provide some or all of these tools. Many additionally look to third parties to provide some of the functionality, particularly via scalable cloud-hosted services.

Over 85% of developers who completed this section of our survey use at least one third party tool, while just over 45% of developers use tools from at least 3 different categories. There’s clearly significant demand but how does tool adoption correlate to revenue? Looking at only those developers who generate between $1 per month and $5 million per month (i.e. excluding those not trying to make money, not yet making money and the mega-rich – n=1596) we get the following:

More developer tool use, less risk

Looking at only the mean average revenues you could be forgiven for thinking that developers should be avoiding most third party tools, since by far the wealthiest developers are those not using them. However, a look at the median revenues shows the opposite. Some of the largest and most successful developers can afford to build and control their own tools so don’t need third party offerings. [tweetable]The vast majority of developers trying to make it without any third party tooling support generate hardly any revenue at all[/tweetable]. The median number of people involved in development for the organisations not using tools is 1, whilst it is 3.5 (2-5) for all other results. In general the increasing median revenue with use of more tool categories suggests that those who use more tools have lower financial risks. It’s tempting to speculate that there’s some causation here where developers are able to offload some risk by using proven third party solutions. In fact, the major driver is that the tool categories cover such a wide spectrum of apps that the more you use the more likely you are to be doing a lot of contract development – an inherently lower risk revenue model.

It’s not what developer tools you use, it’s how you use them

How use of tools in the various categories correlates with revenues doesn’t produce any great surprises. Those using cross-promotion networks, game development tools and ad networks are at the bottom of the revenue pile. Large game developers and publishers tend to have their own game engines, can cross-promote with their own titles and even run their own ad systems. The [tweetable]smaller, independent developers who rely on third parties for this typically struggle to climb the app store charts[/tweetable]. App store analytics users are next up from the bottom, this may simply reflect the relatively poor revenues of those who rely on app stores. Most other tool use was correlated with fairly average revenues. Notably above average, ranking second overall, is Backend-as-a-Service (BaaS) – where the mean revenues are about 35% higher than average and the median revenues 50% higher. As a result those using a BaaS typically beat average revenues by significantly more than the associated costs.

Using the data from our survey at the beginning of the year, we previously argued that developers who collect lots of analytics and quality data for their apps and act on it are significantly more likely to succeed. Users of crash analytics tools had the highest mean ($26k/person/month) and median ($2.1k/person/month) revenues of any single tool category in the latest survey. Nearly 50% of respondents to this section of the survey now use usage* analytics tools so it’s unsurprising that their mean revenues are almost exactly average ($17.5k/person/month) although noteworthy that their median revenues are 50% above the average ($1.5k vs $1k). Those using both crash and usage analytics tools had similar mean revenue to those just using crash analytics but significantly higher median revenue ($3.5k). The only tool combination to beat this was crash and usage analytics plus beta testing, which had mean revenues of $33k and median revenues of $3.75k. Beta testing tools can also help developers to improve the quality and usability of their apps, as such it’s interesting that those using just crash analytics and beta testing had extremely low mean ($5k) & median ($750) revenues. Possibly this last tool combination typically signifies a developer with a quality problem rather than one proactively seeking quality?

Is selling picks and shovels where the real money is?

There are some massive app developer success stories but our data suggests that the typical app developer (as represented by median revenue) is struggling to break even. It turns out that the developer tools market is similarly competitive. Selling services to developers ranks third in mean revenue per organisation and per person involved amongst all revenue models (behind per device royalties/license fees and subscriptions). Compared to the users of the tools the mean average income at $29k/person/month is slightly higher than for users of any single tool category but the median income is exactly the same as for the tool users.

* This category gets called both “user analytics” and “usage analytics”. The developer tools do both, although if you only use them to get an idea of who your user base are and how often they use the app (user), rather than what they do in the app (usage), you’re probably doing it wrong.

Categories
Business

6 tough questions on app business models and strategies

[VisionMobile’s Andreas Pappas was recently quizzed on app business models, best practices and strategies for developers and entrepreneurs. In this post we’re presenting the most interesting questions and answers from this interview. These are tough questions that all developers and entrepreneurs are faced with in the early stages of their ventures.]

 Print

Q1: I am thinking of developing my own mobile app: What are the main business models I can use to make money and how do I select the right one for my idea?

There are numerous factors to take into account when developing your business model but the two key questions you have to ask are:

  1. What problem am I trying to solve?

  2. How am I solving this problem?

Once you have answered these two questions, you will be in a much better position to develop a business model. A good place to start from is the Business Model Canvas, a simple tool that outlines the key areas that a business model needs to address.

A number of areas within your business model are interdependent. For example, your target market will initially be defined by the problem you are solving. Once you have identified your target market you can start thinking about revenue models, marketing, partnerships, distribution etc.

While it helps to get everything right the first time, it is most likely that you will need to adapt both your product and your business model several times along the way.

From an economics perspective, a large number of successful business models these days are built on two-sided networks and even multi-sided networks. These are usually services that connect businesses to consumers or consumers to consumers, such as, for example AirBnB and eBay type services. These models exhibit powerful network effects if they manage to scale up and allow owners to monetise either one side of the network (e.g. consumers or businesses) or both (e.g. commission-based) depending on the application.

[tweetable]When it comes to making money, there is a variety of revenue models available[/tweetable] and the selection is to some extent dependant on your business model, competition, target market, and exit strategy. There is no one-size-fits-all solution here.

Free services can scale up quickly but monetisation may be problematic. So if your business plan requires scale, think about indirect income sources such as advertising or even VC funding, to get you through the growth phase. Once you’ve achieved scale, an exit is an option you should consider: user acquisition is expensive and larger businesses will frequently opt for acquisitions rather than organic growth.

[tweetable]Advertising may be profitable but requires massive scale and even then, getting it right is tricky[/tweetable]. Advertising is more popular on Android and WP than on iOS, due to the fact that Android users are not as heavy spenders as iOS users.

Obviously app-stores allow developers to monetise their apps directly, via paid downloads or in-app purchases. The latter has become increasingly popular, particularly on iOS and competes favourably against paid-downloads.

Beyond these obvious ones there is a range of options that have to do with the type of app/service that one is providing. For example, apps offering content or services (e.g. news apps or some fitness apps) may utilise a subscription model. This app business model is not easy to pull off though – even popular newspapers are struggling to make money off subscriptions.

 Advertising most popular revenue model

Q2: I am a mobile developer. Which sectors have the most potential in my country?

The good thing about mobile apps is the fact that the market is global and the costs and barriers to reach international markets are very low compared to other, more traditional businesses. So mobile app development should not be seen in the traditional way of “what works in my local market” but instead, from the viewpoint of “what works in the markets that I want/I am well placed to reach”. In short, any sector has potential in your country if your focus is international and it should be international-first.

While this change in mindset is critical, that is not to say that there are no opportunities locally. If one is developing apps that rely on local content or services (e.g. transport services) then highly localised content is required. So it may be easier for local developers to source and access this content, although this is not always the case.

One would think, for example, that local travel/tourism apps would be more successful since they’re optimised for each region. However, the most successful apps in this sector are global because they have scale. [tweetable]For most apps, scale is critical and thinking locally can only get you so far[/tweetable].

Q3: What is more difficult? Coding or marketing the app?

The consensus among developers says marketing. While adopting new languages, frameworks, SDKs and APIs may pose challenges, it is usually a straightforward matter of learning to use new technology. For most developers, marketing has been uncharted territory until the very first app-store appeared. Mobile marketing is quite a different beast to anything that was available before iPhone-era smartphones. Even digital marketing specialists may find the landscape too perplexing since the strategies, practices and even the KPIs are in constant flux. Constant experimentation (in other words trial-and-error) is one of the strategies most frequently used in order to find out what works best in your case.

Q4: What are the best ways to do marketing for my app and acquire users/downloads etc?

😉 See above. The best advice is to try several options and see how they work for your particular case. Before you pay for any advertising or promotion network, try some textbook marketing methods that are still of great value:

#1 Cross-promotion

If you have several apps, make sure you promote your other apps through them. Of course this must be done in a way that will not annoy your users. If you can promote your app through other apps, that’s also a good idea.

#2 Become part of an ecosystem/platform

Make your app work with other apps if this is an option. For example, if you’ve developed a fitness app that could work with Withings or Runkeeper, why not make it work with these and gain more visibility through their own ecosystem?

#3 Do some PR

Let people know about your app. Send emails or press releases to popular websites, newspapers and anyone with a sizeable reach. Most of them may not respond but it’s definitely worth a try and there are several success stories that started this way.

After you’ve done the above, there are plenty of options to try, depending on your marketing budget. If you have determined how valuable each customer is to you, then you can hire a mobile marketing expert to handle all your marketing activities and pay them per customer acquired.

Q5: What are the most common mistakes that mobile app developers do and how can I avoid them?

#1 Failing to see app development as a business

[tweetable]The best technology solution is not good enough without the right business models and execution[/tweetable]. This is one of the best known principles in the area of technology strategy. Developers that lack business experience often fail on the commercial side of the business.

#2 Failing to prepare for success

The nature, scale and pace of the app economy is such that in a matter of days your user based may grow from tens to tens of thousand users. Will your back-end cope? Will you be able to pay for third-party API calls utilised in your app? If not, what may have been initially a great service, will fail due to poor customer experience or you may run out of money. A proper business case should anticipate success.

#3 Failing to pivot/adapt

A common advice in the startup world is “pivot till you die”. If your idea is not working try applying it on a different market, adapt it to the current market, flip it on its head or scrap it altogether and go for something else.

#4 Failing to know and listen to your users

In a market where consumer switching costs are so low and a user can easily replace your app with the competitor’s app, user experience and customer support are critical success factors. Your app will be deleted if it crashes repeatedly, if it is poorly designed, or does not deliver what it says on the tin. Test your app, test it again, use crash-reporting and user-analytics services and keep it up to date, implementing new features and listening to user feedback.

Q6: Is it better to try to innovate with a never-seen app, or is it better to be a follower?

Neither is easy and both can work. The advantage of being a follower is that you learn from others’ mistakes and failures. You may for example see what is not so good or what is missing from an app and fill the gap, or extend it into another market. The downside is that by the time you do it, others will probably be trying to do it too, so there will be more competition. You don’t just need a better app, you also need better execution, i.e. a better business model and marketing, in order to topple the leader.

On the other hand, a new, innovative idea can take you a long way before the competition catches up (although never at a safe distance) but it is more difficult to create a niche and then expand it.

[tweetable]While most developers develop apps they want to use themselves, this should not be the only criterion for developing your ideas[/tweetable]. At the very least, discussing with users, friends or researching the market can get you a long way.

Those developers that extend tried and tested ideas into new markets are usually more successful. That doesn’t mean that you can just copy an app; you have to adapt the business model to the new market at the very least. In the app economy innovation is not limited to technology but extends to business models too.

Successful developers grow by extending to new verticals

Comments? More advice? Feel free to start the conversation.

Andreas Pappas

Follow me on twitter @PappasAndreas

Categories
Business

App monetisation: Games vs. Enterprise and Business Apps

The mobile apps business is maturing and while most of the media attention is still focussed on the latest app store success stories, developers are finding lots of better ways to improve app monetisation. Considering all revenue sources, which categories of application are generating the most money and what’s the competition like on each platform?

DE12c3_web

App Stores not the answer?

In our last developer economics survey we asked developers to give us a breakdown of their revenue from different sources. Of the 1,695 developers earning between $1/month and $5 million/month who reported their revenue breakdown to us, 55% generated some of their income from app stores. There is a negative correlation between the fraction of revenue an organisation earns from app stores and the total revenue they earn per person involved in app development. That is, the more you rely on app stores for revenue, the less you are likely to make any. By excluding those with revenues above $5 million/month, we’re ignoring the very top of the store charts where the bulk of app store revenue is made. However, this is just a handful of developers, who would otherwise have an extremely disproportionate effect on the average. It’s also worth noting that [tweetable]there are limited costs involved in app store publishing but it produces the lowest average revenues of all sources[/tweetable] in our survey – it’s clearly not the easiest way to build a profitable app business.

Is there gold anywhere but games?

With games accounting for around 75-80% of all app store revenues it’s possibly not surprising that they were the most popular category of app amongst the developers in our survey. Given the chart above it shouldn’t be surprising that they are far from the most profitable (~$2,500/person/month more than the lowest mean income and the lowest overall median income). So [tweetable]which were the most profitable app categories? Business Productivity and Enterprise apps[/tweetable]. However, there are some significant differences between platforms so it’s worth playing with the interactive chart below to spot any opportunities that might be of interest.

[tweetable]Median developer revenues are higher on iOS than Android across all categories[/tweetable], but in some categories mean revenues are higher on Android. This shows that there are some developers managing to exploit the much larger market on Android successfully but most developers are still financially better off on iOS, including revenues from outside the app stores. Where average revenues across all platforms were higher than either iOS or Android, web developers were usually making the most revenue in that category.

The averages in the charts above still hide a lot of potentially interesting detail on where the best opportunities in the apps market are. Those wanting a more complete analysis should look at our App Economy Forecasts report.

Categories
APIs Tools

Accelerating Web Apps – It’s all about politics

On desktop computers web apps have come to dominate many application categories. They are easier to develop and deploy across multiple platforms and it’s possible to iterate much faster. A very large number of developers would like to be able to apply the same technologies and techniques on mobile devices but very few are able to do so successfully, particularly for mass market consumer apps. One of the most important reasons for this is performance. Resolving this issue is much more about politics than technology.

Are mobile web apps doomed to be slow?

Back in July, Drew Crawford wrote a blog post that got a lot of attention essentially claiming that JavaScript performance on mobile devices was simply too slow for serious apps and likely to stay that way for the foreseeable future. It showed, amongst other things, that the browser on the iPhone 4S was around four times slower than the slowest browsers capable of running Google docs real-time collaboration or Google Wave back in 2010. He claimed that ARM processors were not going to get faster rapidly enough to make a difference and JavaScript runtime improvements had stalled and were unlikely to make significant progress. Technically both of these points seem to have been proven wrong already. Apple just announced the iPhone 5S, with a processor twice as fast as the iPhone 5, which was in turn twice as fast as the iPhone 4S – so we have four times more raw CPU performance than we had just two years ago, theoretically enough to support 2010 desktop class browser performance. Also, Mozilla are working on asm.js, which uses a subset of JavaScript compiled ahead of time (AOT) and promises to enable apps to run in the browser at just 1.3 times slower than native performance – almost another four times speed increase versus the current five times slower than native performance of modern JIT compilers.

In addition to being at least partly incorrect this is also looking at a very narrow area of browser performance, a point well made in Sencha’s blog post in response. Across all vendors there are key performance areas where each is 10-40 times behind another. In reality, most of the major performance issues that prevent web apps from being competitive with native apps are related to graphics performance. Mobile device users have come to expect slick animated UIs which are only enabled by GPUs on the devices rather than, say, manipulating the DOM with JavaScript. Fortunately HTML5 and CSS3 provide several opportunities for GPU accelerated graphics with e.g. Canvas, CSS animations and WebGL. So, as mobile hardware and browser software continue to improve over the next couple of years competitive web apps should be just around the corner, shouldn’t they?

Platform wars and politics

With the technologies available or on the very near horizon today, plus improvements to mobile browsers across the major platforms, there’s almost no doubt that we could have competitive web app performance. The problem is that to get there requires platform providers and OEMs to adopt the technologies and implement the improvements – it’s not necessarily in their interests to do so.

Apple and Microsoft want users locked-in while Google wants them logged-in. Mozilla wants the open web everywhere but Google funds them. Opera recently gave up on writing their own browser core and use Google’s instead. That’s over-simplifying but fairly accurate. With other browser vendors attempting to prevent the user tracking that Google’s business model depends on (through default Do Not Track settings or third party cookie blocking) the best way to ensure users stay logged-in is to get them all using Chrome. This means they’re fighting a new browser war for control of the desktop web and taking that to the bulk of the mobile market through Android. In the process they are building several browser technologies to differentiate rather than standardise (e.g. they’ll prefer their own Native Client solution to asm.js).

At the same time Apple wants a great browsing experience but wants developers to build native apps rather than cross-platform web apps. As such they adopt most new web standards quickly but are very slow to include any that might enable high performance web apps – e.g. WebGL has been implemented since iOS 4.2 but only enabled for iAd, not in the browser, also Apple has famously not enabled their JIT compiler in the WebViews used by wrapped web apps* (needed to access native APIs) slowing their JavaScript performance by almost four times. Mozilla’s asm.js seems a very unlikely candidate for Apple to adopt anytime soon. Unless their new CEO makes a major change of strategy, Microsoft seem determined to follow the Apple model, although they might need first class web apps enough to accelerate their standards adoption.

A ray of light?

While there may be several classes of app for which mobile browsers are already good enough, for those hoping to develop all apps with web technologies, the news is not all bad. Although it seems unlikely to be possible to deliver a single solution with great performance everywhere, we might not be far from being able to deliver a good level of performance almost everywhere. Although Apple appear to have some strategic performance limitations, they also have some of the fastest hardware on the market. At the other end of the spectrum good Android browsers are reaching low end smartphones and the Firefox OS, also targeted at low cost devices, has an excellent web app environment. The other good news is that while we have real competition in the mobile market, browsers should keep getting better all round. We’re unlikely to see the return to stagnation of the Internet Explorer dominated early 2000’s.

* Apple do have a good security reason for doing this but they haven’t been in a hurry to resolve it either.

Categories
APIs Languages

Websites vs Web apps: What the experts think

websites-vs-webapps

Definitions of web sites vs. apps

Web sites are so deeply embedded into our daily culture that it is impossible to imagine life without them. Even as a developer, I find it hard to remember the times from my childhood when my chubby little hands didn’t yet know how to type. In the last two decades, the Internet has grown, expanded, exploded and became impossible to ignore, making any keyboard without an Internet connection pretty much useless.

In the last few years, the web brought with it a new term that can be exciting and confusing at the same time: “web app”. But what is a “web app”, how does it differentiate from a “web site” and why does it matter?

Understanding this difference ultimately makes us better users or developers? Is a business going to blossom just by marketing its online presence as a “web app” instead of a “web site”?

To figure out the boundaries between websites and web apps, I interviewed several prominent figures in the web technology domain who contributed with their experience and professionalism to help guide the debate: Dominique Hazael-Massieux (Mobile Web Initiative Activity Lead at World Wide Web Consortium), James Pearce (Head of Developer Advocacy at Facebook), Michael Mullany (CEO at Sencha), Christian Heilmann (Principal Developer Evangelist – HTML5/Open Web – at Mozilla Corporation) and Stephen Pinches (Head of Learning Technologies – ELT at Pearson plc and Group Product Manager – Mobile & Emerging Platforms at Financial Times). In this article I pieced together their expert input to help answer the web site vs web app debate.

The difference between Web sites and Web apps

In the pre app store era, the word “applications” had been applied to Web sites that provided advanced user interactions and capabilities previously available only through installable software. Early examples of web applications include Webmail, Google Maps and Google Docs. Compared to the classic web, i.e. blogs and news sites, web apps provided a richer user experience and access to advanced browser capabilities.

Today single-page web sites might still be referred to as web apps, but it’s more about the task focus than the technology itself. From this perspective, as Christian Heilmann explains, “The use case of an application is always to DO something with it”.

The task centricity of web apps is easier to understand if you think of smartphones or tablets: an app’s purpose is to achieve a specific task, like making a call, checking your email or finding a taxi nearby.

Some may argue that we can simply classify Web sites as being read-only and Web apps as being read-write. That certainly seems simple enough: Web sites are for consumption what Web apps are for creation. Does it sound right?

For developers, it is easier to draw the line between web sites and web apps if we think of the technical distinctions. Web apps have some defining attributes that bring them closer to their native counterparts:

  • self-contained
  • rich/interactive user interface, possibly mimicking the native UI of the device,
  • using advanced device capabilities – like geolocation, camera integration, or other technologies that the W3C Device APIs and Policy Working Group is developing,
  • action oriented rather than information oriented
  • not relying heavily on (or hiding when possible) the browser chrome (back button, reload button, address bar),
  • working off-line, for example using HTML5 ApplicationCache, localStorage, or indexed database.

Mozilla’s Christian Heilmann argues that the offline attribute is not a technical necessity in terms of definition, but rather a crucial usability distinction:

“Seeing how flaky our connections are – I am writing this on a plane – our apps should make people as effective as possible and this means we shouldn’t be dependent on a connection. The interface should be usable whilst we are off the grid and sync as soon as we go online”.

But how can we explain the difference to non-technical users? And, do we need to?

According to Dominique Hazael-Massieux, a Web site can be presented as a Web app as long as users consume it in a similar way they do a native app. If it’s exposed as an iconified app and used for a specific task, it shouldn’t matter whether it’s contained in the browser or installed via an app store. Facebook’s James Pearce outlined a few possible vectors that need to be considered when differentiating between Web sites and Web apps. I‘ve summed up his arguments:

Creation versus Consumption

Pearce asserts that read-only interaction should be classified as a site, but this criteria is not sufficient to distinguish between web sites and web apps. We still have cases like Flipboard (clearly oriented towards consumption) or Twitter and Facebook (with entirely user-generated content) that do not fit in any box.

Linkability

Since both web sites and web apps can be launched by entering a URL into a browser or from a home-screen icon, this is clearly “not a reliable way to distinguish between web apps and web sites” according to Pearce.

User Experience

Visual pizzazz is an important argument, one that users might particularly relate to, but is also a fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list appears as hyperlinks instead of ‘tappable’ items? What if I use plain scrolling instead of smooth fancy bars?

Architecture

In the case of single page webapps, is SEO the price to pay when choosing to give the browser far more autonomy and responsibility and take advantage of its HTML5 APIs like storage? Do Web sites have SEO capabilities while Web apps don’t? We are back to explaining the differences between the two by using technical terms.

Should you be building web apps or web sites?

This question might be regarded as a technicality with a pinch of marketing to spice it up. This reminds me of the “HTML5 is ready” contest by Sencha that was announced a few months back, encouraging developers to draw inspiration from native apps and create similar web apps that show off the capabilities of HTML5.

The creators of the competition correctly argued that “the mobile web is the most fertile ground for leading edge web development because it doesn’t have the legacy of the older internet explorers that the desktop does. You can start your development with the assumption that your app or your content will be used in a fairly recent browser, so you can take advantage of a whole host of features like Canvas, inline SVG, HTML5 video, CSS3 styling etc. that bring the experience alive for the user”, as Sencha’s Michael Mullany explains.

Would it be safe to argue in favour of building web apps instead of web sites especially on mobile? Mobile users perform specific tasks on their devices, so a web app that offers the same experience as a specialised native app might gain more interest compared to a regular website.

Long term the distinction should not matter. According to FT’s Stephen Pinches, it really doesn’t make any sense, on the long term, to speak about the future of the mobile web: “there shouldn’t be “mobile” and “desktop” but simply good, user-centered design, which adapts and responds to the screen size and features of the device upon which it is displayed. However, on short to medium term, there is a need to differentiate and ensure the user experience is as good as possible on a given device.”

The ‘app-ification’ of the Web

Whatever your preference may be, there is an increasing number of mobile developers targeting web apps. Based on VisionMobile’s latest Developer Economics survey of 6,000+ developers, already 23% of HTML5 mobile developers develop web apps, compared to 38% who develop mobile websites.

With browsers increasing support for device APIs, and with a growing number of developers going direct to native with PhoneGap, Icenium or Appcelerator, or even with the recently launched Firefox OS, the web world is clearly moving in the direction of apps.

As Sir Tim Berners-Lee said in 2012, “the solution is in your hands: develop web apps!”

Categories
Tools

Cross-Platform Tool Trends – Freemium & Flexible

CPT trends

CPT trends

Creating versions of an app for multiple platforms (at least iOS & Android) is an increasingly common requirement. Building and maintaining native code for every platform supported is both difficult and expensive. Cross-Platform Tools (CPTs) offer a solution to this problem by enabling sharing of code across platforms and in many cases a single code base can target multiple platforms. With such significant cost savings available, why don’t all developers use CPTs?

Learning curves & licensing

Unfortunately the platform spanning magic provided by CPTs doesn’t come without any costs. Most CPT vendors depend on licensing revenue – developers have to pay to use the tools. Of course the cost of licensing most of these tools is far less than the cost of a full native port of an app to one additional platform. However, there are more costs associated with adopting a tool than the license fee; learning to use a CPT and building confidence in it’s suitability for future projects requires a significant time investment. The potential future cost of switching away from a tool that isn’t working out as hoped is also something that developers must consider.

The spread of Freemium models

In order to build sufficient confidence in a CPT to build their businesses around it, some developers need lots of time for evaluation, perhaps building a side project before risking major apps or customer projects. For many the 30 day trials that were typical in the sector just weren’t sufficient. One of the first mobile CPTs, MoSync, was very early to recognise this and had generous free options early on, they even went open source with a dual licensing model back in 2009 around the time many of their competitors were just launching. This year has seen a tipping point, possibly partly due to increased competition in the sector but also to capture a larger share of the ever growing demand for mobile development – Appcelerator, Corona, RunRev, Unity and Xamarin have all either switched to freemium models or expanded their free offering for mobile. RunRev has also joined MoSync in releasing their code under an open source license, Appcelerator have open sourced more of their code and Xamarin have just open sourced some of their cross-platform API wrappers. Having access to the code for the cross-platform layer can help remove developer fears of getting blocked by a bug in their chosen tool and being entirely dependent on the vendor for a rapid fix.

Technical tradeoffs

In many areas platforms are sufficiently different that it’s not possible to unify them under a single API. CPTs get around this in a number of different ways:

1) Not providing access to the problematic functionality – this restricts what developers can create.
2) Providing a lowest common denominator API – this prevents developers from using the full power of the native platforms.
3) Providing their own implementation of the functionality – this can bloat apps and often prevents them from having a fully native experience.
4) Providing thin wrappers or separate extensions for each platform – this gives maximum control but adds complexity to the code, reducing the benefits of a cross-platform approach.

Different apps, or even parts of apps, will have different priorities that determine which of the above approaches are acceptable. For example, a mass market consumer utility app is likely to require a completely native look and feel for the UI, while an internal app for a large enterprise may want to look and feel exactly the same on all platforms to minimise both development and staff training costs. The same tradeoffs won’t always apply to every part of an app either; most games have a completely custom UI and don’t require access to the native platform UI components at all, however, they may well want access to the new Google Play game services, or the iOS 7 Game Controller APIs as soon as they are available.

A flexible future

Faced with a still growing list of platforms to support and wide array of new features in each new platform version, CPT vendors now have to specialise for a sufficiently profitable subset of the market that has fairly narrow requirements or become increasingly flexible. Most vendors currently provide flexibility through a native interface that enables the creation of third party extensions or plugins. Xamarin’s approach to flexibility enables developers to (semi-)automatically generate wrappers for any native API or library, which is ideal for developers who want to stick with C# for all of their own code yet build on the work of native developers for each platform.

Even greater flexibility is possible though. What if you could just build the parts of an application that made sense to be cross-platform with a CPT? RunRev has a beta for an embeddable library version of their engine to enable this, although currently only for iOS. They are also re-architecting their engine to put 3rd party extensions on an equal footing with the core functionality – even allowing them to extend the language where necessary. Another interesting option going forward here is Digia’s Qt, the open source cross-platform framework that was acquired and re-purposed for mobile by Nokia before they dropped it in favour of Windows Phone. Qt is now the native framework on BlackBerry 10, Ubuntu Mobile and Sailfish OS and is close to production readiness for iOS and Android; it also has a Tizen port ahead of the release of that platform. The core of Qt being C++, it can easily interface with native code on most platforms and has always been delivered as a library, so it’s also embeddable within native apps.

Flexibility enables greater agility

This library format means that developers can start cross-platform and add or optimise parts of their app with native code later. It’s possible to just add a full native experience for the platforms that get the most traction. Alternatively, starting on a single platform and then adding new functionality that works across all platforms after achieving some success and starting to port to other platforms is also an option. Last but not least, the library format also removes any concerns about lock-in. If a developer decides to migrate away from a CPT, they can do so gradually, without having to port/re-write everything in one go. It’ll be interesting to see how many vendors can push flexibility this far and how many developers take advantage of it.