Categories
Tools

A Look at Some of the Top Mobile UI Frameworks

Deciding on a cross-platform tool (CPT) when developing mobile applications is really only the first step of a larger journey. When you choose a web-based CPT (PhoneGap, for example), you’re typically faced with the decision of what UI framework to choose as well.

Blog007-Final

The good news is that there are number of powerful options available. We’ll take a brief look at a few of these in this post. There’s a wide range of what’s available in a UI framework – some focus entirely on widgets (UI components), others provide light app framework functionality and still others provide a more comprehensive set of behaviors covering widgets and application framework concerns. The “right” choice for your project will depend largely on what you need, your team’s background and what kind of control you want to retain over certain aspects of the application architecture.

There are SO many interesting options, it can feel overwhelming even if you’re a veteran of HTML5-based mobile development. Limiting this post to only 4 frameworks was difficult. I will include a list of additional frameworks at the end in case you’d like to explore beyond the few we cover. If you’re looking for a full list of UI frameworks, check out the relevant section on ToolFinder – our online app for helping developers find the right tool!

jQuery Mobile

jquery-mobile

jQuery Mobile is arguably the most widely used mobile framework – benefiting from association with the nearly ubiquitous jQuery project. Due to its recognition and association with jQuery-based open source development, jQuery Mobile boasts a huge number of 3rd party plugins, extensions, tools, themes and more.

High Level Overview

Developers writing mobile and hybrid mobile apps using jQuery Mobile will encounter the following:

  • Heavy use of HTML “data-*” attributes. For example, a “page” in a jQuery Mobile application is simply a DOM element with a “data-role” attribute value like this: <div data-role="page"></div> Experienced web developers will pick up these kinds of framework conventions quickly.
  • jQuery Mobile provides a light application framework – primarily covering navigation, & transitions between views. This can be extended via plugins, or through integration with more comprehensive frameworks. If your “app framework” needs extend beyond transitions and navigations (for example, templating, two-way binding and more), jQuery Mobile alone may not be a good fit.
  • It’s designed to work within a Responsive Web Design (RWD) context – enabling developers to target a wide range of devices.
  • A wide array of device and browser support as well as a helpful theme roller to help with quickly customizing the otherwise “clone” look and feel.

Despite its popularity, jQuery Mobile has been criticized for performing poorly in mobile browsers. The jQuery Mobile team continues to work to improve the framework, including performance issues. If your team opts for jQuery Mobile, avoiding deeply nested DOM structures & unnecessary reflows and investigating the use of libraries like FastClick can help you avoid some of the typical pitfalls that have earned jQuery Mobile the “slow” label.

Widgets

jQuery Mobile’s site currently lists 22 built-in widgets (though the number of custom/3rd party widgets is much higher). Among them are header, footer, navbar, listview, slider popup and more (all the basics you would expect). Creating customized widgets is likely a moderate amount of effort for most developers. jQuery Mobile’s good documentation and examples will be helpful for any team. You can view a list of demos here.

The screen capture below demonstrates one of jQuery Mobile’s widgets: the responsive grid listview:

Licensing

jQuery mobile is free and open source (MIT licensed).

Kendo UI Mobile

Blog007-Final
Telerik’s Kendo UI Mobile framework has emerged as a powerful and performance-minded framework for mobile web and hybrid mobile applications. Kendo UI Mobile provides both UI widgets and app framework functionality. Kendo UI Mobile is part of a larger Kendo UI framework that can target both desktop and mobile devices. In addition, Kendo UI Dataviz is arguably one of the best data visualization libraries available for both desktop and mobile web clients*.

High Level Overview

Developers writing mobile and hybrid mobile apps will encounter the following:

  • Theming that matches the ‘native’ look and feel of iOS, Android, Blackberry and Windows Phone 8, as well as a “flat” theme that looks nice across multiple devices.
  • Similar to jQuery Mobile, Kendo UI Mobile makes use of HTML5 “data-*” attributes. For example, a “view” in a Kendo UI Mobile application is a DOM element with an attribute/value of ‘data-role=”view”‘. This naturally extends to Kendo UI Mobile’s widgets as well, since (for example) an unordered list element can be made into a “listview” element simply by adding ‘data-role=”listview”‘ to the element.
  • Two-way binding, with a declarative syntax. Kendo UI Mobile provides some fairly sophisticated application framework features, with MVVM (model-view-viewmodel) infrastructure included. Application state is typically maintained in ‘view models’, which are bound to views (DOM templates). As data in views change, the view models are automatically updated (and vice versa). By “declarative” we mean that the metadata necessary to enable two-way binding can be provided in the actual markup. For example, to bind the text content of a span to the “firstName” value of a view model, developers simply include this in the markup: <span data-bind="text: firstName"></span> Frameworks supporting two-way binding often help eliminate the same tired boilerplate code necessary in traversing DOM structures to retrieve state (user input, etc.). This can be a big productivity boost for your team.
  • Also included in the application framework features: view transitions, navigation & layout templates (which can be highly customized) as well as “DataSources” – an abstraction over retrieving data from multiple kinds of sources (for example, simple HTTP services, local data or even some Back-end-as-a-Service offerings). The Kendo UI team has gone quite a ways further than primarily UI/widget focused frameworks like jQuery Mobile in providing more substantial application architectural help.

Widgets

Kendo UI Mobile’s site lists 13 built-in widgets, ranging from ListView, ModalView, and TabStrip to Navbar (including support for header & footer), Drawer and Scroller (and more). Kendo UI Mobile supports creating custom widgets as well.

The screen capture below demonstrates a couple of Kendo UI Mobile’s adaptive widgets: the Grid and Scheduler. You can view additional Kendo UI Mobile demos here.

Licensing

Kendo UI mobile is a paid framework which starts at $199 (includes support for 1 year).

Sencha Touch

Sencha will be a recognizable name to many web & mobile developers – likely due to their response to Mark Zuckerberg’s assertion that “HTML5 Wasn’t Ready”. Sencha went on to prove that HTML5 is, indeed, ready for many complex use cases in mobile applications. Sencha Touch – Sencha’s mobile focused HTML5 development platform – goes much further than providing only widget-focused features.

High Level Overview

Sencha recently updated Sencha Touch so that their device APIs fully support Apache Cordova (i.e. – PhoneGap). Similar to Kendo UI Mobile, Sencha Touch makes use of HTML5 and CSS3 (taking advantage of hardware acceleration where possible) to create web-based UIs for mobile apps that aim to rival native UI performance. Developers building projects with Sencha Touch can expect the following:

  • Sencha Touch leans more heavily towards “full app framework” than many other popular options. It provides an MVC style architecture, complete with storage, device profile and top-level application abstractions.
  • Sencha Touch ships with 50 built-in components (and developers can create their own as well).
  • It’s my understanding that Touch shares some common code with ExtJS (and common conceptual paradigms), so developers familiar with ExtJS will pick things up quickly. I would also argue that developers used to frameworks like Backbone.js will also pick up the concepts more readily than developers used to UI frameworks that focus on declarative bindings in markup.
  • Sencha Touch provides its own abstractions for things like history management and XHR – which is in line with expectations of any framework seeking to be a more “one stop/full-stack” option.

Widgets

Components are a key part of Sencha Touch’s architecture. Among the 50 built-in components are ones such as Carousel, Slider, DataView, List, DatePicker and more. In other words – like the frameworks we’ve looked at so far, the essential things you’d expect plus a bit more. The screen capture below is showing some of the animation demos in the “Kitchen Sink” demo application, which highlights many features available in Touch:

Licensing

Sencha Touch has a wide array of licensing options (which can be seen here). It’s free for commercial use (and a GPLv3 option is also available). Sencha offers paid support options for Sencha Touch, starting at $1395 for a 5-developer package.

Chocolate Chip UI

Chocolate Chip UI’s beta debuted on Github roughly 3 years ago. Currently at version 3.0.6, the project has been gaining recognition as a powerful and performance-minded option for both mobile web and hybrid mobile applications targeting iOS, Android and Windows Phone 8. Chocolate Chip UI’s site lists 12 widgets, but simply skimming the documentation will reveal many more. Chocolate Chip UI provides a substantial amount of UI/widget focused features, but also ventures somewhat into “application framework” territory by providing a number of utility methods & view transition features – though it stops short of client-side routing (though there’s nothing preventing you from integrating any number of routing libraries).

High Level Overview

Developers using Chocolate Chip UI will encounter the following:

  • Chocolate Chip UI makes use of semantic HTML5 elements to drive its widgets. Your team may find overtime that this aids markup readability.
  • Chocolate Chip UI encourages the use of their own JavaScript library (ChocolateChip.js) in lieu of jQuery. They maintain that it was created specifically for mobile use and that it is both faster and smaller. It is possible to use jQuery 2.0.3 on Chocolate Chip UI version 3.0.3 and newer. This may prove useful if your team has jQuery plugins which are essential to the project.
  • Chocolate Chip UI provides API hooks to create your own widgets which follow the same paradigm as creating jQuery plugins. This will aid your team’s transition from jQuery to ChocolateChip.js.
  • Chocolate Chip UI uses OS-specific theming, allowing you to target a specific mobile platform (currently iOS, Android and Windows Phone 8) simply by sourcing the appropriate CSS file.
  • Chocolate Chip UI provides layout behaviors to help organize your DOM structure, as well as a number of utility methods including script loading, type testing, string utilities, AJAX communications and more.

Widgets

As mentioned above, Chocolate Chip UI’s home page lists 12 widgets – among them things like Popup, Paging, Range, Switch and multiple types of Lists. However, as you review the documentation, you’ll notice mention of additional widgets such as slide out menus, masks (semi-transparent overlays), split layouts (for tablets) and more. You can see a few of these in the screen capture below (specifically, range/slider and pop-over):

Licensing

Chocolate Chip UI can be licensed either under BSD or commercially. For commercial terms, you need to contact Sourcebits to get a quote. I reached out to Sourcebits to get more information on commercial licensing, and they were very prompt & friendly in replying:

“…our terms for commercial use are an acknowledgment that Sourcebits’ Chocolate Chip UI was used in the creation of the app, something along the lines of “Powered by Chocolate Chip UI”, either in the app’s splash screen or ‘About’ page with tap/link back to ChUI’s awesome landing page, as well as permission to use the brand’s name/logo on our website. In addition we might also wish to collaborate with the brand to create a case study around their use of ChUI. We’d have the same asks if a ChUI web app were being deployed for internal use by an enterprise, too.”

Further Resources

Markus Falk has a fantastic mobile frameworks comparison tool which you may find quite useful in evaluating which options will work for your team. One thing to bear in mind: this comparison chart doesn’t differentiate between UI frameworks and cross-platform tools (like PhoneGap), so it’s useful if you’re looking up supported features for a given framework or comparing two frameworks of the same type (i.e. – apples-to-apples comparison of two or more UI libraries, or CPTs, etc).

Also – check out our own full listing of UI frameworks, on our ToolFinder web app,

This post can’t possibly cover all the UI framework options available – and choosing which ones to write about was extremely difficult, given the amazing number of good choices out there. I’d like to list a few more here to give you the option of further exploring which UI framework(s) may work best for you. Bear in mind that these are web-based UI frameworks for mobile web or hybrid mobile solutions that make use of web-based assets (like PhoneGap):

Have you used any of these options? If so, we’d love to hear about your experience. Feel like one is missing? Let us know! We’d love to hear what you’ve been using.

* I’ve used Raphael and D3.js – and love both (not to mention, both are free frameworks). I think very highly of Kendo UI Dataviz primarily because of the wide browser support (it uses canvas, SVG and VML, depending on the browser) and because of the accessible/intuitive API.

Categories
Tools

HTML5 performance is fine, what we are missing is tools

HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools?

HTML5-cover

In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers).

html5_stoppers

We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen.

Ciprian Borodesku, CEO of Web Crumbz, added “From a business standpoint, there’s a lot of education needed for the acceptance of HTML5. There’s a gap between what we developers can provide and what the clients think we can provide”. The perception of HTML5 being a less capable platform is also common amongst people who commission apps.

Experts point to a tools gap

As part of our How can HTML5 compete with Native? report, VisionMobile conducted 32 interviews with industry experts, from Miško Hevery (author of Angular.js) to Max Firtman (author of “Programming the Mobile Web & jQuery Mobile” published by O’reilly) and Peter-Paul Koch (author of Quirksmode).

It came as a surprise when Robert Shilston, director of FT labs, champion of HTML5 apps, noted that “the biggest issue for HTML5 is the maturity of tools”. He emphasized not performance, but tools, as the key HTML5 gap.

Ran Ben Aharon, head of front-end development of Everything.me, explained it in more colour: “Hearing Mark Zuckerberg denounce HTML5 made me angry at first, but then I looked at some data and realized that the main reason was not performance or APIs but the lack of memory management and debugging tools”.

Even though developers identify performance as the #1 problem of HTML5, a number of experts claim the actual challenge is tools. There’s no contradiction here, performance and tools are related. How can you improve an app, if you can’t measure it? How can you fix a bug, if you can’t replicate it?

HTML5 is like a car without a dashboard

[tweetable]Tools are to HTML5 what a dashboard is to a car[/tweetable]. You can’t run at high speed without knowing how fast the engine runs or you might end up totalling the engine. Likewise, you can’t produce fast HTML5 apps if you don’t have quality debugging and profiling tools.

With HTML5, coding and debugging are two separate processes. There is no self-contained IDE here. Developers code on the editor (e.g. vim or sublime) and debug on the browser, i.e. using Chrome developer tools. But debugging tools are difficult to master and they require a thorough knowledge of the underlying technology, e.g. what is a reflow, how does the garbage collector work, how is a memory leak created.

Louis Stowasser, author of CraftyJS noted “it would be great to have something like YSlow for game developers”. Why pick YSlow and not Chrome developer tools? Well, because the former offers insights on what to fix rather than data requiring interpretation.

Moreover, each browser has its own set of debugging tools. As a result, [tweetable]developers need to become familiar with at least 4 different environments to match the most popular browsers[/tweetable] of the market. And though it’s generally true that these tools look alike, it’s the little bits and pieces that make the difference.

Patrick H. Lauke, former product manager at Opera Software, highlighted the fragmentation of the browser debugging tools by commenting on a W3C public discussion board about our research: “Opera Dragonfly was the first to offer remote debugging and proposed a unified protocol for debugging. Sadly, other browsers showed very little interest and instead went their own separate ways to build something similar but different”. This also touches on the browser politics issue, due to be the subject of another blog post.

Better tools are needed

HTML5, as far as performance is concerned, is adequate for most use cases. And tools like famo.us and Goo Engine provide a testament. The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps. What the HTML5 platform desperately needs is easy-to-use debugging and profiling tools.

With the right tools we could see external debugging tools hooking to multiple browsers and even apps able to profile themselves via standard debug APIs.

Web development attracts millions of developers who are new to software engineering because of the learning curve; it’s very easy to get started. The complexity gap between building basic sites and single page web apps (SPAs) is too big of a leap for many to jump over. Improved tool usability is one of the best ways to bridge that gap while also increasing productivity for those already building complex web apps.

What other improvements do you think are needed in HTML5? Download our research and participate in the discussion.

Categories
APIs

Device API Usage and Trends

In the early stages of new technology markets, a lot of services are created because new technology has made new ways of doing things possible. [tweetable]Where app developers go, apps and then users will follow[/tweetable]. By looking at the popularity of various device APIs across platforms, we can see which developers are making the most of the capabilities their devices offer. If we then look at the device APIs that developers say they plan to adopt, we can see future trends in the app market, possibly months before the apps start to appear. Would it be wise to move against the herd, or is the trend really your friend?

Distinctively mobile computing

Mobile computing devices enable a greater range of applications than their desktop counterparts purely by being mobile. There are also features that are unique to, or much more relevant on mobile devices. In our last survey we asked developers about their plans for and usage of device APIs related to these features to gauge how much different groups of developers are taking advantage of mobility. The device APIs we asked about in our survey were those available to HTML5 developers, which allows us to compare their usage versus native developers across the most popular platforms.

Rather unsurprisingly, it turns out that HTML5 developers make less use of almost all device APIs than native developers. A lot of web developers are targeting desktop as well as mobile platforms and as such are less likely to build functionality that relies on mobile device specific APIs. However, that does seem to be changing as HTML5 developers are among the most likely to say they’re planning to use the majority of device APIs. You can see the popularity of each of the APIs covered in our survey by primary platform in the interactive chart below.

Another point to note about almost all of the APIs surveyed is that a greater proportion of iOS and Android developers use them than for other platforms. This suggests some maturity factor for platforms, either through increased competition causing developers to seek out more mobile-specific niches, or more likely, developers becoming more creative with ways to enhance their apps with mobile features over time.

Peering into the future

The differences between what developers are currently using and what they plan to use allows us a glimpse at future trends. Some of them are obvious, like the increase in intent to use the video camera. Video has long been more engaging for users but making effective use of local capturing and uploading relies on high bandwidth mobile uploads, which 4G connections provide. This trend is already preceded by mainstream services like Twitter’s Vine and video features for Instagram and Pinterest. For web developers, WebRTC offers the promise of easily integrated video chat in any site.

Voice recognition is another area where the trend is expected. The technology is maturing and the platform providers are investing heavily. It’s interesting that Windows Phone has the highest fraction of current usage here and the highest planned usage by a fairly wide margin. Perhaps there is some very effective developer marketing for the relevant APIs going on here?

Other APIs on the rise are less obvious, particularly the increase in interest in proximity sensors – the sensor normally used to detect whether you’ve got the phone held to your ear! It’ll be interesting to see what other creative uses developers put this to, or if it has been mistaken for technologies like NFC and Apple’s iBeacons. Sharing and Pairing is another less obvious candidate – as we didn’t specify exact technology here, it’s safe to say interest in various forms of social sharing from apps is unlikely to decline anytime soon and local sharing options such as Apple’s new AirDrop feature are likely to be popular.

User needs trump technical possibility

Given that Apple and Google (Motorola) have added special hardware for motion sensing, it’s not surprising that there’s a resurgence of interest in this type of API. Lets hope this time we get more creative uses like Magic Plan and not just a lot more motion controlled games and fitness trackers. For those looking where to take their app business, it might not be wise to follow any of these trends. Where lots of developers are exploring (and we do all love to explore new technology) there will be a lot of competition, yet the more general transition to mobile computing is still in the early stages. There are probably much more lucrative opportunities in slightly less exciting corners of the market.

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.