Categories
Business

Developer Economics: Ecosystem wars drawing to a close

Welcome to the brand new Developer Economics report! Now in its fourth year and 6th edition, the latest Developer Economics survey reached over 7,000+ developers across 127 countries, setting new standards in developer research.

DNAapps

Get your free copy here and read about the movers and shakers in the app economy. Dive deep into our rich dataset and discover how developers select and prioritise platforms, which developer tools they use and how their choices translate to revenues.

As always, we have a lot more data available so get in touch (moredata@visionmobile.com) to get the data you need if you can’t find it in the report.

The mobile Developer Mindshare

The latest Developer Economics research shows that 84% of mobile developers are now developing for Android or iOS (or both), the two clear winners in the developer mindshare race. While Android amasses hundreds of millions of new users every year, sales of iDevices are still rising, attracting developers that are more interested in revenues rather than reach.

3b_mobile_mindshare

HTML5 continues to play an important role in mobile development, providing diverse development paths for those developers that want to extend their web skills or web assets onto mobile. [tweetable]37% of developers rely on HTML5 for developing mobile websites and web apps[/tweetable], but more developers use HTML5 to target native platforms via hybrid apps or converted or translated HTML5 code.

Microsoft remains the outsider in the ecosystem battle but has gained some ground in the past few months owing to rising sales of Lumia handsets. Windows Phone still faces a long and thorny road in its quest for mobile mindshare. Meanwhile [tweetable]Windows 8 remained stable at 21% Mobile Developer Mindshare[/tweetable] – the Q4 uplift in Surface sales is likely, however, to generate some developer interest that could push Windows 8 ahead.

Getting your priorities right

Developer Mindshare tells just one side of the story. In a multi-platform race, mindshare is nice to have but what matters most is getting developers to prioritise your platform against the others. This means more, better-quality apps and faster updates, keeping users happy. [tweetable]Android is now the priority platform for 37% of developers, with iOS at 32%[/tweetable].

2_platform_distribution

But there are large variations in developers’ priorities: iOS is still the priority platform in North America and Western Europe, with Android claiming pole position in most of the other regions. There are also significant differences across developer segments: [tweetable]Android is very popular among hobbyist developers who may find the start-up costs somewhat lower[/tweetable], but iOS is preferred by Hunters, who target app-store revenue and Guns-for-Hire, who target development contracts.

HTML5 is prioritised by 14% of developers, although a large number of these developers target Android or iOS via hybrid apps, rather than building true cross-platform apps. With 83% of developers prioritising Android, iOS or HTML5, the other platforms face a mighty challenge: if they are to become key players in mobile, they need to convince iOS or Android developers to switch their priorities. But looking at the revenue distribution for developers across platforms, it becomes clear that that is not a compelling proposition for the majority of developers.

Revenues

We’ve often argued that revenues are not the most important factor for all developers. But at the end of the day, you need to make money, whether that is via app stores, advertising, e-Commerce or any other way you can think of (selling t-shirts to your users or accepting bitcoin donations).

We calculated median revenues to demonstrate the revenue disparity across platforms. The revenues shown in the graph below are the revenues that developers can realistically expect to earn per app per month.

18a_median-revenue

This graph is a picture saying a thousand words and reveals why more than half of the developer population are still investing in a platform that has less than a third of the user reach of Android.

There’s a lot more information on revenues and revenue distribution across platforms in the report, and a lot more graphs and data points that you need to know about if you’re in the app business. We don’t want to spoil the fun so go ahead and download your copy of the report and tell us what you think.

If you don’t find the information you need, then do get in touch at moredata@visionmobile.com to see if we can help.

Follow me on twitter @PappasAndreas

Categories
News and Resources Platforms

The Three Waves Of Mobile Marketing

waves of mobile app marketing

With over one million apps in the Apple and Google stores, you‘d think that app development has become business as usual. As we enter 2014, the making of apps is a sought-after commodity. But [tweetable]the marketing of apps remains part art, part science[/tweetable].

shutterstock_114890851

App marketing and advertising took off early in the history of the app economy. The freemium model (generally speaking, apps that are free but monetize through premium upgrades, in-app purchase items or advertising), took place a couple years after. On the App Store, in-app purchase items (IAPs) were only introduced as of late 2009. On the Google Play Store, they had to wait until 2011.

Since the freemium app model started making a name for itself, the parameters and requirements of app advertising and user acquisition have been in constant evolution, strongly influenced by transformations of the app ecosystems. In particular, app publishers, marketers and other stakeholders have constantly needed to adapt to the evolving policies and barriers enforced by Apple and Google.

In fair consideration, many of the steps the two companies took were also in reaction to the evolution of advertising techniques and practices within their ecosystem. The dynamic is therefore mutual.

Looking back on the brief history of app marketing, there are three main phases or “waves” of app marketing, presented in the table below. Each phases has distinguishing features in terms of business objectives, marketing strategies and practices, technology focus, transparency standards, platform regulations etc.

The three waves of mobile app marketing:

1st wave 2nd wave 3rd wave
Timeframe 2009 – 2011 2012 – present 2013 – present
Goal Volume through top chart position Volume with a focus on the price of installs Volume with a focus on the quality of installs
Marketing strategy Incentivized Downloads Shift to quality: Non-incent ROI-positive media buying
Pricing Methods
  • Flat fee
  • Cost Per Click
  • CPM
 Cost Per Install
  • Cost Per Action
  • Cost per Reengagement
  • adjusted CPI (aCPI)
Technology focus None
  • Install attribution tracking
  • In-app analytics
  • Post-install, in-app event tracking
  • Programmatic buying
  • Deep linking
  • (Cross-device) Retargeting
Tracking technology
  • iTunes Connect
  • UDID matching
  • MAC Address
  • openUDID
  • Fingerprinting
  • Platform-specific device identifier (IDFA, Advertiser ID)
  • Social Media login
Level of platform regulation and transparency Low Medium High
Market dynamics Emergence of new “pure” players Growth, stronger positioning of existing players Consolidation, M&A activity, older players start getting involved
Advertising formats Banners, editorial advertising, incentivized Interstitials, video ads Native ads

I’ll discuss these three waves along their most important characteristics.

The first wave: the early days, focus on volume

The early days of app marketing date back to 2009. They were characterized by the emergence of the Apple App Store as the main platform for user acquisition. [tweetable]Publishers mostly relied on the top chart rankings to gain visibility[/tweetable]. This led many of them to resort to the so-called burst campaigns, either incentivized or natural such as editorial app “boosters” and blogs. These campaigns generated large amounts of downloads in a short period of time in order to climb the app store rankings.

In this context, performance models, whereby advertisers only pay for the installs generated, mostly served for incentivized campaigns, and burst campaigns were often sold on a flat-fee basis. For the burst campaigns run on a Cost Per Install (CPI) basis, downloads were accounted for using iTunes Connect data or at best UDID matching. Consequently, there was neither technology focus nor need in terms of tracking. In short, user acquisition was not data-driven.

During that time, many pure players, such as Tapjoy, Flurry, or AppGratis, entered the space, as it was a land grab with low barriers to entry. Platform regulations were still relatively lenient, as the tenants of the ecosystems didn’t wish to curtail their growth. For instance, incentivized downloads were still allowed by Apple until April 2011.

The second wave: focus on quality and performance tracking

The second wave of app marketing started around 2012. The volume remained the main marketing objective, but CPI-based campaigns gained momentum and performance marketing started becoming widespread. More generally, a discrete shift towards more quality tracking in advertising campaigns was taking place.

In terms of regulation, Apple tightened its grip on a fast-growing ecosystem and cracked down on players accused of taking advantage of the top chart ranking algorithm. In April 2011, incentivized downloads were banned and in October 2012, Apple enacted clause 2.25, forbidding “Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store”. This led to the ban of several of app discovery services, the most famous being App Gratis which was pulled from the Apple’s store in March 2013. App publishers themselves suffered the consequences of these restrictions, such as Animoca who, in January 2012, saw all their apps removed by Apple under the allegation that they were using bot farms to generate fake downloads.

Technology-wise, the growing popularity of performance marketing encouraged the rise of efficient attribution tracking solutions, in order for advertisers to trace downloads down to their respective sources. Among the tracking technologies which then emerged, the most popular are fingerprinting as well as single, platform-specific device identifiers (Google’s Advertiser ID and Apple’s Identifier For Advertisers – IDFA). As of today, [tweetable]fingerprinting remains the only legitimate solution enabling mobile web tracking[/tweetable].

Publishers also started becoming more data driven by integrating in-app analytics solutions such as Localytics to analyze usage, retention, engagement, virality and monetization metrics. Similarly, a focus grew on measuring the quality of the users through the estimation of customer lifetime value (LTV). However, this was at this time mostly performed to understand the user journey and improve the user experience, not yet (so much) to optimize user acquisition campaigns. In other words, [tweetable]performance stopped at the install, as in-app and attribution tracking remained distinct from each other[/tweetable].

In terms of market dynamics, the wave of new entrants stalled as existing advertising players consolidated their positions and stronger regulations prevented the use of shadier advertising tactics. The second wave was pioneered by ad networks (inmobi, AdMob, Leadbolt), affiliate and cross-promotion networks (AppFlood, Chartboost, AppLift), mobile agencies (Fiksu, Somo Global).

The third wave: focus on lifetime value and ROI

The third wave of app marketing started in 2013, is currently unfolding and will probably define the mobile landscape for at least the next two years. This third wave is distinguished by a massive shift towards quality, with, in particular, the growing realization by mobile advertisers that acquiring users, even at a low price, makes no sense if these users are not retained, engaged and finally monetized.

This global shift to quality has generally been embraced by advertising companies, app publishers and platforms alike, all with various consequences.

First, platforms themselves are taking on and driving the trend, and introducing heightened regulation. In 2013, Apple modified its ranking algorithm to take into account more in-app, post-install qualitative factors such as retention and engagement metrics. Google, too, started enforcing harder restrictions on its developer policies when it banned spammy user acquisition techniques such as push notifications or icon drops on the Play Store.

Naturally, it is app publishers and advertisers that are driving the largest part of the shift. Indeed, increased competition as well as rising CPI prices has made it an impediment to track and optimize user acquisition campaigns more accurately, and to allocate marketing budgets towards the best-performing channels. Technically, this means tracking post-install events, connecting them to the acquisition source, and finally linking attribution tracking to in-app metrics.

Early assessment of the LTV of acquired users now enables advertisers to quickly assess the quality of the various acquisition channels used. This in turn allows them to optimize and fine-tune the campaigns by allocating budgets to the traffic channels offering the highest user quality (users whose LTV is higher than their cost of acquisition – CPI).

On the whole, if the first wave focused on volume only and the second on price-weighted volume, the third wave is characterized by quality-filtered volume.

In the wake of this quality shift, new pricing schemes appeared: for instance, [tweetable]Cost Per Engagement (CPE) now allows advertisers to pay for actions taking place after the install[/tweetable], such as game tutorial completions, or first purchase.

More quality and more regulation also go along more trust and transparency. In the specific context of the relationship between advertisers and user acquisition networks and other partners, this means that networks have been more willing to share information about their traffic sources, while advertisers have been less reluctant to share more in-app data about the users generated.

In terms of market dynamics, the third wave is characterized by increased M&A acquisitions as older, established digital and online companies start acquiring pure mobile players. This way, in 2013 we saw, among others, retargeting company Criteo buy out mobile tracking company AD-X, Twitter snap up mobile ad exchange MoPub and, in gaming, Japanese telecoms firm Softbank together with GungHo acquire Finnish mobile game publisher Supercell. There were also a couple of mobile-only deals, such as the acquisition of Jumptap by Millennial Media or the merger of mobile gaming services company Playhaven with mobile analytics provider Kontagent.

As the third wave of app marketing is still forming, other data-driven approaches are emerging, such as real time bidding, retargeting and cross-device targeting. Reactivation and re-engagement campaign techniques are already taking into account quality factors and focusing on post-install events.

For developers, it can be of great help to keep this history of paid mobile user acquisition in the rear-view mirror as they strive to understand and adapt to its new challenges.

– Thomas

[Thomas heads up content marketing at AppLift, loves scrutinizing the developments of the mobile industry and collects photo apps on his iPhone the rest of the time. He can be contacted at tso@applift.com]

Categories
Business Platforms

Mobile Gaming And The Pyramid Of Scarcities

pyramid of scarcities

Distimo - App Revenue Distribution

According to Distimo’s latest report, apps with “freemium” business models, i.e. free apps monetized by in-app purchases (IAP), have dominated revenue charts in 2013. This spurred me to take a deeper look at the “economics of free” and explore new opportunities for innovation in these business models.

The Economics of Free

Let’s begin by taking a brief look at the “Economics of Free” or the “Economics of Abundance”, as described by Mike Masnick. Here’s a short, 2 minute video introducing the concept:

Economics is essentially a social science that examines the best possible way to allocate “scarce” goods or resources, i.e. ones with meaningful marginal cost and limited supply. However, digital goods like apps are abundant because the marginal cost of creating an additional copy is zero. Given the nature of near-efficient competition in the digital world, price naturally approaches the marginal cost of zero.

This explains the decline in popularity of paid app downloads and the decline of numerous traditional business models. However, cheap or free content allows developers to reach a much wider audience which consequently increases demand for related scarce goods or resources. In the music industry, the advent of digital music precipitated a steep decline in US recorded music sales from $14.6 billion in 1999 to just $6.3 billion in 2009, but concert ticket sales grew from $1.5 billion to $4.6 billion over the same timeframe. In other words, digital music converted a scarce resource (recorded music albums) into an abundant resource (cheap, easily downloadable singles), which then increased demand for a related scarce resource, i.e. concert tickets.

  1. Marginal Cost – Cost of producing an additional unit
  2. Efficient Competition – Participants do not have the market power to set prices

The Pyramid of Scarcities

This particular study focuses on scarcity-driven monetization opportunities available to developers of free-to-play (F2P) games like Candy Crush Saga, Angry Birds, etc. As shown in the image below, the scarcities created by F2P games can be segregated into 3 categories, in order of increasing scarcity (or decreasing availability)

  1. Induced Scarcity
  2. Scarcity of Goods
  3. Scarcity of Time or Access

Pyramid of Scarcities

1. Induced Scarcity

Induced scarcity is one that does not exist in reality, but is created artificially — for example, in-app purchases of digital goods. The availability of these goods isn’t really in question and therefore, the value placed on each purchase or transaction is quite low. Consequently, effective monetization depends on maximizing transaction volume from these low-value digital goods, i.e. micro transactions. This strategy is most effective when scarcity is induced because of direct player engagement, and not when it is forced onto players. Game design plays a critical role here as in-app purchases need to be naturally blended into gameplay elements. King’s games like Candy Crush Saga are perfect examples as players pay for boosters to help them progress through difficult levels. In fact, King’s revenue is expected to top $1 billion this year, almost exclusively driven by micro transactions on Facebook and mobile games.

However, exclusive use of this monetization strategy also brings up some challenges. King’s “Games Guru”, Tommy Palm, recently said that 70% of the players on Candy Crush Saga’s final level “haven’t paid anything”. While this is a great sign for consumers, King seems to be losing out on monetizing their most engaged players and biggest fans (excluding a minority population of “whales”). The only reason these players haven’t become paying customers is because they don’t consider digital goods to be scarce enough. The solution isn’t to create “paywall” equivalents, but to explore additional monetization opportunities with even scarcer products.

2. Scarcity of Goods

Scarcity of goods refers to physical products that have a tie-in with an F2P game — for example, branded or licensed merchandise. Since physical goods aren’t as abundant as digital ones, the value placed on each transaction is automatically higher. However, this comes with the trade-off of lower transaction volume. Rovio’s Angry Birds franchise is a great example of a successful merchandising strategy. Led by sales of Angry Birds plush toys, merchandising and IP sales made up 45% of Rovio’s $195 million revenue in 2012. This year, Hasbro sold over one million “Telepod” figures within a month of Angry Birds Star Wars II’s launch. This year, King also dipped its toe into merchandising with a range of Candy Crush themed candies and socks.

These products are likely to appeal to fans of F2P games even if they have never purchased digital goods. However, the biggest fans and most engaged players may be looking for something even scarcer.

3. Scarcity of Time or Access

Scarcity of time or access can be leveraged through a direct connection with the most ardent fans — for example, events like gaming competitions or conventions. Conventions tap into scarcity of time from key personnel like game designers, while social gaming competitions tap into scarcity of access to exclusive benefits and direct competition with other “superfans”. The monetization opportunity from events is likely to be immense, even though the actual frequency may be low.

So far, very few game developers have utilized this particular strategy — a related example from the non-F2P space is Mojang’s Minecraft Convention or MineCon. 7,500 tickets to the event sold out in roughly 5 minutes, generating roughly $1 million in revenue. This may seem like small change for large gaming companies, but it’s important to keep in mind that Mojang may view MineCon as more of a promotional event. Expanded ticket sales and advertising partnerships could easily make gaming events a significant revenue opportunity. Given the competition in allied industries like mobile hardware, there will certainly be no dearth of advertisers.

Opportunity for Innovation

The monetization opportunities outlined in this post show that the free-to-play mobile gaming industry still has a lot of room for growth. Most publishers have focused on just one of these strategies and I have no doubt that we will see more business model innovation from these companies as we move forward.

Having said this, these strategies are only useful for companies if their games remain popular. The gaming industry has proved again and again that companies cannot rest on the laurels of a single mega-hit. Therefore, developers need to focus on continuous innovation across a wide catalog of games. What’s most important is to ensure that players have fun. After all, isn’t that the entire point of playing games?

– Sameer

This post was originally posted in Sameer’s Tech-Thoughts blog – you can find the original article here.

Sameer is a business strategy professional with expertise in mobile ecosystems, asymmetric business models and disruptive innovation. Over the last 6 years, he has held various roles in strategy consulting, investment management, M&A and venture capital. During this time, he has developed a keen interest in the intersection between technology, innovation and business strategy. You can follow his work on his blog at Tech-Thoughts, on Twitter @sameer_singh17 or on LinkedIn.

Categories
Business

The Android Monetisation Myth: iOS still rules the west

[tweetable]Revenues from Android apps saw tremendous growth in 2013[/tweetable]. If you look at the headline global figures then revenues from Android apps on Google Play are rapidly closing on those from iOS apps on the App Store. It looks extremely likely that 2014 is the year that Android will overtake iOS in total app revenues. However, dig a little deeper and you’ll find the distribution of revenues, both geographically and across apps is rather different. If you’re planning your platform strategy for this year then a dive into the details might prove invaluable.

Almost a year ago, I wrote about two important app market trends to watch in 2013, which were continued growth of app revenues (they’re still growing, Android significantly faster than iOS) and revenue distribution (it’s getting even more concentrated at the top). According to Distimo:

“On a typical day in November 2013, we estimate the global revenues for the top 200 grossing apps in the Apple App Store at over $18M. For Google Play, our estimate is about $12M. In November 2012, these estimates were at $15M for the Apple App Store and only at $3.5M for Google Play.”

That’s 20% annual growth at the top of the market for iOS and just over 240% annual growth for Android. Add to that there are also alternate stores for Android that have been growing revenues too. These figures and relative growth rates make it seem as if Android is the place to be in 2014. It might be, if you can make it to the very top. If we look at AppAnnie’s report for a similar period, they estimate that total iOS App Store revenues roughly doubled year over year*, while total Google Play revenues were a bit more than triple their year ago levels. So although Apple seems to be improving the revenue distribution slightly, it’s getting even more concentrated at the top of the market on Android.

Even the wider distribution of revenues on iOS may not be quite as good as it looks when we also consider geographic spread. Although the US is still the top revenue earner for iOS, the bulk of the growth is in Asia, particularly China and Japan. The top grossing charts in these countries look very different from the global top grossing apps and this may account for much of the widening range of high revenue apps. [tweetable]On Android, the bulk of the growth and total revenue is in Asia and thus so are the top grossing apps[/tweetable]. Japan has overtaken the US as the top revenue earning country for apps overall mostly due to growth on Android. The vast majority of the increased revenue is in free-to-play games and App Annie’s report shows that in Japan, almost all of this was attributable to just five publishers. Two of those publishers were existing major games powerhouses before the mobile era and they have several well known franchises. Two more reached the kind of scale where TV advertising became a viable route to market and exploded from there. The last of the five is LINE, who built a messaging platform with over 300 million users as a channel to promote their games.

This concentration of revenues amongst five publishers in Japan is mirrored elsewhere in the world. Consider Supercell (makers of Clash of Clans and Hay Day) were at $2.4M per day in revenues in April 2013, when they were still only publishing on iOS (they’ve since launched on Android) and were in the middle of expanding through Asia. That’s more than 10% of daily global App Store revenues for the top 200 grossing apps made by one publisher with 2 apps. Supercell aren’t unique either – according to Think Gaming’s estimates, King.com’s Candy Crush Saga is making more than $900k per day, just on iOS in the US. Indeed Think Gaming give us a better idea of the distribution. Their estimates show that the number 10 grossing game makes only a 10th as much as the top grossing game and by number 100 you’re down to nearly 100th of the revenue.

So, with revenue concentration at the top of the charts on Android even greater than on iOS, Android is the platform to target if you’ve got a world beating app with global appeal on your hands. Otherwise you’re almost certainly still better off on iOS first. Our own data, which considers revenue sources outside the app stores as well, agrees with this. If we only include the publishers earning less than $5M per month then iOS comes out on top, although if we include everyone with non-zero revenues then Android sneaks ahead. Significantly higher revenues for a tiny number of top Android developers pushes the average ahead of iOS (although the median remains way behind – there were more iOS than Android developers earning >$5M per month in our survey).

Android may become the top earning platform from App Stores in 2014 but it seems that only an elite few developers will reap the rewards. We’ve already shown that building enterprise apps and avoiding the app stores is a better bet financially but Android is not currently a lucrative platform in the enterprise market either. Still, it’s not all bad news for Android developers – the rising tide of revenues will lift all boats to some degree. Also, even 2014’s cheap Android device should be running at least Android 4.0 and have hardware capable of running almost any app well. This should reduce costs and increase the real addressable market for all Android developers. Last but not least, for an increasing number of developers [tweetable]it’s not a question of Android or iOS, it’s becoming ever more important to target both[/tweetable].

* Distimo’s year was November to November, while App Annie’s was October to October, so there may be some impacts from the relative timing of new product introductions.

Categories
Tools

The Ins & Outs of Mobile App Testing

Over the last decade, application testing has continually proved itself to be an important concern. When done well, testing can drastically reduce the number of bugs that make it into your release code (and thus actually affect your users). In addition, good testing approaches will help your team catch bugs earlier in the development lifecycle – resulting in a savings of both time and money (not to mention reputation with your users). Code that has good test coverage enables you and your team to make changes and introduce new features to your app without the fear of it breaking existing functionality.

shutterstock_131210207

The word “Testing” is a large umbrella, and is usually better understood when you break it down to specific types of testing. For example:

  • Unit Testing – automated tests written by developers, with each test targeting a narrow slice of application behavior.
  • Functional & Acceptance Testing – typically performed by QA personnel or automated UI testing frameworks.
  • Performance Testing – often performed manually with profiling tools (for example – heap and CPU profiling tools), though many mobile app developers are moving towards integrating app analytics to gather this data from real usage as well.

That’s certainly not an exhaustive list of the types of testing, but enough to make an important point: [tweetable]mobile applications face several challenges when it comes to testing[/tweetable]. Key among those challenges are:

  • Platform & Device Diversity
  • Immature Tooling
  • Lack of Awareness

If you opt to write native applications for each target platform, then any code-level testing (i.e. – Unit Tests) will not be transportable as you move from Objective-C (iOS) to Java (Android). In addition, any scripted UI-Automation testing tools may not work for multiple platforms (or at the very least require separate scripts for each platform). Hybrid solutions like PhoneGap, or cross-compiled solutions like Xamarin can offer a single approach to unit testing (given a single codebase for multiple platforms) – but do not always offer the same level of quality as native tooling when it comes to performance profiling. Despite the trade offs involved, I’ve found in my own experience that [tweetable]the biggest barrier to entry in mobile app testing is often a lack of awareness of what tools are available[/tweetable]. That is the barrier which I hope to address in this post.

Unit Testing

Unit testing for specific platforms or cross-platform tools is not difficult, and your options abound. Let’s look at a sample of some of these choices.

iOS

iOS developers who’ve been writing Objective-C for a while may be familiar with OCUnit, which shipped with XCode prior to the XCTest framework. It’s still supported in XCode 5, but the understanding is that new and future projects should focus on using XCTest.

Don’t let Apple’s sparse documentation on unit testing deter you from checking out the XCTest framework. If you’re running an OS X Server, you can also take advantage of the XCode service’s continuous integration features. As part of a continuous integration workflow, you can create “bots”, which can continually build and test your app.

Many developers prefer a Behavior-Driven-Development (BDD) style syntax for unit testing. If this describes you, be sure to check out Kiwi – a BDD style unit testing framework for iOS.

One other important mention is OCMock a mocking framework for iOS. Mocks are an indispensable part of writing adequate tests around your application’s behavior.

Android

JUnit is perhaps by far the most well known (and officially recommended by Google) testing framework for Android. The JUnit Android extensions allow you to mock Android components, but I’ve also seen quite a number of Android developers use JUnit with Mockito, another Android mocking framework.

Robolectric takes a different – and very interesting – approach by allowing you to run your Android unit tests in the normal JVM (Java Virtual Machine), without the need for an emulator. This enables your tests to not only run from within your IDE, but also as part of a continuous integration workflow.

Qt

Qt made the top 5 most used CPTs in 2013. If you’re building mobile applications with Qt, you’ll be happy to know about QTestLib, a unit testing framework built by Nokia. Based on my research, it appears that QTestLib can be integrated with a 3rd party continuous integration workflow – enabling very helpful testing automation.

PhoneGap/Apache Cordova

Web-based hybrid approaches to mobile apps can take advantage of a host of testing and mocking frameworks, not to mention scripted UI/acceptance testing tools as well (more on that in a moment). When it comes to unit testing JavaScript, three of the biggest names are QUnit, Mocha and Jasmine. I’ve personally used all three, with my favorite setup including Mocha and expect.js (which provides a BDD style test syntax). Mocking and “spy” frameworks abound in JavaScript as well, with Sinon.js and JsMockito among the more popular stand-alone mocking options.

Many PhoneGap developers take advantage of tools like PhantomJS – which is a “headless” (no UI) WebKit browser, with a JavaScript API. PhantomJS can be easily integrated into a continuous integration workflow to automatically run unit tests against your hybrid mobile application’s codebase.

Xamarin

Xamarin uses a customized version of NUnit (ported from JUnit), called NUnitLite which enables you to write unit tests against your Xamarin iOS & Android projects. For any shared codebase, you can use the unit testing framework of your choice.

Scripted UI Testing

Not every team can afford to hire an army of manual QA testers, despite how valuable that can be. Automated tooling can bridge the gap.

If you’re writing native iOS and Android apps, you’re in luck. Apple provides an “Automation instrument” that will automate UI tests against your iOS mobile application. The Android SDK provides the “uiautomator” library, described as “A Java library containing APIs to create customized functional UI tests, and an execution engine to automate and run the tests.” In addition to these, you can use third party tools like Squish, Ranorex and Perfecto Mobile’s MobileCloud Automation to automate UI tests against Android and iOS apps, web apps and more. It’s worth mentioning that Perfecto Mobile’s MobileCloud Automation exposes an API to better facilitate integration with existing build/continuous integration tools. Perfecto Mobile also offers MobileCloud Interactive, which enables you to “perform remote manual testing on real smartphones and tablets regardless of where you are” – who wouldn’t want to have a “testing army” of real mobile device users at their disposal?

Among the more interesting developments in mobile UI automated testing is the emergence of an open source project named Appium. Appium uses the WebDriver JsonWireProtocol to interact with iOS, Android and Firefox OS apps and gives you the choice of writing your UI tests in any WebDriver-compatible language (Java, Objective-C, JavaScript, PHP, Python, Ruby, C#, Clojure, Perl and others).

Performance & Profiling

Apple’s Instruments is one of the more impressive native toolsets I’ve seen recently. With Instruments, it’s possible to profile how your app executes, run stress tests, record and replay user actions, create custom instruments and a lot more. If you’re writing native iOS apps & not using Instruments, I recommend reading through the Quick Start to get up to speed.

With Android apps, you have several (albeit, lower-level) tools available: Systrace & Traceview. You can also use the Device Monitor to view memory usage based on logcat messages.

For hybrid mobile apps, you have a host of mature desktop browser tools (Chrome Developer Tools, Firefox/Firebug, etc.), which you can bring to bear on your app to profile CPU usage, memory, DOM manipulation and much more.

Many mobile developers have started taking advantage of third party analytics services such as Google Mobile Analytics, Countly, EQATEC, Flurry, Perfecto Mobile’s MobileCloud Monitoring and many others. The focus of these kind of analytics is usually more about how your app is actually used, user engagement, demographics, feature popularity, etc. However, it provides an opportunity to measure certain pieces of application performance from within real-world usage. While I wouldn’t recommend this being your first line-of-defense in performance testing, having the ability to track real world performance metrics can be a powerful tool in tuning your application to your users’ needs.

We’ve only scratched the surface of the various testing options available for mobile app development. What testing approaches & tools are you using when writing mobile apps? If you’re not currently testing your application, what are some factors that would change your mind?

– Jim (ifandelse)

Categories
Business

4 Reasons Not to Build Enterprise Apps

In an earlier post we showed how enterprise app developers make 4 times the revenue of those developing consumer apps on average. Targeting enterprises with apps can be very different from building consumer apps and not all developers prioritise revenue, so it’s not for everyone.

chapter1

Do you want the indie developer lifestyle, or to build a company? What sort of contact do you want to have with your customers? Do you like consulting work or do you prefer to build your own products full time? Do you have a strong development platform preference? Depending on your answers to these questions you might find one of the 4 reasons below keeps you focused on consumer apps for the foreseeable future.

1. You like to work alone

The creation of the app stores enabled vast numbers of individual developers to create and monetise their own apps. Amongst the revenue earning developers targeting consumers, almost 43 percent are in one person companies and practically all of those don’t involve anyone else in development. Of the developers building apps for enterprises, only 13.3 percent are in one person companies and those are almost exclusively doing contract work. The one person enterprise development companies earn 24% more revenue than the equivalents building consumer apps but it’s definitely not the independent developer lifestyle they’re living. In general the enterprise developers earn more than those developing for consumers at every team and company size, with the difference increasing with team size up to the 500 employee mark. Above that revenues from app development per person drop significantly, although on both sides a lot of large companies developing primarily for reasons other than earning revenue are included here.

2. Direct sales repels you

As you can see from the charts above, enterprise app developers tend to work in larger companies than those targeting consumers. There’s also a bigger company size to team size ratio. The difference here is likely to be sales, marketing and support teams. In general, larger customers need more direct contact. In the consumer apps space it’s possible, although unlikely to be successful, to launch an app and sell it without ever having contact with anyone that uses it. However, although the costs of direct sales staff may seem high, consumer apps with large revenues and user bases typically pay to acquire a decent fraction of users (e.g. via in-app ads, Facebook app install ads, cross-promotion networks). We don’t have any data to compare the cost of sales for these developers but I wouldn’t bet that the average cost of sales as a fraction of revenue for the successful consumer app developers was significantly lower.

Whilst subscription revenue is by far the best earner for consumer app developers, it is one of the worst revenue models for enterprise developers. In the enterprise market per user/device licensing and other sales outside of app stores is a key revenue component for most successful businesses. This aspect of a business can often be very unattractive to developers.

3. You want complete creative control

On average [tweetable]enterprise app developers earn a much greater fraction of their revenue from contract work[/tweetable] (consulting). The most successful enterprise app businesses earn 25-75% of their revenue in this way (we only have 25% bands). It’s likely that there’s a lot of custom integration work involved in selling to larger enterprises. Even those selling to SMEs often offer customizations.

Developers who consider their apps an art-form and build them primarily to earn a living doing something creative they love will probably want to stay away from areas where a lot of contract work is involved. Those same developers are also not very likely to be inspired to help automate business processes or other similarly mundane but useful enterprise app functions.

4. You love Android development

There are some very major differences in the revenue models and revenues of enterprise app developers depending on their primary platform. The really big revenues are currently being earned by HTML5 developers (> $100k per developer per month). Next highest revenues are for iOS developers (a little over $50k per developer per month) but it seems that [tweetable]a lot of iOS app enterprise development is currently outsourced[/tweetable], since more than 70% of these earn >75% of their revenue from contract work and 40% earn 100% of their revenue in that way.

Compared to these two, the Android developers are the poor cousins. Despite having a much wider range of revenue models, their average revenue per developer is much lower (about $14k per month). Enterprise development still pays very slightly better on Android than building consumer apps but given the other trade-offs discussed above, it might seem like a relatively poor deal.

Running out of excuses?

When we published the last article, showing that enterprise developers make 4 times as much revenue as those targeting consumers, a lot of responses suggested that this difference was all in the large enterprise sales market and required large direct sales teams. While there is definitely some advantage to scale, this is certainly not the case. Not all enterprises are large and there’s a very big market of SMEs looking for mobile software to make their businesses more efficient or convenient. Although the most profitable enterprise app development companies are in the 51-500 employee range and solo developers are only marginally better off targeting enterprises, a 2-5 person company makes more than 4 times as much revenue on average by choosing to build enterprise apps. The 2-5 person enterprise app business is much more likely to be building HTML5 hybrid wrapper apps rather than the native iOS or Android apps of a similar sized consumer focussed business. They are also likely to be spending more of their time (although far from all of it) doing contract work. If neither of those things bothers you then it might still be worth considering the enterprise market for your next app.

Categories
Business

Why are you still building consumer apps? Enterprise pays 4x more!

Consumer apps are the focus for all the excitement and media attention in the industry. Enterprise software is dull and boring, right? Not if you care about making money! Our data shows [tweetable]enterprise developers generate 4 times as much revenue as those targeting consumers[/tweetable]. Besides, what’s so dreary about reinventing the way people work in a mobile and connected world?

Print

“Wait”, I hear you cry, “what about BYOD and the consumerization of IT? Surely the future is all about selling computing tools directly to professionals?” Well the data from our April-May 2013 Developer Economics survey says that future isn’t here yet. In any case, if you’re going to collaborate with colleagues then you all need to be using the same tools, so most of the time the company still has to choose and buy them.

We asked developers which type of customer they primarily targeted from a selection of Consumers, Professionals, Enterprises, Other and Not Sure. Using this data we can compare the fortunes of developers serving each of those audiences.

It’s entirely natural that a new consumer-focussed computing market for smartphones and tablets spawned a large industry of consumer focussed app development organisations. The market is rapidly maturing now, with smartphone penetration above 50% in all developed markets and tablet adoption not far behind, yet still almost 75% of companies involved in app development are focussed on consumer apps. Traditionally software spending has been much higher in enterprises and although there is a shift towards employees selecting their own technology and tools it is surely not happening as fast as the shift to mobile computing. This leaves a gap in the market for developers focussed on apps for the mobile enterprise to fill.

A little over 12% of the money-making developers in our survey were targeting the enterprise yet they made on average almost 4 times as much revenue (per person involved in development) as those targeting consumers and typically had more than 4 times as many people involved in app development. Developers targeting professional users rather than their companies only made about 50% more revenue per person than consumer focussed developers and had about twice as many people involved in development. So, while this is a promising market, [tweetable]independent app developers are not replacing the enterprise IT department just yet[/tweetable].

At the bottom of the revenue pile it’s no big shock to see that developers who aren’t sure about their target market make by far the least money. How do you build a great product without knowing who it’s for? The small number of respondents who felt their audience didn’t fit one of our categories, selecting “Other”, may possibly be targeting too small a niche since their revenues are not far above half those of developers building consumer apps.

It’s important not to get confused by the similarity of the increased development team size and higher revenue figures – the chart shows revenue per person, so the effect multiplies. That is, the average enterprise focussed app development organisation is making around 16 times as much revenue as the average consumer focussed one in total. That makes the total revenues of the enterprise developers significantly greater than those of the consumer developers, even though there are around 6 times as many of the latter. Averages hide a lot of detail though. You don’t have to build a large company to be extremely profitable in the enterprise mobility market – smaller development teams actually have much higher revenues per developer. More details on that and important differences between consumer and enterprise app developers will be the subject of a future post.

Agree with our figures or disagree? Drop us a comment.

– Mark (@__MarkW__ )

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.