Categories
Tools

21 tools behind the success of King and Halfbrick Studios

King and Halfbrick Studios are some of the most successful mobile game developers. Their best-selling games, i.e. Candy Crash Saga (King) and Fruit Ninja (Halfbrick), rate in the 100M – 500M download tier on Google Play and rank among the Top 100 on iTunes. Did you ever wonder which tools they use and how they compare? Do they use the same SDKs available to the rest of us mortal developers and what can we learn from their tooling choices?

29-tools-behind-king-halfbrick-1

We analysed 39 apps (iOS and Android) from King.com and Halfbrick Studios to determine which SDKs they are using and what tools makes them tick. We ‘ve broken down the results by tool sector for easier comparison. Note our analysis technology is still in beta, so let us know how we can improve it.

Halfbrick Studios King
Ad networks and exchanges Google Ads
Apple iAd
InMobi Native Ads Platform
Millennial Media
MoPub
Vungle
Google Ads
Apple iAd
Game development Apple GameKit
Amazon Game Circle
Google Play Games Services
Apple GameKit
Google Play Games Services
MV* frameworks Angular
Crash analytics and bug tracking ACRA ACRA
Crittercism
User analytics Google Analytics
Kontagent
App monetization Amazon In-App Purchasing
Google Play In-app Billing
Google Wallet
Amazon In-App Purchasing
Google Play In-app Billing
Google Wallet
Social Tools Facebook
Google+
Twitter4J
Facebook
Google+
KakaoTalk

Let’s consider these tooling choices one sector at a time.

1. Ad networks and exchanges

Starting with Ad Networks, you can tell HalfBrick Studios employs a handful of tools, while King uses only the major networks of each platform, i.e. Google Ads (Android) and Apple iAd (iOS). This is indicative of the reliance of the two companies on ad revenues. King has long abandoned advertising as a revenue source with a clearer focus on in-app purchases.

Bear in mind it is quite common for app developers to use multiple ad networks. If demand is not met by the first network’s supply, you move to the next network and so forth until you find a medium to display. That is why Halfbrick Studios uses multiple ad networks, and indeed they have chosen high performance networks.

2. MV* frameworks

Halfbrick Studios using AngularJS, a popular JavaScript MV* framework, might strike as a surprise. What does JavaScript have to do with Fruit Ninja and Jetpack Joyride? Digging a bit deeper we discover Halfbrick is using web technologies to implement BrickNet – a service that allows transfer of scores and saves across multiple devices. The BrickNet service is bundled with all the company games we examined.

This strikes another chord: there has been a lot of talking on how web technologies are not suitable for mobile apps due to mainly performance reasons. Well, this case is a testament that technologies are not good or bad per se – it all depends on the use case.

3. User analytics

Regarding user analytics, we were unable to detect any SDKs on King’s games. They could be using a custom in-house solution, or an unknown-to-us tool.

Halfbrick Studio uses the notorious Google Analytics in combination with Kontagent (rebranded as Upsight), which is better positioned for mobile games. The takeaway here is that the most popular tool of the category, i.e. Google Analytics, works perfectly for top as well as indie developers. [tweetable]The difference is in not in which tool you use, but how you use that tool[/tweetable], i.e. how do you interpret the analytics data and use it to grow your company.

4. Social tools

While Halfbrick Studios uses all the popular western social networks, King is more picky. They don’t seem to like Twitter, at least on the apps we found in the US stores. They do however use KakaoTalk on the iOS version.

Anything we missed?

So, this wraps it up. What did you learn from the tooling choices of King and Halfbrick studios? Is there anything we missed? Want to see more of these tooling deep dives? Leave a comment below and let us know.

Categories
Business

App developer trends Q1 2015

Our 8th Developer Economics survey has once again achieved an industry-leading scale, including responses from more than 8,000 app developers and 143 countries. Their collective insight shows us an app economy that’s beginning to mature. Platform mindshare and priorities are fairly stable and developers are increasingly turning to cross-platform technologies to deal with the multi-platform reality. Tool adoption is gradually increasing and a shift in focus towards enterprise app development is underway. You can get a copy of the full report here – it’s a free download.

DE8-illustration

The big changes on their way are in development languages and the Internet of Things. Apple’s new Swift has had an impressive level of uptake but C# and JavaScript are also growing in importance. Meanwhile mobile developers are showing a very strong interest in the next wave of connected devices.

Platform Wars
The platform wars have ended in a stalemate. [tweetable]Apple have an increasing lock on the high-end with iOS and Android dominates everywhere else[/tweetable]. Windows Phone is still growing, now at 30% mindshare, but not generating enough sales to break through the app-gap. The split of developer platform priorities amongst full time professionals best illustrates the stalemate. Android has 40% of developers, iOS has 37%, whilst Windows Phone and the mobile browser have just 8% and 7% respectively.

fulltime-pros-duopoly

Although not yet a priority the mobile browser has also bounced back strongly from an all-time low in terms of mindshare 6 months ago, with 25% of developers now supporting it. With the massive growth of mobile apps it’s important to remember that the desktop and mobile web combined is still the most important digital channel for the majority of businesses. [tweetable]The web is definitely not dead[/tweetable].

The Rise of Swift
Our development language rankings show absolutely unprecedented growth for Apple’s new Swift language. [tweetable]20% of mobile developers were using Swift just 4 months after it was introduced[/tweetable] to the world. For comparison, Google’s excellent Go language doesn’t make it onto our new top chart for server-side programming languages, having reached just 5% mindshare amongst mobile developers after more than 5 years. [tweetable]Amongst the first wave of Swift adopters, 23% were not using Objective C[/tweetable], a sign that Swift may succeed in attracting a much wider range of developers to build native iOS apps.

rise-of-swift

Revenues
Growth in direct revenues from the app stores is slowing. As these direct revenues are preferred sources of income for the Hobbyists, Explorers and Hunters that make up around 60% of the mobile developer population, competition for them is becoming more intense. 17% of developers who are interested in making money generate no revenue related to apps at all. A further 18% of developers make less than $100 per month and the next 17%, bringing us to a total of 52%, make less than $1000 per month.

below-1k-month

Those low revenue earners are not at all evenly distributed across platforms. Of those that prioritise iOS, only 37% are below the app poverty line, making less than $500 per month on iOS. On the opposite end of the revenue scale, 39% make more than $5,000 per month on the iOS platform. Rather surprisingly, the revenue distribution for Android-first developers is not much different than for those targeting BlackBerry 10 or Windows Phone. In fact, developers that go iOS first actually earn much more revenue on Android than those that prioritise the platform.

Internet of Things
Despite the relative immaturity of IoT platforms, mobile developer interest is high. A massive [tweetable]53% of mobile developers in our survey were already working on some kind of IoT project[/tweetable]. Smart Home was the most popular market with 37% of mobile developers working on IoT projects targeting it. Wearables were a close second with 35% mindshare. The majority of these mobile developers involved in IoT development are doing it as a hobby (30% involved at this level) or side project (just under 20%), whilst working on mobile apps in their day job. This is expected at this stage of the market where revenue opportunities are still limited.

Tools
Tool awareness is increasing. The fraction of developers not using any third party tools at all has fallen to an all time low of 17%. The second most popular category of tool is ad networks, with a 31% adoption rate. Unfortunately this is the one category of tool that’s negatively correlated with revenues. Cross-platform tool adoption is on the rise. The percentage of developers using these tools has grown from 23% to 30% over the last 6 months. While cross-platform tool use was previously uncorrelated with revenue it’s now a positive revenue indicator. We don’t believe this is due to a significant improvement in the tools, rather it’s because of their disproportionate use in enterprise app development.

Enterprise vs. Consumer
The enterprise app gold rush is now well underway with 20% of developers primarily targeting enterprises, up from 16% in Q3 2014. This shift in focus is paying off. [tweetable]43% of enterprise app developers make more than $10K per month[/tweetable] versus 19% of consumer app developers reaching the same revenue level.

Amongst consumer app businesses, the majority of the revenue is coming from free-to-play games. A typical game is giving a third of gross revenue to the app store provider as a cut of in-app purchases and spending half of what’s left on ads to acquire new users. These game developers are starting to look more like typical fast moving consumer goods businesses, with significant benefits from scale. Despite overall revenues from the stores still rising, life is getting much harder for the small independent developers that try to serve consumers.

The good news for consumer app developers is that 3 of their top 5 favourite categories are common with enterprise app developers. It’s definitely not too late to re-focus on B2B rather than B2C sales. Also, the skills developed building consumer apps are in greater demand than ever now that more and more businesses are taking mobility seriously. This is a trend that will keep running for several years yet.

Want more? Download and read the full report!

Categories
Business Community

Developer corner: Lessons from a one-man app business

For the last two and a half years I’ve been building and selling apps directly on the iOS App Store, however only in 2014 I committed to some substantial effort on this. I’d like to share some numbers about my experience last year and draw some insights about what things went well and which ones didn’t.

Hopefully this analysis will be useful to others and will give me some insight about where to focus in 2015 to grow my app revenue.

How do you monetize your apps? Take the Developer Economics Survey and let us know. You may win awesome prizes and gear.

one-man-band

Apps Summary

January 2014 brought along my most successful app so far: My Oyster. This app has been in development since October 2013 and even though it had a rough start on the first few months of the year, it is now my most consistent app in terms of downloads and revenue. Along with it, I started selling My Oyster Pro as a 69p ad-free alternative as I wanted to evaluate how well the freemium and paid pricing models would work for the same app. As it turns out, this paid version contributes to sales figures comparable to the ones of the freemium app.

Alongside this, I have been working on improving Camera Cube, which has been live since 2012 and takes the second spot for this year on revenue. Most notably, I released a major update with iOS 7 compatibility in July and added support for iPhone 6 and 6 Plus in December.

In August, I also released Perfect Grid as an iOS port of a simple puzzle game I previously made for Android.

Finally, in November I launched Pixel Picker, my first app written in Swift!

Alongside these new entries, my two old apps Puzzle Camera and Camera Boom are still live on the App Store, however I have not been updating them this year.

My App sales numbers in 2014

Total Revenue
Paid Downloads
IAP Revenue
Ad Revenue
£ 584.23 £ 151.80 £ 199.21 £ 233.23

AppAnnieRevenues2014

App Annie Yearly Revenues 2014 – Source: Musevisions blog

The first important observation is that 86 % of my total revenue comes from the My Oyster and My Oyster Pro apps which both went live in January and brought in 504.86 £ by the end of the year. Overall the freemium version accounted for 70% of these sales (fairly equally split between in-app purchases and ad revenue) and the paid version for the remaining 30% of sales.

This shows that the choice of differentiating my revenues across advertising, in-app purchases and paid downloads has paid off and I plan to keep all these streams going for My Oyster in the future and try them with my other apps as well.

AppAnnieRevenueGraph2014

App Annie 2014 Revenue Graph – Source: Musevisions blog

The graph above shows how my revenues have changed over time during this year. For various reasons, I had to remove My Oyster from sale during the January, February and April timeframes, and this shows clearly in the revenue graph.
For the rest of the year, revenues have been varying between 1.5 to 2£ per day on average and peaks of 4 to 6£ per day.

Expenses

In 2014, the costs of running my app business have been as follows:

Apple iOS Developer Program: 60.00 £
Domain Hosting: 102.47 £
Facebook Ad Campaign: 200.00 £
Outsourcing services: 408.69 £
iOS icons pack: 16.10 £
Total Expenses: 787.26 £
Total Revenue: 583.86 £
Net Loss: 203.40 £

The biggest expense has been some outsourcing work I’ve done to create UI artwork for my apps, however this was necessary to create some high quality UI elements and I’m happy with it.

Marketing

This year I have tried a few marketing strategies to give my apps more visibility. These three have been the most effective:

  • Keywords optimisation Particularly for My Oyster, the number of downloads has had a high correlation with the ranking of the keyword “Oyster” in the UK App Store. The app has been ranking third for this keyboard through the whole year and averaging 50 to 70 downloads per day.
    On one occasion it jumped up to second spot due to one of the competitor apps being temporarily removed from sale and the downloads spiked to over 300 a day as a result. This shows that direct search ranks are fundamental for user acquisition on this app.
  • Facebook advertising In an attempt to get My Oyster to the top of the UK Travel rankings, I ran a Facebook Ad campaign in the London area for 10 days, allocating 12£/day initially and spiking this to 40£/day towards the end. The campaign succeeded in boosting the app from position 200 to the top 50 in the UK Travel category, however as soon as I stopped the campaign, the ranking dropped again to its previous levels. With a cost per mobile app install of 0.12£ and an average revenue per download of 0.01£, I would have had to generate 12x more revenue per download, or decrease the cost per install by 12x in order to break even with this strategy.
  • Hacker news I have promoted Perfect Grid and Pixel Picker by sharing the apps’ iTunes links on Show HN and asking some friends to upvote them. I did this for Perfect Grid on the day after launch, managed to get 14 upvotes and stay on the Hacker News front page for a few hours, but this only resulted in 180 downloads on that day, which I presume could be attributed evenly to Hacker News traffic and the app just having gone live.
    Pixel Picker fared much better and managed to get 2200 downloads in one day, largely attributable to Hacker News traffic.

MyOysterRanks2014

My Oyster UK Travel Ranks 2014 – Source: Musevisions blog

MyOysterFacebookCampaignMay2014

My Oyster Facebook London Ad Campaign May 2014 – Source: Musevisions blog

MyOysterDonwloadsMay2014

My Oyster Downloads May 2014 – Source: Musevisions blog

PixelPickerHackerNewsNovember

Pixel Picker Downloads generated by Hacker News traffic, November 2014 – Source: Musevisions blog

Additionally I have been spreading the word about new releases of my apps on Twitter and Facebook, however I haven’t noticed an increase in downloads as a result.
Writing to bloggers to request a review for My Oyster also proved ineffective and a big time drain so I’m not going to invest more effort on this going forward.

Overall, I have been quite impressed at the number of downloads that a high traffic site like Hacker News can generate, however in my experience this only helps in getting a spike in downloads. I haven’t yet found a way to sustain high download numbers over time, other than through paid advertising which is an unsustainable model given my current ROI.

Going forward I’d like to share my apps on other high traffic sites such as Product Hunt and Reddit, as well as trying other advertising platforms.

User Engagement

So far, My Oyster is the only app that shows promising engagement metrics with around 5000 MAU and good retention rates:

APP
Period
AVG session
duration (min)
Monthly active
users
Returning
Users (%)
New users
per month
My Oyster November 6.47 5441 94.4 2116
Pixel Picker December 2.06 738 41.1 575
Camera Cube November 1.18 681 50.0 N/A
Perfect Grid November 3.05 98 86.1 N/A

Having around 640 daily active users and an average session duration of over 5 minutes, My Oyster performs much better than my other apps in terms of ad impressions and revenue.

MyOysterAdsReport2014

My Oyster Ads Report 2014 – Source: Musevisions blog

As outlined in the graph above, My Oyster received 3000 clicks at a cost per click of 0.06£. Next year I plan to experiment with Ad Networks other than AdMob to determine if a higher CPC is achievable.

Customer Support

To facilitate user feedback, all my apps have a help/about screen with an option to contact customer support via email.

One peculiar aspect of the My Oyster app is that it lets users check their Oyster card data which comes from a 3rd party website. As the content can be unavailable at times and users sometimes have issues with their accounts, some time is required to answer customer emails, so the revenues from this app aren’t completely passive.
The positive side of this is that a lot of customers get in touch with me directly and their feedback helps me improving the app over time.

As download numbers and engagement metrics are not good for my other apps and I very rarely receive emails from customers that have downloaded them, I can infer that those apps are not as discoverable as I’d like them to be and they don’t generate much interest from customers. From a business perspective perhaps I should focus on My Oyster instead and try to grow its user base and functionality.

Conclusions

As many others have noted, [tweetable]bootstrapping a consumer app business on iOS is hard[/tweetable]. My personal experience so far has been that from a purely financial standpoint this is unsustainable and I should be investing my time in something more lucrative like consulting, which at the time of writing brings in 30x to 50x more revenue per hour worked.

However, I believe there are a lot of intangible benefits in making and publishing apps:

  • They make for a good portfolio Prospective clients will be able to assess the quality of my work and my apps always help me getting jobs and consulting gigs.
  • I keep acquiring new skills Making apps is by nature a creative process, and I have the freedom to choose all the latest tools and technologies for the job at hand.
  • Full product lifecycle Making apps forces me to think about the whole product: development, UX, support and marketing.
  • Flexible workload I get to choose how much or how little I work on my apps, as well as choose what I want to work on. For me this is very valuable as I can enjoy working on these side projects without having too much pressure.
  • I get to talk at events Sometimes I feel it’s worth sharing my findings and experiences as an app developer, and this also is beneficial for building my brand and network.

Goals for 2015

In 2014 I was hoping to hit and maintain 100 £ in revenue per month. I have missed this mark by about 50%.
As most of my revenue came from the sales my My Oyster, I plan to focus on further developing this app and try a few more marketing channels to improve its visibility.

While I plan to do some more independent app development in 2015, my app business so far has struggled to take off and I feel that I could invest more of my time in other relevant activities, including:

  • Open Source development I’d like to focus more on creating small and reusable iOS libraries and components and share them with the community. I find that such projects are very well suited for giving presentations of technical nature. Additionally, I’m reading a lot of stuff on functional programming and I can’t wait to share a lot of functional stuff on my GitHub page.
  • More consulting work I see consulting as an opportunity to see what challenges companies face and work on problems that I would not have the chance to take on as an indie developer.
  • Write technical material, courses and seminars This could be a new exciting venture for me and I feel that there is a great community around iOS development and software programming in general. As I become a better developer, I’d like to share some of the lessons I learnt in a format that can be most useful to others. Further down the line, I would like to start running my own courses and seminars.

Time will tell how things will go, but I feel very privileged to be an iOS developer in 2015 I can’t wait to build more products and awesome stuff this year!

 

Which skills do you want to develop? Take the Developer Economics Survey and we will compare your skills to the global average. You can work on those skills and maybe get your lucky break.

Categories
Business Tips

Vital Metrics For Tracking Your App’s Success

Making data driven decisions is key to driving growth in your mobile app, and it’s the reason that nearly every app developer in the world integrates analytics tracking within their app. In fact, in a recent Tapdaq survey we discovered that 90% of developers have implemented a third party analytics SDK into their app[bctt tweet=”90% of developers have implemented a third party analytics SDK into their app” username=”DevEconomics”].

viral-metrics-app-success

However, we were surprised to then learn that only 5% of these developers knew what to do with the data points which they were tracking. After speaking with a large group of the developers questioned, we realised that many aren’t sure which metrics are most important, or what steps they need to take in order to improve.

As the App Store has matured, creating a chart-topping product has become a much more complex process. App analytics providers have moved with the times and now provide developers with more data than ever before on their app’s performance. In this post I am going to pick out 12 app metrics and explain why they are the most important data points when tracking your app’s success.

Acquisition

Growth of your app business starts at the user acquisition stage. Here there are several key questions which all developers ask themselves.

How many installs have I generated?

Tracking installs received as an overall figure is very easy, and all data is provided through iTunes Connect/Google Play.

How much have these downloads cost?

You have to know what your cost per install (CPI) is when paying to acquire new users to your app. [tweetable]If your CPI rises above the value of your user’s lifetime value (LTV), then the campaign is unprofitable[/tweetable] and unless you are propped up by strong organic install numbers, your business is going to struggle.

Working out your cost per install on mobile ad networks is straightforward, and nearly all networks now give this figure to you up front. If you are acquiring users via cost per install ad networks then I’d recommend you test multiple platforms, providing you have a large enough budget. In an interview with KISS Metrics, Wooga’s head of marketing, Eric Seufert, said the company used 23 ad networks to get their Jelly Splash game in to the top charts of the key markets.

Where did these downloads come from?

When you see a spike in your app’s downloads, the first thing you want to know is where they came from. By using install attribution tools you can see a breakdown of all your installs by referral source, which gives you far stronger idea of which networks can send you the greatest volume of users for the lowest cost.

How high a quality are the users within my app?

This question can’t be answered immediately, but, over time, [tweetable]cohort analysis can help you to get a better understanding of the quality of the users [/tweetable]within your app. Specifically, when working with multiple paid traffic sources, you can work out which platform provides you with the most real value beyond just the install itself.

For example, Ad Network A might have sent you 10,000 installs for $20,000, whereas Ad Network B sent 10,000 installs for $15,000. If looking at the CPI alone, logic would say that Ad Network B is the preferred choice here. However, using cohort analysis you may discover the users from Ad Network A have an LTV of $2.50, whereas the users from Ad Network B only have an LTV of $1.50. So, in terms of real value, Ad Network A would actually be the optimal solution.

Engagement

In mobile analytics, the fun really starts after the install. With app engagement there are multiple metrics that need to be tracked in order to paint a picture of how engaged your users really are.

Session Length

Tracking your session length is not as straight forward as it sounds. Different analytics companies have different definitions when it comes to sessions. For example, Flurry deem a session to start when an application is opened, and end when the app is terminated. By default, a session is ped as terminated if a user leaves the app for more than 10 seconds, although this logic can be changed.

In contrast, Google Analytics only consider a session to be over after 30 seconds of inactivity, although again this can be customised to any required time.

app-success-4

They key takeaway here is to ensure you know exactly how a session is defined within your app, as the definition does vary depending on who your analytics provider is.

Time in App

This is a marketing metric that is sometimes confused with session length, and is also often classed as a retention metric.

Where session length describes how long a user’s individual session lasts, time in app is used to define how long a user spends within an app, in total, over a given length of time. For example, a user could spend 2 hours in an app over the course of a week, and this could comprise of multiple sessions. The more time a user spends in your app on a daily basis, the better your chances are of monetising that user.

Popular Pages/Features

Understanding which pages and events are most popular in your app helps you paint a better picture of which content is most valuable to your users. More importantly, it also highlights weaknesses too. By tracking your page visits and conversion funnels you are able to see exactly where users drop out from your app, and this enables you to make data driven decisions on what content to improve in order to get more users reaching the ‘aha’ moment in your product.

Retention

It is argued that user retention is what sets apart a top grossing app from its competitors. Whilst user engagement tracks how long users spend within your app, user retention focusses on how often customers visit your app. It’s worth bearing in mind that a digital product can be a huge success, even if engagement is low, providing retention rates are high. For example, Google is a very successful tech company with sky high retention rates, yet engagement is relatively low.

Let’s take a look at the most important engagement rates you need to be tracking…

Retention Rate

User retention rate can be calculated in a number of ways. However, probably the most popular method is rolling retention (which is actually the default method used by Flurry Analytics).

To calculate this, you need to look at the proportion of users returning to your app on Day+N, or any day after that, and dividing it by the number of users who had installed your app on Day 0.

Here’s a great graphic from the Applift blog that summarises this calculation…

app-success-3

app-success-5

app-success-6

It’s going to be very interesting to see exactly how powerful Apple make their analytics tracking within iTunes Connect. A sneak preview has been posted on the AppTweak blog, showing a screenshot of a cohort table used for tracking retention…

app-success-2

Daily and Monthly Active Users

[tweetable]Your daily and monthly active user count is another measure of just how ‘sticky’ your app is[/tweetable]. Over time, successful apps look to grow the gap between their daily downloads and their daily active users, and they do this by ensuring they add as much value to their customers as often as possible.

Again, both these metrics are heavily tied with engagement. The more engaging the content is within your app, the more likely it is you will retain your users. The more often you can provide them with value, the higher your DAU count will be.

Churn rate

User churn rate is a key metric to understand, particularly when you come to calculating your user lifetime value (LTV). Churn rate is the opposite to retention rate and is the measure of how many users stop using your app over a given period of time, usually a month.

Churn rate is expressed as a percentage of the number of people who could have left and it is not possible for customer churn to be 0% or lower. An example would be: If your app has 100 users, then 100 people could leave/stop using your app this month. At the end of the month, only 23 users stop using your app, so this means you have a churn rate of 23%.

Monetisation

Average Revenue Per User (ARPU)

This metric is often confused with LTV, but it’s actually a far simpler data point to track. ARPU is the revenue you generate, on average, from each user of your application, and this can be calculated by simply adding up the revenue your app generates each month, and dividing it by your total number of users.

LTV

Lifetime Value, often shortened to LTV, is the measure of the revenue a customer will bring during their lifetime of using your application. In our recent Tapdaq survey, amazingly all 60 of the developers we spoke to said it was the most valuable metric in app marketing.

To calculate the LTV of one of your users there are several data points you need to know. They are:

  • Customer Churn: As described above…
  • Income: This includes all revenue from In-App Purchases and subscriptions, after Apple has taken their 30% cut, and any income from selling advertising space within your applications.
  • Number of active users: This one’s fairly obvious, it’s the number of active users your application has. The definition of what a “user” or “active user” is will vary depending on your application and your business model. If you have a mix of active users where some generate income and some don’t, include them all. This mix will likely continue as your app grows.
  • Average Revenue Per User (ARPU): As described above…

Once you have collated all the numbers above, just plug them into the equation below to discover the average LTV of your users.

app-success-1

App Success Sum Up

There are quite a number of important metrics that you need to be tracking and improving upon in order to make your app a true success. Always be looking at the wider picture, and evaluating how each metric has an effect on one another. If your team is small, or you are an indie developer working alone, then I’d recommend starting by iterating your product with the focus on increasing engagement, retention, and your average user LTV. You don’t need to have millions of users on board in order to build a truly great mobile app. Test heavily, and make data driven decisions in order to position yourself in a place where you can start to invest in acquisition with the confidence in your product’s quality and monetisation.

Categories
Languages Platforms Tools

Comparison of 4 popular JavaScript MV* frameworks (part 1)

Finding a comprehensive comparison between any kind of JavaScript Frameworks, Libraries or Extensions is not hard these days. Especially when it comes to JavaScript MV* Frameworks, which are used to develop single-page applications (SPAs), and their notorious representatives, i.e. AngularJS, Ember, Backbone.js and newcomer React. A simple Google Search offers a plethora of technical comparisons to choose from.

mv-frameworks

Which are your favorite and worst frameworks? Take the survey, let us know and you can win awesome prizes and gear.

What they don’t usually mention, though, is the overall features those frameworks provide and how they compete for different use cases. Moreover, it is sometimes difficult, if not impossible, to find information on the origins of those Frameworks, i.e. how they have developed in time and, most importantly, how they will develop in the future.

This article is part 1 in a 2-part series, and will focus on comparing key features from some of the leading JavaScript MV*frameworks. In part 2, we’ll give you some insight on market-related qualities, followed by a conclusion.

Features Comparison

To get our comparison started, we will focus on the heavy-weight and most promising features you, as a developer, expect from a JavaScript MV* Framework.

Dynamic UI Binding

Dynamic UI Binding is not just passing data to our View or template at page load. You want to automatically have the View update when the data of the underlying Model changes. That being said, you may want to have a look at the following jsfiddle examples to get an idea of the huge improvement provided by dynamic UI binding over traditional server-side static data binding.

Ember.js:

Ember uses Handlebars as the default templating engine. To update a value, which is bound to the UI, you have to use a specific setter method on your Model while Handlebars takes care of rendering your page. Additionally, Ember offers much more binding options, such as its capability to have your Model in either a one or a two-way binding mode between a View or even another Model.

Angular.js:

In contrast with Ember’s approach, Angular.js allows you to use UI binding at plain object or even property level. At the end of every code execution, $scope.$apply() is run to check whether the value has changed and calls $scope.digest() to update your bindings. This may seem like a possible performance issue at first glance, but bear in mind that it allows you to update more than one binding simultaneously without requiring time-consuming DOM updates after each setter call. So the DOM rendering is triggered only once after you updated as many of the Model’s properties as you wish rather than being triggered after every single value change, like in Ember’s setter approach. Having all the magic happen in $scope.$digest() you don’t need to call your UI-Binding-Buddy yourself and even the $scope.apply() call is handled by Angular automatically (e.g. after events, controller init, http callback, etc).

React:

One of React’s rich UI Features is the straightforward linking of states directly to the UI. Since the UI is thought of as the representation of different states of a React Component, you just have to manage your states with the magical #setState(state, callback) method. The state parameter is passed as an object and will be merged into the internal state reference of your React Component. Meanwhile, React takes care of all the updating and re-rendering of your interface using the render method. The callback parameter from setState is optional and can be registered so you are informed after the UI update.

Reusable Components

While all frameworks provide out-of-the-box functionality, you will inevitably end up with a lot of custom code. Assuming you are developing more than one applications, you would like to be able to reuse that code, right?

Ember.js:
Ember is making use of a widget-based approach called Ember Components. It enables you to write your own ‘application-specific HTML tags’ using a Handlebars layout and the power of Ember’s backend infrastructure. Your custom element can be used in any Handlebars template you want. Keep in mind, though, that this is only possible at View level, while Controller level reuse is not supported by the Framework.

Angular.js:
Similar to Ember, Angular.js provides the ability to create custom HTML tags. Reusable components in Angular are called “directives” and are significantly more powerful than Ember Components. In fact, you will be able to create your own semantic and reusable HTML syntax using those directives. On the other hand, you may also make use of Angular’s extend or mixin system like in Backbone.js and React.

Backbone.js and React:
The way Backbone.js and React solve reusable components is not new, yet it is very reliable. They both use the mixin system for code reuse. You may know this feature already from the dojo toolkit and might remember how powerful mixins can be. Both Backbone and React let you use mixins at view or even controller level, so that your components are not forced to be UI-related and may contain just some utilities or even complex program logic.

Routing

The simplest routing infrastructure a MV* JavaScript Framework can offer is mapping functions to URLs, similar to their server-side relatives (e.g. Grails, Spring, ASP.NET, CodeIgniter). For Single Page Applications (SPAs) a URL is whatever follows the hashtag (or might even be full path assuming HTML5 push-state is enabled). This routing functionality is essential for any self-respecting SPA.

Ember.js:

The routing in Ember.js is quite intuitive, since you do not even need to provide a path for your route, as long as you follow the naming convention. You just provide the View and an optional Model to the route and there is no need for any kind of controller (as exhibited in the Fiddle above), unless you are planning to do some advanced stuff in your application.

Angular.js:

In contrast to Ember’s convention-over-configuration routing mechanism, Angular.js requires a template and even a controller to its router configuration. You have to manage your template and controller manually – but you can do that almost without restrictions.

Backbone.js:

Similar to Angular.js you provide a View with a Template for your route. The actual replacement of the DOM is done manually by instantiating the View and updating the DOM in your container node with the rendered view template. At the end of your routing configuration you just have to tell Backbone to listen for URL changes with the command Backbone.history.start().

Pit Stop – Concluding the Feature Comparison

It is quite unfair to compare React with the likes of Ember, Backbone and Angular. First and foremost, React is new, while the latter are already established frameworks in the MV* universe. Secondly, React is not a framework, but rather a View engine – even though it competes extremely well in terms of features. In fact Facebook explains it better: “React is mostly used as the V in MVC”.

Let’s look again at our JavaScript MV* candidates.

Backbone doesn’t provide UI binding and does a really good job at reusable, components but loses some of its fanciness when it comes to Routing. Ember offers a slick routing mechanism, keeping things clean and simple by introducing naming conventions. Its UI Binding concept and use of Handlebars, which provides you with very nice benefits, is flawless. The only thing Ember lacks is the reuse of components at Controller level.

To conclude, Angular is our winner – so far. The approach of extending HTML with custom syntax, the easy-to-use data binding features combined with the power of mixins or extends and a clear routing mechanism makes Angular more than just a swiss JS-Knife. With its high abstraction level and a bunch of features it may be the choice for a full featured CRUD application – client sided.

Stay tuned to find out more about how our rivals compete in market penetration, community support, their estimated future usage and, of course, our final conclusion to help you back the right horse for your SPA.

 

In the meantime, tell us more about what you love or hate for each framework and you might win cool gear. Take the Developer Economics Survey.

Categories
Platforms

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.

app-store-growth-1

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

app-store-growth-2

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-store-growth-3

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:

app-store-growth-4

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

app-store-growth-5

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.

app-store-growth-6

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:

app-store-growth-7

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.

app-store-growth-8

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.

Categories
Tools

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:

using-ad-libraries

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).
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.
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.
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)

Categories
Tools

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.

prototyping-tools-developer-economics

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.

Prott Web UI
Prott Web UI

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.

Quartz Composer with Origami
Quartz Composer with Origami

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.

Form Mac App
Form Mac App

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.

Pixate Web UI
Pixate Web UI

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.

Proto.io Web UI
Proto.io Web UI

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.

Framer Studio Mac App
Framer Studio Mac App

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.

Categories
Business Community

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.

Βlueprint of the app economy preview 4

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.

Categories
APIs

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.

sdks-de

– 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:

  1. Compute nodes (Start / Stop instances or configure)
  2. Data Volumes (Creating / Attaching / Delete volumes, snapshots etc.)
  3. Load Balancers
  4. 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 Azure
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.

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.

cloud-providers
community-statistics-comparison

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?