Developer Nation Blog

App Stores Growth Accelerates in 2014

Post author By Ariel Michaeli
Post date January 26, 2015
No Comments on App Stores Growth Accelerates in 2014

2014 was quite an eventful year in our industry. Apple finally gave in to the big screen but also teased us with the small screen of the upcoming Apple Watch, and even surprised developers with Swift. Google wasn’t quiet either, revealing their vision for the future of UI with Material design and tackling wearables head-on. To celebrate such a great year, we’ll be taking a look at app store growth in 2014.

In this report we’ll be exploring the growth of each of these stores in 2014, but let’s start by establishing a baseline of how big each of the stores are, in number of apps, and how they got to where they are today.

Looking at the chart above we can see all three stores really expanded their app catalog. It’s the kind of healthy growth you’d expect from an industry that’s still relatively new. The most obvious takeaway here, however, is that Google finally closed the gap and actually jumped ahead of Apple, ending the year with more than 1.43 million apps compared to 1.21 million. Amazon, although a distant third, grew its catalog by nearly 90% to 293k apps.

Google surpassed Apple for number of new apps for the first time in 2014

Looking at the number of app developers who publish apps for the different stores, we see a familiar picture. Google Play’s developer community grew tremendously in 2014, exceeding Apple for the 3rd year in a row. In fact, [tweetable]Google Play is distributing apps from nearly 400k different developers[/tweetable]. This is a much higher number than what we observed in last summer’s report on app developers, meaning the Play store saw rapid growth in the last two quarters of the year.

Google’s developer community continues to grow faster than Apple’s for the 3rd year in a row

More apps than ever!

App development is certainly on the rise and the platform doesn’t seem to matter. [tweetable]In 2014, all three app stores grew by at least 50%[/tweetable] (by the way, when we say growth we mean the percent change from the end of the previous year). What’s interesting is that although Apple continues to grow strongly, it’s really Google Play that’s growing. In 2014, the number of apps distributed through Google Play has doubled. Amazon is also enjoying impressive growth, albeit from a much smaller base.

[tweetable]Google Play more than doubled in number of apps in 2014[/tweetable]

We initially only set out to look at aggregate growth, but with so much data at hand, we just couldn’t stop. So TL;DR Let’s have a look at the top 5 categories with most growth during 2014:

We expected to see Business and Games rank very high as both are fairly mainstream, but Food & Drink, with the second largest growth, was certainly a surprise. Keep in mind, for the comparison to be apples to apples, these charts look at growth and not total size.

More than 128k new Business apps were released in the iOS App Store in 2014

On Google Play, Games are in abundance with the category more than doubling in size. Interestingly enough, although tiny in comparison, the Photography category saw abnormal growth in 2014. Selfie Stick anyone?

Developers. Developers. Developers.

This is surely amazing growth, but are those new apps being published by new developers, or is the catalyst for this massive increase in apps a result of incumbents expanding? You’re about to find out.

More developers joined Google in 2014 than Apple and Amazon combined! With developers flocking to Google Play, the store has reached a new milestone: 388k developers — more developers than Apple (with 282k developers) and Amazon (with 48k developers).

More developers released apps for Google in 2014 than Apple and Amazon combined!

Let’s break this down by categories:

We can see the relationship here between app growth and new developers, with most new Apple developers publishing business apps. What’s interesting is how games started off slow and sped up around March, catching up with the steadily growing lifestyle category. It’s no surprise that Apple developers, much like their Google counterparts, are focusing on mainstream apps.

The amazing growth in games we mentioned earlier correlates directly to developers. The category saw the highest number of new developers, more than the business and entertainment categories that are tied for second place.

Most new Google developers focus on games, Google Play’s fastest growing category

There you have it, a whole year of amazing growth by the numbers.

[tweetable]2014 was certainly the year for Google Play growth[/tweetable]. Kudos to the teams who run the store and help developers! With the most apps and largest developer community, Google Play is starting the new year with a kick. Market fragmentation and varying device capabilities don’t seem to detract developers from making Android apps. But, with the upcoming Apple Watch, Swift, and a larger screen, Apple is giving developers a lot to be excited about.

Tags amazon app store, app growth, app store, Google Play, ios app store

Tools

Go ahead and add that extra ad library, but be careful about which one you add

Post author By Meiyappan Nagappan
Post date January 20, 2015
No Comments on Go ahead and add that extra ad library, but be careful about which one you add

In our case study we started with a set of 236,245 free to download Android apps from the Google Play store mined in 2011. Overall we found that the apps connected to 72 different ad networks through the respective libraries. In all there were three key findings in our study:

Finding 1: Developers integrated more than one ad library quite frequently.

Fig 1. Number of apps (y-axis) that have a particular number of ad libraries (x-axis).

We find that most apps have only one ad library in them. However, at least 42,206 of the apps with ad libraries in them have two or more ad libraries. Fig. 1 shows a breakdown of the number of apps based on the number of ad libraries integrated in the apps. We even find eight apps with as much as 28 ad libraries!!

Finding 2: We found no evidence of a relationship between the number of ad libraries and the user rating of an app.

Fig 2. Bean plot of apps with a specific number of ad libraries and their user rating. The long dotted line and the line across each beanplot represent the median rating of all the apps and the median rating of the apps that integrate a particular number of ad libraries, respectively.

In Fig. 2 we break down the data and show more details by means of a bean plot of the rating of apps grouped by the number of integrated ad libraries. Bean plots show both the median value for the rating (indicated by the solid horizontal line), and the actual distribution (the width of the curve at any point in each bean plot indicates the number of apps with a particular rating). Since app ratings can be biased by a few raters, in the above Figure and the rest of the study, we filtered out apps with less than 10 raters and fewer than 2 releases in an entire year (unmaintained apps), which resulted in a set of 13,983 versions distributed across 5,937 different apps.

The Spearman rank correlation (correlation among the relative ranks rather than the actual values) between the number of ad libraries integrated in an app and the rating of the app is 0.016. Such a weak correlation illustrates that there is no relationship between the number of ad libraries in an app and the rating of the app.

Finding 3: Apps that integrated certain specific ad libraries had a noticeably lower ratings.

Fig 3. Bean plot of apps that integrate a specific ad library and their user rating. The long dotted line and the line across each beanplot represent the median rating of all the apps and the median rating of the apps that integrate a particular ad library, respectively.

We observe that ad libraries with a highly intrusive behaviour result in complaints from app users, and in some occasions ruin the users’ perceived quality of the app. We find comments such as: “Good game, bad ads. I was loving the game until I noticed it put a new shortcut called ‘Apps’ on my launcher. Sorry, but if your idea of advertising is putting sh*t in launcher pages or notifications then I’m not interested. Keep ads INSIDE the app.”. At the time of our study, apps that included Wooboo, Leadbolt and Airpush all had lower ratings. We found that these ad libraries had an intrusive behaviour (as explained in more detail in our paper). Recently, Google Play updated its policies to encourage the app developers to be more conscious with ad libraries that have highly intrusive behaviour. They also updated their ad policy in mobile apps which has forced ad libraries to either change or risk not being included.

Recommendation

Given a certain real estate space that the ads will occupy on the screen of a device (control variable), app developers can add as many ad libraries as needed to increase the fill rate (ratio of number of ads received to the number of ads requested) without impacting their ratings. However, developers need to be careful and selective about the specific ad libraries that they integrate.

You can find more details about the case study in our paper published in the Nov-Dec 2014 issue of IEEE Software. (Preprint)

Tags ad networks, app ratings

Tools

Are prototyping tools becoming essential?

Post author By Mark Wilcox
Post date January 13, 2015
No Comments on Are prototyping tools becoming essential?

How do you design the UI for a new app or feature? Good old fashioned pencil and paper? Photoshop or Sketch? Perhaps a wireframing tool like Balsamiq? Maybe you build clickable mockups or fully interactive prototypes? However you go about it, using prototyping tools to get some feedback on a design before it’s fully coded is a great way to save time and effort.

When building an app for a client, they’re usually a lot happier if they can see and touch what they’ll be getting before it’s built. For your own apps, being able to rapidly iterate on the design with prototypes can get you to market with a quality product much faster. There’s been a lot of activity in the prototyping tools space over the last year or two, providing a variety of ways to build brilliant prototypes. In this post we’ll look at some of the most interesting and promising ones.

Animation era

In iOS 7 Apple made a major change to their UI design. The old realistic textures and skeuomorphic design elements were out and flatter, cleaner look was in. Many of the hints at what interface elements were for, or affordances in designer-speak, are now gone – replaced by animations that make it clear what’s happening as you start to interact with the interface. This arguably makes it harder for complete beginners to discover functionality but also makes it easier to understand what’s happening and how apps work. Well designed animations can delight and surprise, making the whole experience more engaging. The danger here is that developers building custom UIs in a similar style can mimic the look of the new UI without adding the animations. This effectively takes away almost everything that helps a user learn how to interact with the app. [tweetable]Animation became essential to a good UI design[/tweetable]. At the time there were almost no tools for designers to help them create or communicate this aspect of the user experience – developers largely had to add these animations in code and tweak parameters across many slow and painful iterations to get them right.

In the Android 5.0 update last year, Google has also adopted a much more minimalist UI style – they’ve called it Material Design. Here also, animation is a core part of the user experience; this is made very explicit in their design guide. Fortunately we’re now in a much better place in terms of tooling to design and prototype these animations. Which tools you’ll want to use is likely to depend on your current process, what sort of app you’re building and what level of fidelity you want to achieve in the prototype.

Exploring ideas

If you primarily want to create a prototype to explore an app idea or communicate about one, then it’s hard to beat the efficiency of pencil sketch on paper. That’s fine for showing a basic app layout but what if you want to explore interactions. Prott lets you capture your sketches and turn them into interactive prototypes that are fully tappable, along with custom gestures and transition animations. The tool also has collaboration functionality built in.

For those who prefer to start sketching out their ideas in a digital form but want a low-cost and low-effort way to add some basic interaction and animation, Apple gave us a peek at part of their prototyping process in one of the talks at WWDC (video requires developer login and Safari). They use Keynote! Creating slides with the dimensions of a device screen and animating from one to the next (particularly the “Magic Move” animation) allows for a surprising amount of sophistication. Since there’s a Keynote app for iOS devices too, you can actually preview the designs on the device. The major restriction here is that you can’t tap different areas to cause different actions – tapping anywhere transitions to the next slide, so you have to prototype individual flows through the app rather than the whole thing.

If you’re only designing for iOS and only want to use standard UI elements and screen transitions, then a fun alternative for exploring new ideas on the go is AppCooker. This is an iPad app for designing iPhone and iPad apps. It’s necessarily limited compared to many desktop tools but still very capable. There’s no custom animation support here though and while you can import images, it’s not really suited to designing a custom UI.

High fidelity prototypes without code

The majority of designers have limited coding skills. Being able to create a basic page layout and style it with HTML and CSS is an excellent start but it doesn’t get you to a place where you can easily build screen transitions or custom animations. Professional animators have almost always had tools that didn’t require coding but there was nothing for app designers. Facebook started using Apple’s Quartz Composer, a motion graphics tool, for prototyping. They built a toolkit on top of it for prototyping apps and released it for free as Origami. This is a highly capable toolset but since it wasn’t originally built for for designing apps it’s somewhat complex and difficult to learn and use. Quartz Composer itself is also not very actively maintained or stable.

For anyone that wants a similar tool to Origami that’s easier to use there are a couple of excellent new options. If a complete freedom is what you want then Form is an excellent option. It was released by RelativeWave as a paid tool but then rapidly acquired by Google and made free. They initially launched for iOS only with plans announced to also support Android. With the tool in Google’s hands we can assume that Android support will come quickly. Like Origami, Form provides a node and graph based visual programming environment. They also have a viewer app so you can preview the design on as many devices as you like and it updates automatically as you make changes.

If you want to build prototypes that look and feel just like native apps using the built-in OS frameworks then Pixate is definitely worth checking out. It lets you build iOS and Android prototypes that use the native UI components directly. You can add your own custom styling and animations in a visual programming environment. The Pixate team are currently working on direct import functionality from Photoshop and Sketch, so it can be added seamlessly to existing static design workflows. They’re also planning to add native code export, so that when a design is complete, the native code generated for it can be used as the basis for the final app UI. Generated code doesn’t have a great history of being maintainable but if they can pull it off it would be a killer feature.

EDIT: Just after this was published, Pixate added a free tier that lets you use all of their features for 1 app.

HTML5-based solutions

There are lot of prototyping solutions on the market that involve building app UIs with HTML5. Some of them are for custom designs and others provide libraries of native component clones. Some do both but very few provide a good level of support for custom animation. A couple of interesting exceptions are Proto.io and Framer.

Proto.io is another non-coding solution which also has collaboration features, allowing you to get feedback from your team or a client. Unlike most of the tools on the market, it has a library of Windows Phone components as well as those for iOS and Android. You can test on real devices and export the final HTML5, which could be useful as the basis for a hybrid app, or just as a guide for the developers. It is a fairly expensive subscription solution compared to most of the others but would clearly produce an excellent impression in a consulting and contract development environment.

For designers that know their way around JavaScript (or CoffeeScript), developers with some design skills or those rare unicorns – true designer/developer hybrids – Framer is one of the most interesting options out there. Framer already has direct imports from Photoshop and Sketch and focuses on rapid iteration, including live device previews. If you do a lot of design work and iterating quickly is a key goal then Framer might be the tool to beat. The underlying prototyping framework, framer.js, is open source and could be used independently but a lot of the productivity boosting features are in the paid Framer Studio tool.

What about functional prototypes?

What if your prototype needs to do more than just look and feel like the final app? Some app concepts can only really be understood and tested with live data or working features like using the device camera. Depending on the level of complexity it may even be possible to prototype these too. One option would be to hook up the output of an HTML5 prototyping tool to some real device functionality in a hybrid app. Another option is to build a fully functional prototype in a rapid application development tool like LiveCode. Although there may be areas where performance or functionality are lacking compared to building a native app, LiveCode has a visual UI design environment and good animation capabilities. It also makes it very quick and easy to add a database of real data or mobile specific features. When you get to this level of prototyping complexity, it starts to get time consuming and costly to build the prototype. It may make sense to only prototype parts of an application in this way, where it’s critical to get the design right before a very lengthy and expensive coding phase.

Consider prototyping your next app in more detail

[tweetable]The most common problem in software projects is not the technical execution[/tweetable], although that often takes longer than expected. By far the most common reason for app projects to fail is building the wrong thing. Although on the surface building a prototype only to throw it away might seem like wasted effort, it can massively reduce the risk of much more effort going to waste building something either the client doesn’t want or insufficient customers are willing to pay for. Prototyping the UI and putting it in the hands of clients or potential customers in a real device is one of the best possible ways of getting concrete, actionable feedback. Pick one of these tools, or find another that suits you better and give it a try with your next app. If you’re already a prototyping convert and we haven’t listed your favourite tool here then let us know in the comments.

Tags animated prototype, animation, prototype, prototyping tools

Business Community

Can the app stores sustain 5.5 million developers?

Post author By Mark Wilcox
Post date December 23, 2014
No Comments on Can the app stores sustain 5.5 million developers?

In our latest report, App Economy Forecasts 2015 – 2017, we estimate the number of mobile ecosystem in 2014 at 5.5 million developers. Demand for mobile development skills has never been higher and yet revenue from app store sales cannot possibly pay their salaries. Luckily they don’t have to as developers aren’t all building apps full time and there are several other revenue sources in the app economy, some of them comparable with or even significantly larger than the app stores.

Estimating the developer population

Counting mobile developers is hard. A lot of software developers look into mobile platforms and a lot of people are curious enough about how they’d make an app for their phones that they’ll try to find out. We can’t meaningfully count all of these as mobile developers. However, we also know from our Developer Economics surveys that a huge percentage of developers creating the apps that fill the app stores are not full-time professionals. Popular programming Q&A site StackOverflow has around 35 million unique visitors and it is only an English speaking community. That probably includes a lot of students trying to get help with their coursework. Meanwhile bottom up estimates for the global professional developer population based on job classification data from multiple sources are just under 20 million. This is highly error-prone due to the way developers are classified along with other IT professionals in many places around the world. How many of those are really building mobile apps anyway? Apple has over 9 million developers registered on their developer portal. Some of those are for Mac and Safari but the majority are iOS developers. Then again, the number of developer accounts with any apps published on the App Store for iOS is only around 350,000. Google Play has fewer active publishers than iOS. The truth must lie somewhere between these extremes.

For the purposes of our estimate we decided to count developers who are actively building, or planning to build in the very near future, publishable apps for a mobile platform. Students building toy apps to learn and hobbyists who only build things for themselves aren’t taken into account. Those people could join the ranks of mobile developers in the near future but they aren’t doing anything to satisfy mobile app demand yet. 5.5 million is the number of developers required to maintain all of the published apps that have been updated in the last 12 months, plus build all of the new ones released in the same period. In our report we also forecast the number of new and updated apps going forward and the number of developers required to sustain that app growth through 2017.

Keeping the pizza and coffee flowing

Developers are in high demand and as employees in the US they will typically earn upwards of $100k per year with relatively little experience. Proven talent in Silicon Valley can easily earn 50-100% more. Salaries in Western Europe are not quite as eye-catching but not that far behind either. In countries where the cost of living is much lower, developer salaries are obviously more modest but actually often a greater multiple of the national average wage.

Why would anyone with such earning potential build and sell apps that are likely to produce a poor return on their time. There are several answers:

Some apps make fantastic returns and some developers believe, or at least hope, they could emulate those and use their skills to make a small fortune
Other developers are trying to build small but sustainable businesses on the app stores, targeting niches and working as artists and entrepreneurs
Some developers build their own apps as proof of their abilities in order to sell their skills for a higher rate on contract development work
Many developers just love to code and already earn a full time salary in their day job, they build apps as side projects or for a hobby, either for fun, a little extra income or to sharpen their skills for their next career move
Some developers are purely learning and having fun, usually either at the beginning of their careers and in some cases after they’ve retired.

Note that only the first two of these are depending on the apps for income. Of course not all developers are trying to make a return from apps via paid downloads or in-app purchases. Advertising is also a big source of revenue in the app economy, although most of it goes to a few giant corporations. The typical developer monetising through ads does much worse than those using in-app purchases, so that’s not the answer. However, there are other models where developers have better odds of making money. Subscriptions are the fastest growing revenue opportunity according to our forecasts, although for pure Software as a Service rather than content subscriptions that will mostly be selling to enterprises. The biggest revenue opportunity of all in app economy over the next few years is definitely not in pure software businesses. Indeed, it’s the rather old-fashioned business of selling real physical things! Find out just how big it is by purchasing our latest report.

Tags app store, developer economics survey, mobile developers, state of the developer

APIs

4 + 2 tools for a happy multi-cloud developer

Post author By George Psistakis
Post date December 9, 2014
No Comments on 4 + 2 tools for a happy multi-cloud developer

It is exciting to be a developer these days. You’re the talk of the town and everyone looks for ways to make you happy, competing to create new tools or new services just for you. Developing a great app in such a mesh of services shouldn’t be an issue. Still, this often proves to be a daunting task. Just like the last time you wished to deploy in the cloud and there were 15+ various different services you had to consider.

– OK, so what is the problem? Having many alternatives is good … Right?

Well, that depends…. Here’s an example…
Let’s take the app we just talked about. To develop an app for cloud “X” you will need to download the SDK or Toolkit of that cloud and start writing code to use it. But what happens if you wish to switch to another provider? In case you want to change to cloud “Y”, you will need to download the toolkit for the new cloud. Cloud “Y”’s toolkit in turn has its own structure, syntax and design.

What can you do?
1. Stay on the same cloud…
2. Switch to another cloud. That is: Remove the old cloud code; download the toolkit of the new cloud; understand how it works; learn its particulars and re-design your app around it. Quite complicated, isn’t it?

It is clear that switching to another cloud provider is becoming difficult. Should you stay or should you go? This problem can be solved by two ways: standardization or 3rd party tools.

There are currently two organizations competing to come up with a standard for all cloud providers. These two standards are the CIMI / Cloud Infrastructure Management Interface and the OCCI / Open Cloud Computing Interface. The problem is that neither CIMI or OCCI are very widely used – instead of standardising, providers are increasingly coming up with their own APIs. Which leads to the 3rd party tools solution.

Cloud providers offer REST APIs for their services, but these often differ at the details. Cloud libraries or multi-cloud toolkits try to fix this by offering an abstraction layer over these services, allowing interaction with various cloud providers. They hide away their differences, provide one view and a unified API and eventually make moving between cloud providers easier. With their help, you can avoid getting stuck with one vendor. You only have to download the toolkit and write the code to use its API, which in turn will communicate with the cloud services. To switch to another cloud, you will not need to download another SDK or toolkit. You simply need to write some code (which is what you do anyway) to “talk” to both clouds.

What is out there?
There are several open-source, multi-cloud toolkits that you can use in your projects. Which to select largely depends on your coding language, cloud provider and service you need to work with. There are 4 main types of services supported by these toolkits:

Compute nodes (Start / Stop instances or configure)
Data Volumes (Creating / Attaching / Delete volumes, snapshots etc.)
Load Balancers
DNS

Note that not all providers are supported or willing to hand you over all the above four functionalities. To choose therefore the tool that best fits your needs, you need to do some homework.

To understand why you need to do any homework, let’s consider an example.

Assume you want to deploy and integrate your application and you only have to select between Amazon AWS and Microsoft Azure. Which are the best tools for you?

Apache Libcloud – Python

In 2009, Cloudkick created a SaaS cloud monitoring and management platform as a means of “talking” to many different providers. That early version of Cloudkick was later released as an open source Apache project and was finally acquired by Rackspace and replaced by Rackspace Cloud Monitoring.

Libcloud is a library that abstracts the differences between cloud providers. It allows you to manage different cloud resources through a unified and easy API. It is an open source project with a single Python interface of 35+ cloud providers and their services. Below is a list of the features and supported providers:

SERVICE		AWS	Azure
Compute	40+	YES
Block Storage	17+	YES
Cloud Object Storage	8+	YES	YES
CDN	6+
Load Balancers as a Service	7+	YES
DNS	6+	YES

Libcloud is the de facto choice for devs into Python and is supported by a great community. The documentation on their website is pretty good.

Let’s see some community stats:

Stackoverflow questions: 160
Github repositories 176
Most Github Stars (on single project) 518
Github Code results 2.2M
Google search (name + “libcloud”) 80K

Notice that Libcloud does not fully support Azure. For the time being it only supports Azure Blob Storages plus many of the AWS methods.

More about Libcloud at:

Note 1: If you exclusively work with AWS you may want to check Boto < https://github.com/boto/boto>. It is a Python library for interacting with AWS APIs which allows you to build tools in Python, change and manage your AWS resources.
The project is led by an Amazon Engineer.

Note 2: If you feel adventurous, take a look at Libcloud REST, a Google Summer of Code 2012project which exposes most of the Libcloud functionality over HTTP.

Apache Jclouds – Java, Clojure

Jclouds, now one of the most popular solutions, started off as a project from Adrian Cole who later joined the Apache incubator. Adrian Cole is considered an active community leader in the cloud interoperability, REST and DevOps space. His current title is “cloud guy” at Twitter. Jclouds is an open source library that allows you to use portable abstractions or cloud-specific features and supports Java and Clojure.

Let’s see what kind of cloud resources Jclouds can manage:

SERVICE		AWS	Azure
Compute	17+	YES
Block Storage	7+	YES	YES
Cloud Object Storage
CDN
Load Balancers as a Service	2+	YES
DNS

Jclouds, being a Java toolkit, naturally relies on a great community to support it. They also have excellent documentation on their website.

Here are the community statistics:

Stackoverflow questions 26
Github repositories 52
Most Github Stars (on single project) 531
Github Code results 7K
Google search (name + “jclouds”) 33K

While Jclouds supports some of the AWS services, it does very little on the Microsoft Azure side. In fact, it does not go beyond Azure Blob.

Note: There seem to be some early Azure implementations in the Jclouds labs. If interested, take a look or even contribute to their project.

More about Jclouds at:

Fog – Ruby

Wesley Beary, currently working at Heroku, is a great Rubist and the creator of Fog back when he was at Engine Yard. Fog is a cloud provider agnostic toolkit, therefore it supports a variety of cloud providers. The Fog gem is the most popular cloud SDK in the Ruby world and it is heavily used with over 4M downloads and a large and active community contributing to its development. It is an MIT-licensed open-source community project and is also used as basis for other Ruby gems like Chef.

SERVICE		AWS
Compute	25+	YES
Block Storage	9+	YES
Cloud Object Storage
CDN
Load Balancers as a Service	2+	YES
DNS	10+	YES

You can find many tutorials about Fog and its implementation online and adequate documentation on their website.

Stackoverflow questions 279
Github repositories 188
Most Github Stars (on single project) 3230
Github Code results 305K
Google search (name + “fog”) 565K

While currently Fog supports some of the major AWS services, it supports nothing on Azure! There are various discussions around the net about whether Fog will eventually go that way but, for the time being, no ongoing relative efforts exist other than some sparse GitHub repositories. Thus, if you are a Rubist and Azure user, the official SDK is a one-way option.

More about Fog at:

Apache deltacloud

RedHat wanted to develop an open cloud, vendor neutral so they started Deltacloud in 2009 and later joined the Apache incubator. For all you Rubists outhere, Deltacloud was written in Sinatra.

While Deltacloud is not the only open source project to offer cloud abstraction, it has a remarkable difference: Libcloud and Python, Jclouds and Java, Fog and Ruby are programming language-specific libraries. Deltacloud on the other hand is independent of the programming language and can also be used as web service. It provides three different APIs for interacting with Cloud service providers (a RESTful API, a CIMI-compliant API and a proprietary API) and is backward compatible across different versions of support cloud platforms.
Let’s see what kind of cloud resources and providers it supports:

SERVICE		AWS	Azure
Compute	15+	YES
Block Storage	15+	YES	YES
Cloud Object Storage
CDN
Load Balancers as a Service
DNS

Apache Deltacloud has an active community of programmers who constantly update it. You may find adequate info both in their website and online to get you started.

Stackoverflow questions 10
Github repositories 37
Most Github Stars (on single project) 80
Github Code results 34K
Google search (name + “deltacloud”) 23K

More about Deltacloud at:

…and 2 bonus tools

1) Do you like to play with node.js? Check pkgcloud! It is a standard library for node.js that abstracts away the differences among multiple cloud providers. It supports the usual Cloud resources and providers. Interestingly, it supports Azure Compute resources which is not the case in any of the above toolkits.

2) If you are the Erlang type of dev take a look at elibloud. An Erlang wrapper around Libcloud.

The Official Web site

Community Statistics Comparison

Below you will find two charts: a comparison of the number of cloud providers supported by each of the above toolkits and some community statistics.

Conclusion

Since 2006 the number of cloud providers has been steadily growing, bringing more services in the game. This is good news for developers, as more options become available to choose from. Using tools that provide a single interface to work with all these services can prove of great value to you, facilitating a potential transition from one provider to another. Still, good research prior to choosing a toolkit is essential. In our example, it becomes clear that Azure support from the toolkits presented is problematic, which is not the case for AWS (there could be many reasons for that, some originating in the very nature and definition of the Azure API). It seems that the development of toolkits is still a work in progress and things will soon start moving. Support of all major cloud providers is only a matter of time – and a game changer!

Do you use any kind of multi-cloud toolkits?

Tags apache, multi-cloud, restful api

Business

Are Freemium Apps Killing Game Developers?

Post author By Ted Nash
Post date December 2, 2014
No Comments on Are Freemium Apps Killing Game Developers?

The rise of freemium games has been ferociously quick and it continues to accelerate at an incredible pace. It’s estimated that adults now spend, on average, 5 hours and 46 minutes online and on their mobile devices. Time spent online has now surpassed time spend watching TV.

With more consumers than ever playing games on their mobile devices, developers have had to “evolve” to find the most efficient ways to monetise their potential customers and, from a revenue perspective, [tweetable]the ‘freemium’ model has almost completely killed ‘paid-for’ games[/tweetable].

Putting morals and ethics aside, the freemium route is absolutely genius. Freemium, especially on mobile, can generate vast amounts of profit for developers who manage to create popular applications.

When we ask the question, “are freemium apps killing game developers?”, it always generates an interesting debate. Let’s understand why.

What are freemium apps?

The term freemium can be defined as:

“A business model that provides a game to players free of charge, but charges a premium fee for special features, powers, or content.”

Take a look at the App Store whilst reading this post and you will see the overwhelming majority of top grossing applications are free to download.

To developers, these applications would be classed as “freemium” apps, but the majority of users who download these type of applications believe the developer is making it as difficult as possible to progress within the application in order for you to purchase ‘upgrades’, ‘coins’ or ‘power-ups’ that allow you to progress within the application.

Freemium applications started as an experiment, but very quickly became mainstream. In fact, it was reported last year that 76% of all iPhone app revenue came from in-app purchases.

From a developer’s perspective, freemium games are the preferred route. It’s where the majority of download volume exists and the highest earning revenue streams can be found. Most importantly, their prospective customers’ mindset has shifted. If you are not a ‘free’ game or application, you will have a much harder time selling yourself.

When you speak to independent game developers, they will tell you that more and more revenue could be generated from a free-to-download application. Take an example of a subscription-based game which might charge $20 a month to play. Only a few people might ever be willing to spend that – but far more would be willing to spend 10% of that on a freemium type game. The reality is, when you look at the metrics, there is little to no comparison. Free apps with in-app purchases are potentially much more lucrative.

On the other hand, there may be customers who, even if they were spending $20 a month on a game, would be willing to spend even more if they had the opportunity to. Legacy games never offered that type of flexibility, but things have changed and the top games developers are reaping the rewards.

The thought of ‘what if?’ really did start a new line of thinking. A line of thinking that eventually took the freemium model mainstream.

Why is Freemium seen as bad?

When you look at games from a hardcore gamers point of view, with the above scenarios in mind, you soon realise that the freemium trend is a real negative for them and their style of playing.

[tweetable]The core underlying aspect of freemium games is that you have to pay to continue playing[/tweetable]. Rather than pay a one off fee for a game which would take even the most dedicated gamer a while to complete, there are now deliberate parts of a game or application that force you to spend money in order to overcome a problem.

Roadblocks deliberately placed by a developer force a gamer to spend if they want to continue progressing. It’s this understanding, which has led to many negative reviews of freemium games and the mobile gaming industry in general.

When it comes to developing, freemium games are, arguably, easier for much larger game publishers to make, because these types of games require much more iteration than a traditional paid-for game might demand.

This means that the true independents have a higher barrier to entry than they did before. People expect a lot for free, and if you are not monitoring your audience with a deep level of detail, it’s very difficult to understand when the best time to monetise might be.

Example of the freemium model

Examples of the freemium model taking place inside a game can be found in many different scenarios:

Energy bars are everywhere. The new ‘World of Warriors’ game and ‘Clash of Clans’ from Supercell are good examples of energy meters. In both games, you have ‘food’ and various other ‘elixirs’ which are essentially energy meters. If you have ‘0’ food, you can’t play until it recharges. Regardless of what shape these roadblocks come in, they all serve an identical function: to slow down a player’s progress.

Mobile games would also appear to be getting easier and easier. The majority of these games would not work if a gamer could engage with them and play them for an hour at a time.

Energy meters and time constraints mean that you can only really play an app in small chunks. Unless you pay.

Naturally, a percentage of all users don’t want to wait for their timers to be refilled, so they will pay to get passed what was intended to be a roadblock.

In older, more traditional games, if the player was stuck at a specific part of the game, they would work hard to try and find a solution to the problem they face. However, now if you run into a problem, no matter the quality of the gamer, to get past what might once have been a complex problem – you can pay.

Another very common freemium model is charging for virtual items.

It’s difficult for game developers to understand what is a fair price to charge for various virtual items, but developers are now moving towards simpler monetisation tactics. For example, skipping a level or buying a considerable item which gets them past what was supposed to be a difficult level.

The problem with this is that items like ‘level skipping’ could be free, because it doesn’t actually cost the developer anything to offer hints.

If you compare this with a game we all know, Call Of Duty, giving a player the opportunity to buy new weapons or customise a character has cost the game developer/designer time and money.

Are freemium games killing developers?

Whilst consumers have obviously voted with their wallets that freemium games and applications are what they want to buy, some of us at Tapdaq believe that this has squeezed independent developers into a corner they might not necessarily have wanted to end up in.

There is no doubt about it, I think it’s harder to devote time into creating a game which is long and complex simply because of the natural shift to more casual gaming.

As with all markets, there are two sides to it. In this particular market, you have developers and you have players. If game players are so anti freemium games, then they need to do their bit. They need to start spending money on items which actually cost the developer resources to make, as opposed to buying hints and level-skipping upgrades which defeat the object of playing the game in the first place. They need to value the mobile gaming experience.

New freemium games come out every week in today’s quickly evolving mobile gaming market. This is a business model that, for the foreseeable future, will impact the games we all play. Therefore, game players need to go out and support games that are fair as well as fun to play. Players passionate about game sustainability must vote with their wallets as well as their words.

Looking at the graph below, freemium is proving to be great for developers, but it might have adverse effects, and who knows when we might start to see diminishing returns.

Freemium still has a large share of the market, but it’s unlikely to make you rich.

I think we’ll continue to see larger game developers dominate the top grossing in various app stores for the foreseeable future, and I don’t think freemium as a business model for games gives a fair platform for genuine independent studios to thrive. However, individuals and small studios who create games are usually far more dynamic and should adapt to evolution faster than larger corporations.

So, is freemium killing developers? The answer is, we can’t be sure yet. One thing is certain, though,the industry will continue to be driven by its customers and customer perceptions of “free” games. Recent events have shown that there is a split between those who are happy to pay for games and additional content within them, and those who expect the game or updates to be free.

A winner for preferred business model has not yet emerged on the mobile platforms, and it is very possible that mobile gaming will evolve in a similar vein to its desktop/console brethren – with games adopting different monetisation methods based on their audience, content and personal preferences.

Let me know what you think in the comments below.

Tags app business, Business models, freemium, in-app purchases

Tools

Popular ICEs for mobile hybrid app development

Post author By Katerina Roukounaki
Post date November 24, 2014
No Comments on Popular ICEs for mobile hybrid app development

If you want to target multiple mobile platforms without having to maintain a separate code base for each one of them, mobile hybrid apps is one way to go. What mobile hybrid apps won’t do, though, is relieve you of the need to manage and use multiple tools, e.g. building your app for a specific mobile platform requires installing the platform’s native SDK on your machine.

ICEs are here to take this headache away. ICE stands for Integrated Cloud Environment and it’s essentially an IDE that does some of its work in the Cloud. A typical ICE for mobile hybrid app development provides you with tools to design, write, test, debug and profile your app. It also allows you to configure the build settings of your app, manage its signing keys and compile it for various platforms.

[tweetable]One of the most popular features of ICEs is building your app in the Cloud[/tweetable] – they grab your code, upload it to the Cloud, build it and come back with the produced app bundle(s). Since the build process no longer takes place on your machine, there is no need for you to install any native SDKs. Apart from building, ICEs may also use the Cloud for storing your app or for pushing it to a device for testing purposes.

A mobile hybrid app development ICE traditionally comes with a companion mobile app that can be downloaded for free from all major app stores. This companion app acts as a container for your own app (your app runs inside it, so you not need to install the former on the device) and also provides some extra functionality (e.g. checking for new builds of your app).

So, here are four of the most popular ICEs for mobile hybrid app development (PhoneGap Build is not really an ICE as we’ll explain later on). But before diving into the details, the following tables provide a handy overview of these tools.

Tool	Owner	Free?	Type
AppBuilder	Telerik	No	Desktop-based (Microsoft Windows), Browser-based
Intel XDK	Intel Corporation	Yes	Desktop-based (Microsoft Windows, Ubuntu Linux, Apple OS X)
Monaca	Asial Corporation	Yes *	Browser-based
PhoneGap Build	Adobe	Yes *	Browser-based

* A free subscription plan is offered (among others).

	AppBuilder	Intel XDK	Monaca	PhoneGap Build
Code editor	✔	✔	✔	✘
Drag-and-drop tool(s)	✔	✔	✔	✘
Source version control	✔	✘	✘	✔
Collaboration	✔	✘	✔	✔
Device simulator	✔	✔	✘	✘
On-device debugging	✔	✔	✔	✔
On-device profiling	✘	✔	✘	✘
Builds	✔	✔	✔	✔
Companion app	✔	✔	✔	✘

AppBuilder

With AppBuilder (previously known as Icenium) you can develop your app in collaboration with other members of your team, using both a code editor and a drag-and-drop tool (experimental and limited to apps that use Kendo UI).

AppBuilder allows you to test your app on a built-in device simulator, on native emulators installed on your machine, as well as on real devices (both connected and remote). In the case of real devices, you can either install your app or run it inside the AppBuilder companion app.

While your app runs on the simulator or on a connected device, you can debug it using the bundled debugger that’s based on Web Inspector. AppBuilder also allows you to automatically reload your app as you make any changes to its source code.

❢ AppBuilder offers Cloud-based storage and version control for your apps.

Intel XDK

Intel XDK contains a bundle of tools: a code editor that is based on Brackets, two drag-and-drop tools that help you design your user interface (one supports App Framework, Bootstrap, jQuery Mobile and Topcoat, while the other is limited to App Framework), and a device simulator that is based on Apache Ripple.

In addition, Intel XDK allows you to test your app on real devices that are connected to your machine or are in the same wireless network as your machine. In both cases, you need to have App Preview (Intel XDK’s companion app) installed on your device. Similarly to Telerik’s AppBuilder, Intel XDK automatically reloads your app (if you’re using an Android handset) as soon as you make changes to the source code.

With Intel XDK you can also debug and profile a running app. On the device simulator you can use a debugger that is based on Chrome Developer Tools (CDT). On a real connected Android device (with both App Preview and App Preview Crosswalk installed on it), you can use weinre (WEb INspector REmote) and a built-in profiler that helps you identify hot-spots in your Javascript code.

❢ Intel XDK supports live layout editing. While your app is running on a connected Android or iOS device, you can preview the result of the changes you make to your HTML and CSS files as soon as you hit save.

Monaca

Monaca allows you to collaborate with other testers and developers on developing your app. You can chat with them as you write code, and share your thoughts, as well as screenshots of your running app, while debugging it on a real device.

With Monaca, you can preview your app in a browser (with different device screen sizes and orientations) or run it on real devices inside Monaca Debugger (the companion app of Monaca). In both cases your app gets automatically reloaded every time you make changes to the code and save them.

You can debug your application in preview mode, using the debugger that comes with your browser. Alternatively you can debug on a real device, using Monaca Debug Panel, a tool based on Web Inspector. Some debugging features are also available on the real device; for example, you can view the source of the current page or inspect the application log.

❢ Monaca stores your code in the Cloud, and you can access it at any time and from any place using WebDAV.

PhoneGap Build

PhoneGap Build is not really an ICE, but rather a build service that works in the Cloud. It pulls the source code of your app from either a .zip file or a (private or public) Git repository, and then allows you select the platforms you want to build your app on. Throughout the building and testing process, PhoneGap Build enables you to collaborate with testers and developers from your team.

PhoneGap Build allows you to build debug-enabled and/or “hydrated” versions of your app. With debug-enabled builds you can remotely debug your app using weinre, whereas new hydrated builds can be automatically pushed to the devices and replace older ones.

❢ PhoneGap Build does not store the passwords for your signing keys for more than one hour since the last time you used them.

To sum up

Mobile hybrid apps allow you to target multiple mobile platforms with less code, in less time, and with fewer programming languages. ICEs for mobile hybrid app development move parts of the development process in the Cloud (e.g. they build your app there), thereby adding one more benefit to the above list: fewer tools.

There are several reasons for trying out an ICE – the choices differ according to what you’re trying to achieve. If you enjoy writing code on the Web, you can use Monaca, while if you want to spend less time on writing code, AppBuilder’s and Intel XDK’s drag-and-drop tools might make your life easier. Keep in mind that using an ICE does not require abandoning your current editor or IDE – you can use any editor or IDE you like and then import your code into an ICE to test, debug or build your project. Finally, there are some cool features in this post that might have caught your eye – e.g. Intel XDK’s remote profiler or Monaca’s collaboration tools. So, get started with an ICE – and let us know what you think!

Update Dec 15, 2014: Monaca kindly informed us they also provide full debugging functionality via USB, using Chrome on Android and Safari on iOS devices.

Tags hybrid apps, integrated cloud environment, mobile platform

Business

How to make money with apps

Post author By Mark Wilcox
Post date November 17, 2014
No Comments on How to make money with apps

A major theme in our State of the Developer Nation reports is an increasingly gloomy picture of typical developer revenues. [tweetable]The vast majority of developers make very little money from their apps[/tweetable]. However, there are a lot of developers out there and a decent fraction of them make a good living, some are building thriving businesses on the app stores and a few at the top are even creating multi-billion dollar companies. So, what’s different about the developers that are succeeding financially versus those that are living in app poverty?

Are you making money from your app? Let us know and you might discover new tools that can make you even more profitable. Start here.

There are two major risks when analysing groups of successful individuals or companies to try to work out why they succeed when others fail; the first is survivorship bias – ignoring the many failures that may have done exactly the same things, the second is confusing correlation with causation. In the latter case there are many things that developers do because they have a successful app, like porting it to lots of other platforms, that are completely unrelated to how they became successful in the first place. [tweetable]There isn’t a magic formula for success on the app stores[/tweetable] but we can try to avoid falling into these traps by looking at factors that might increase your chances of success.

In our last report we showed two major factors that correlate with higher revenues, targeting enterprises rather than consumers and using 3rd party tools. The former is almost certainly a direct cause of financial success, the later is probably indirectly related, tool use indicates a more sophisticated approach to app development as a business. There are many more factors that can make quite a significant difference to the chances of financial success with apps, so lets take a look at some of them.

As our benchmark we’ll use the rather modest (but challenging) goal of making more than $5k per app per month. This is a revenue level that would allow a single app to support a developer in the US or Western Europe but is below a typical employed developer salary in those places. In some countries it would support a whole team living very comfortably. How much more likely are developers to be earning above this level depending on which platforms, categories and device types they target or what revenue models they use?

Platforms

It’s been widely reported that iOS is still ahead of Android for revenues but there are suggestions that Android is closing the gap. Looking at overall revenues from the platform or the earnings of the very top developers, this may be the case. Some even earn more on Android than iOS. However, revenue is more concentrated at the top on Android than iOS, so the chances of earning above the $5k per app per month level are still much higher for those who primarily target iOS. Despite the decreasing popularity, targeting the mobile browser is quite far ahead of building Android apps too. In this case though, many targeting the mobile browser may already have successful desktop web businesses, so this might not be so easy to replicate for those starting new businesses. Windows Phone and BlackBerry 10 are both offering very low chances of a decent financial return as primary platforms. Note that this doesn’t imply that there’s no revenue available on either of these platforms, it could all be going to apps that succeeded on other platforms first and then ported.

App categories

It’s no surprise to see enterprise apps and business and productivity software at the top of the high earning app category charts. What’s more interesting is the “other” category between them. Developers who seek out and dominate niches outside the standard app categories are doing very well; it’s not the route to a billion dollar company but it’s a smart strategy for a small business. Despite the many reports of fitness trackers ending up unused in drawers after a few months, health and fitness related apps are doing quite well. It’ll be worth watching how the major platforms health and fitness data platforms impact this category. The success of the communications and social networking category at this revenue level is slightly counter-intuitive, this is a category with significant network effects favouring a few big winners. It seems that this is such popular use case for mobile devices that there’s room for a lot of developers to add value. To contrast with these, the categories at the bottom of the list are Kids (16%), Games (17%) and Education (17%). These bottom categories are pulled down by their popularity with hobbyists, giving full-time professionals targeting these categories a lot of free competition.

Device types

Smart TVs and set-top boxes are a surprise leader in terms of device types to target first. Only a tiny fraction of developers in our survey had these as their primary target, so this isn’t a reliable sample. It’s hard to get visible on TV platforms and you usually need content, so this might not be a strategy to emulate. The Internet of Things is also unexpected at number 2 considering how immature the market is. It may be the case that hardware sales are involved in many of the higher revenue earning businesses here, in which case there are much higher costs associated than for pure software businesses. While smartphones are a massively more popular primary target than tablets, the chances of an app earning above the $5k per month level are quite a lot higher on tablets. There are likely to be several factors involved here; less competition, more tablet apps targeting enterprises and with the reliance on free apps making most of their money from a small fraction of users, it can pay to provide an optimum experience for the heavy users on a larger form factor. This last point is valid right up to the highest revenue levels – Supercell have built their games tablet first with a scaled down experience on smartphones.

Revenue models

At the top of the revenue model tree is per device royalties or licensing fees.This is likely to be a mixture of enterprise apps and successful apps that have managed to get pre-installs on devices. This is a highly desirable revenue source but certainly not available to all apps. The next best is contract work at 30% of developers earning more than $5k per app per month. Contracting gives a decent chance of making higher revenues but of course the app belongs to whoever it is built for, so the upside is also very limited. At the same time this is by far the lowest risk model, with twice the chance of making more than $5k per app per month than the worst model, advertising. Subscriptions and e-commerce are tied for third place at 29% and affiliate and CPI programs are not far behind at 28%. These models are often harder to implement but our data suggests that the effort is likely to be worth it if they can fit the app concept.

Finally, an interesting comparison towards the bottom end of the revenue model scale is paid downloads (18%) versus free apps with in-app purchases (19%). There is very little difference between the two revenue models at this level of revenue. This is a very strong contrast with the total amount of revenue earned through each of those models. This probably reflects the fact that getting a freemium model with in-app purchases to work is difficult – there’s a very big risk of just giving a free app to a massive majority of users and getting no more paying users than for an equivalent paid app.

Conclusion and warning

There are a number of different ways you can target your apps and select your revenue model to increase your chances of financial success. What we haven’t analysed here is how these combine. Some of them probably won’t, for example, tablet first and iOS first is a good combination, but tablet first and Android first probably isn’t. Our analysis in the State of the Developer Nation report has also shown that some of these combine in an additive way, for example, building enterprise apps for iOS has very high chances of financial success.

Take the Developer Economics Survey, test your skills and compare them to the global average. You can work on those skills that need improvement and become more competitive. Cool, right?

Tags app business, app monetisation, app poverty, app revenues

APIs

What the logs don’t tell you

Post author By John Cooper
Post date November 7, 2014
No Comments on What the logs don’t tell you

In a world that is increasingly dominated by mobile applications and cloud services, APIs are becoming crucial to developers and service providers alike. But what are developers actually getting? And is this what service providers think they provide?

Developers

Developers want to use APIs that extend their service without having to either build the technology themselves or comply with required legislation or security (think payments or anything to do with storing large amounts of personal details).

[tweetable]Developers want simple, scalable, well-documented APIs that are as reliable as possible[/tweetable]. They do not want API they use to make their service unreliable, buggy or slow, i.e. make them look bad. Poorly-performing APIs can harm a developer’s reputation but also the API provider’s, should the branding of an API be visible to the world (think Twitter, Facebook, Instagram).

API Providers

API providers grant access to a service or services through the use of public or private APIs; a private API being a service that is not for public consumption for privacy or security reasons. Why grant access at all? To allow developers to use services and functionality that they do not have to build themselves and provide stickiness to an existing user base. Salesforce has done an amazing job of allowing third-party developers to use and extend the functionality that is provided and has even allowed developers to build a thriving apps and plugin community.

API providers look to balance the load on their servers that may also be dealing with other services. They are trying to provide minimum response times whilst maintaining the access and integrity of the data and the service for the developers.

Schrodinger’s API, it both works and doesn’t work at the same time

Here lies the problem; when an app that relies on an API performs badly whose fault is it? Is the app performing how the developer expected or is the API not responding and thus slowing the service? I[tweetable]t is very easy for the API provider to believe that just because the green light is on that the API is working[/tweetable]. Many systems behave completely different from the theoretical under load, when exposed to extreme conditions or elements beyond normal operation or even users doing unexpected things to the API.

Logs

System logs, either from servers, application monitoring tools or other conventional developer operating systems are excellent at hiding things because there is usually a lot of data to digest and identifying the issues from the noise can be nearly impossible.

Some examples include:

Averages – Whilst an average latency of 300ms may look ok its not if you are still getting a number of calls that take 10 seconds. To understand whether or not your slow performaning outliers are an issue means you have to look at the distribution of latencies and the frequency of the outliers.

Errors rates – hopefully these are low. Even a low error rate in a popular API can represent a huge issue. Consider an API that deals with 2 billion transactions a day at 0.2% error rate still has 4 million failed calls a day.

Logs only measure calls – If the API is not frequently used then the logs are not going to tell you anything. If the bulk of transactions are say only done on a Friday but the services failed on a Thursday then the detail will not be in the logs. Only frequent monitoring will notify you of issues before they hit your users.

Basically what the logs don’t tell you is how APIs work end to end, in different geographic regions and what the end-to-end latencies are when using real transactions.

Some simple rules

Monitoring is for life not just for Christmas.

An API that is switched on may not stay on but may be on every time you check.

The reliability of an API is inversely proportional to the number of people using it and the number of developers trying to do things that may break it.

The use of server logs is a function of user base and the amount of data being recorded.

Test the API like it would be used in the wild, end-to-end across a range of cloud services and apps. In this instance cloud services means hosting platforms like Google Apps Engine, Amazon Web Services and Azure to name a few.

Key question to ask is whether the servers are being tested for performance or the API and the impact on users and the overall experience?

As a developer and a user of services it’s the experience that matters. Poor experience equals poor brand perception, which leads to trying a different API or app, losing the client whether it’s a developer or a guy with an iPhone migrating onto the next app.

Things to consider when testing

Where is the data being served and where are your users?

An app that works in San Francisco when the server farm is in Mountain View may show differences when the same server farm has to serve the app in Europe. Test the API from different locations.

I got a HTTP200 response that means everything is fine, right?

Whilst most of us have seen HTTP 404’s, page not found, we also know HTTP 200 indicates an OK response from the server. The challenge comes from when a HTTP 200 means that things are not OK. For example, in order to avoid browser problems, some APIs only return HTTP 200 with an error message which needs to be parsed. Alternatively, the API might be returning invalid content which could cause an App to fail.

API search function comparison

In the above figure it can be seen that the average latency for search using the Facebook and Twitter API is approximately 2 seconds apart with Twitter being the faster and less erratic. Whilst we can only guess at what is happening in the background the reality is Facebook Graph Search appears to be less responsive to anyone using this feature in an app.

Regional server response variation

The above figure shows Facebook Get response across 6 regions globally. It can be seen that Asia and particularly Japan are poor cousins when it comes to regional performance. This behavior has been viewed with other APIs that have been tested in this way.

Caching data

The above figure shows the effect of caching on server response. After caching was implemented on the server it can be seen that response improved, even during refreshes (the spikes) overall performance was up.

Server issues

The above figure shows intermittent server issues over time. This can be indicative of load balancing issues or a problem with a server in a server cluster.

What is the future?

[tweetable]The number of APIs is only going to increase and developers are likely to rely on 3rd party services more and more[/tweetable]. It is also likely that more than one API from more than one provider will be used in an app. How can we mitigate against the response of one API compared to another? We see a need for intelligence in the app that can let that user know that something may be awry with the service trying to be accessed. This should be utilized as part of the UI flow to warn that ‘hey looks like is not responding, please bear with us’. This would be enabled by pinging the monitoring service to determine if there are any issues reported or the app being alerted automatically on a fail scenario that is outside pre-determined boundaries.

Intelligence in the monitoring will also lead to better understanding of the results and give a heads up to the API providers when issues occur or when the data is showing that a server is about to fail and allow providers to avoid downtime.

Disclaimer: Data was provided by APImetrics.io who focus on API Performance measurement, testing and analytics. John Cooper is advisory board member at APImetrics

Tags Analytics, cache, dropbox, Facebook, latency, twitter

Business

North American App Developer Trends 2014: Insights into the app economy powerhouse

Post author By Mark Wilcox
Post date November 5, 2014
No Comments on North American App Developer Trends 2014: Insights into the app economy powerhouse

North America plays a very central part in the app economy. Firstly, it is home to the companies that create all of the leading mobile platforms. These include some of the largest developer communities. Secondly, it is the largest creator of app revenues. We estimate that in 2013, North American app developer trends contributed 42% of the world’s app economy. Developer mindshare in the region is also considered particularly valuable by OEMs and tools vendors. This is due to the disproportionate global shares of both venture capital and media coverage focussed on the region. North America is often the starting point for new developer trends with high smartphone penetration and relatively mature 4G networks.

For those that seek to understand developer trends and preferences in North America we have created a new report which compares the region to the rest of the world. The report covers developer mindshare for platforms, languages and tools. It also includes revenues and deeper dives into enterprise and game developer markets.

North America App Developer Trends report: Questions answered

Why are developers in North America more likely to target mobile browsers than those in the rest of the world?
Android mindshare is higher than iOS in North America. But by how much?
Despite lower mindshare, iOS is prioritised by more North American developers than Android. But how many?
How much more revenue does a developer in North America earn on average than one elsewhere in the world?
How is that extra revenue distributed amongst the developer population and across platforms?
Which revenue models are most popular and which are the most successful in North America?
Enterprise developers in the region make significantly more revenue than those targeting consumers. How many times greater is the average revenue?
Which revenue models do these enterprise developers favour? What’s their share of the total revenue pie?
Games are also monetised differently than other apps. Which are the most popular revenue models for North American game developers?
Ad networks are the most popular category of tool globally but not in North America. What’s more popular there?
What’s the breakdown of developer tool usage across platforms in the region?

The North American App Developer Trends 2014 report includes many more insights and explanations of key trends. If you need to know more about developers in the region then this report is for you.

Tags app economy, app revenues, north america