Categories
Tools

API Management tools: How to find the one for you

Launching an API is hard. You need to make sure your service is reliable, secure and well-documented. This is where API Management tools come into play. They provide the means to expose your API to external developers in an easy and affordable manner. One of the best definitions of API management is the one introduced by APIacademy:

But first, let us know which are YOUR favourite API management tools. Take the Developer Economics Survey and you may win amazing prizes and gear.

api-management

“Creating a centralized API architecture that makes the process of composing, securing and managing high-performance interfaces significantly simpler and more consistent.”

Features of an API Management service

API management services have a multitude of features. Their main focus is to make designing, deploying and managing an API easier, as well as to ensure that it is safe, secure and functional. Some of these tools facilitate integrations, transformations or API orchestrations. Ideally, an API management service should at least cover most of the below basics:

  1. Documentation – Sounds boring, right? Still, one of the most common problems of developers is figuring out how an API works. Development time is too precious to waste in trial and error of an undocumented API. An API management service has to provide an easy way to read the documentation and enable developers to “try before they buy”. In some cases it is even possible to provide interactive documentation. Simplicity and usability are the keys!
  2. Analytics and Statistics – It is critical to understand how people use your API and get insights for your business.
  3. Deployment – Should be flexible and support public or private clouds, on-premises implementations, or combinations.
  4. Developer engagement – Engaging with your API consumers, developer or partners is important. Getting an easily accessible developer portal will significantly facilitate onboarding.
  5. Sandbox environment – This feature will increase both the value of an API and its adoption rate. What better than being able to develop and test your code.
  6. Traffic management and caching abilities.
  7. Security – APIs carry sensitive data, so it is important to protect the exposed information. The service has to at least provide identity and access management for users and developers.
  8. Monetization – Provide the capability to monetize your API.
  9. Availability – Should be available, scalable and redundant. An API environment can become demanding and the service should be able to deal with any kind of errors, problems or temporary traffic spikes.
  10. Support of Legacy systems.

To Proxy or not to Proxy?

The vendors in the API management space provide a number of solutions across the above main categories but that does not mean they support everything. They are implementing their solution in three different ways: Proxies, Agents or Hybrid.

  1. API service providers that use the concept of a Proxy. Their solution “sits” between the customer and their users and the traffic goes through them. Proxies provide caching capabilities and protection of customer’s back-end infrastructure from traffic spikes. The main criticism they receive is that they increase the cost and bring up privacy and latency issues. Apigee, Mashape and Mashery are examples of such implementations.
  2. API service providers that use the concept of agents. Agents are plugins that integrate with your server. They do not get in the way of the API calls like proxies. As a result they do not introduce network latencies or 3rd-party dependencies. On the other side, features like caching are not easy to implement. 3scale is an example of such implementation.
  3. API service providers that use a hybrid approach. This means you may get an agent and a proxy. For example you may want to use a proxy for the caching and the agent for authentication. Companies like Apigee or 3scale we talked before are also moving to hybrid solutions.

13 API management tools

Deciding on an API Management Tool, you are faced with lots of choices. Available solutions may focus in one or two or cover many of the features discussed above and vary greatly in price. There are tools that were acquired by bigger vendors like Intel or CA or Microsoft. Open source tools are also available. Last but not least, some tools are heavy enterprise focused and other much less so.

Name Type License Stackoverflow questions Market segment Strong Points
3scale Agent, Proxy Commercial 15 Startups to Enterprises Wide range of tools
ApiAxle Proxy GPL 9 SMBs to Enterprises
Apigee Proxy Commercial 598 SMBs to Enterprises Powerful Analytics
Axway Proxy Commercial 9 SMBs to Enterprises
CA Layer7 Proxy Commercial 35 Enterprises Advanced support for mobile applications
IBM API Management Agent, Proxy Commercial 17 Enterprises Large Scale, User friendly
Mashape Proxy Commercial 106 Startups to Enterprises Monetization, discoverabilty
Mashery Agent, Proxy Commercial 57 SMBs to Enterprises API strategy services
Microsoft’s Azure API Management Agent, Proxy Commercial 262 Startups to Enterprises
MuleSoft Proxy Commercial 134 Enterprises Based on proven open source technology, programmableweb
Oracle SOA Proxy Commercial 213 Enterprises Large scale, SOA
Akana (formely SOA Software) Proxy Commercial 3 Enterprises
WSO2 Agent, Proxy Apache 4421 Startups to Enterprises Open source

3scale

3Scale is very active on the API management space with a wide range of customers, ranging from startups to enterprises. They provide a hybrid solution to help you deploy, manage, distribute and monitor your API. They offer an on premises API management solution along with cloud based API administration, analytics, reports, developer and partner portal.
More about 3Scale: http://www.3scale.net/api-management/

Mashape

Mashape does not offer an API Management service per se. They provide important features that are part of such services though. You may test an API, generate code, and get a developer portal and user management. Most importantly they provide out-of-the-box monetization, a developer community and discoverability through their API marketplace.
More about Mashape: https://www.mashape.com/

Microsoft’s Azure API Management

Microsoft’s Azure API Management became available to the public rather recently. You can provide and manage an API, get developer portals, documentation, security management, performance management, statistics and analytics. They have on-premises and cloud versions (not limited to the Azure cloud).
More about Azure API Management: http://azure.microsoft.com/en-us/services/api-management/

Apigee

Apigee provides a range of services, from free API tools for developers to large API management solutions for enterprises. Their solution can be deployed in the cloud or on-premises. They offer API analytics, developer portal, transformations, traffic and performance management. Apigee seems to provide the richest API analytics platform compared to other companies. In mid-2014, they launched the new version of their big data predictive analytics platform.
More about Apigee: http://apigee.com/

Mashery

Mashery is an Intel company since 2013. They provide an all-around API management solution that supports SaaS and on-premises implementations as well as a few hybrid oriented ones. Their services cover from API technology and infrastructure to business strategy.
More about Mashery: http://www.mashery.com/api-management

CA Layer7

Layer7’s API Management is heavily enterprise directed. They offer on-premises and cloud deployment solutions. Their services range from integration, security management, performance management, mobile API gateways, mobile optimization and developer portals. CA’s support for mobile applications is considered to be more feature reached compared to other solutions.
More about CA: http://www.ca.com/

IBM API Management

IBM’s solution comes either as on-premise or cloud hosted. It covers a lot of the API management needs of a large company and it is considered a much user-friendly platform.
More about IBM API Management: https://apim.ibmcloud.com

Oracle SOA

Oracle provides an API Management solution that consists of its API gateway and SOA suite. The API gateway is used for securing and managing APIs and as a first line of defense in SOA environments.
More about Oracle SOA: http://www.oracle.com/us/products/middleware/soa/api-management/overview/index.html

MuleSoft

MuleSoft’s solutions is based on open source technology. They offer easy API design, advanced integration and testing features. It is widely used and they also work a lot with developer communities.
More about Mulesoft: http://www.mulesoft.com/

Akana (formely SOA Software)

They provide a unified Enterprise level API management and SOA Governance solution. It can be implemented on-premises or in the cloud. They offer a horizontal solution from design and building an API to policies, security and lifecycle management.
More about SOA Software: https://www.soa.com/solution/api-management

Axway

They offer an API Gateway that provides everything you need to develop, integrate and manage APIs. They provide security management and of course an API Portal for developers and partners.
More about Axway: http://www.axway.com/en/enterprise-solutions/api-management

WSO2

WSO2 is considered the most complete open source solution today. It covers API integration, management, identity and mobile. It supports public, private clouds, and hybrid implementations. WSO2 follows an open development process, where customers can provide input.
More about WSO2: http://wso2.com/

ApiAxle

It is an open source API management and analytics solution. It is a proxy that sits in front of your API and manages caching, security, performance and traffic. As an open source project, you may contribute to its code base.
More about ApiAxle: http://www.exiconglobal.com/apiaxle/

Epilogue

Not all companies launch API programs and not all API programs have the same goals. Some APIs are used as a revenue model or part of a product or service, others are free. Certain APIs are used to provide access and information to an ecosystem of companies. As the requirements vary, the tools diversify. So choose your API strategy and pickup the right tool.

 

Which are your favourite tools? Let us know and shape the future of developer economics. Take the survey.

Categories
Business

Developer Corner: Why successful indie developers are becoming a dying breed

I started developing iOS apps 5 years ago, which can be loosely equated to 50 years in a different, non-tech industry, where the pace of growth is much slower. As a sign of the warp speed at which things are moving within the app economy, simply consider that when I started, back in 2010, there were only 300.000 apps and those were only in the Apple App Store; right now there are over 3 million apps across all stores, which goes to show the phenomenal pace with which the app economy is skyrocketing. During this time I’ve developed over 12 apps at Anlock as an indie dev, which have seen 2 million downloads, and more than 4.000 reviews with an average rating of 4.0 across 110+ countries.

indie-devs

Aside from app development, I’ve also been very active in the kids’ educational developer community, starting as a member of Moms with Apps in 2011. Later, I co-founded the Know What’s Inside™ program, dedicated to helping family-friendly app developers implement best practices around privacy and complying with privacy rules. And for many years I was head of the App Friday program, which was created by family-friendly app developers who simply wanted to raise visibility around kids’ educational apps.

Due to this active involvement, I have seen many fellow indie developers come and go. At first, some of them made it big for no reason that I could fathom, but later, as the industry matured, it became increasingly harder to succeed and a very small number of indie devs actually made it. [tweetable]Success in the app industry is the product of hard work and continuous efforts[/tweetable], and most of the indie devs I know eventually tire out and throw in the towel; a couple of months ago it was my turn.

Because of this extremely fast pace with which the industry is growing, I have always been on the edge, trying to cope with the curveballs the App Store has been throwing. At the beginning, the challenge was simple – all you needed to do to succeed was put together a decent app that was centered around the revolutionary concept of users interacting with content through touch on their phone screens. Soon the challenge shifted and the focus was on having appealing graphics and marketing your app. Very quickly, marketing become predominant, if you did not have a marketing plan in place before you even started developing your app you had no chance. At the time, that meant actively using Facebook (before its IPO, when posting was free), Twitter, YouTube, cross-selling between apps, etc.

And then, a few months ago, I realized that the last curveball the market had thrown was beyond our small team at Anlock. Having a good idea for an app, a good UI/UX execution with excellent coding skills and a marketing plan was simply not enough any more. The app idea itself had to be exquisite and its UI/UX execution brilliant to even have the slightest chance of success. Which absolutely makes sense when you consider there are 3 million apps out there. Of course there will always be Flappy Birds that are beyond “logic” and hit a nerve with users and go viral, but that is one app in 3 million, quite literally.

As far as I was concerned, [tweetable]the app market has just reached that hyper-competitive stage[/tweetable] that was simply beyond our team at Anlock, despite our years of experience, our extensive app portfolio and our 2 million downloads. So, when the opportunity presented itself I opted out and left Anlock.

There I was with 5 years of solid iOS development faced with either having to start all over again in a hyper-competitive market or get a job as a freelance iOS developer. Having closely followed the debate about tech talent shortage the past year I decided to go freelance.

It only took me about a month to realize that are a lot of job openings out there and I actually got to pick the role I found most fascinating and challenging. I have now joined Daredevil Project that “makes mobile social games for the ‘real word’”, in charge of the iOS development of Duel that will be launched in the coming months, effectively putting an end on my indie years … for now at least!

Categories
Platforms Tools

Top 5 Tools for Augmented Reality in Mobile Apps

tools for augmented reality

Augmented Reality (AR) is about overlaying pieces of a virtual world over the real world (in contrast to Virtual Reality (VR) that is about replacing the real world with a virtual one). On mobile devices, this simply means enhancing what you can see through the device’s camera with multimedia content (e.g. you can point your camera at a movie poster and watch its trailer, or you can point it at a star in the sky and learn its name). So, basically [tweetable]AR comes down to the following three fundamental questions: where to display what and how[/tweetable].

augmented-reality-Final

But first: which are YOUR favourite tools? Take the Developer Economics Survey and you could win new, amazing gear.

The where might involve areas like 2-D image matching and tracking, 3-D object matching and tracking, face detection and tracking, SLAM tracking, and location tracking (using GPS, accelerometer, compass, gyroscope). Sometimes the where is nothing more than some predefined point locations, often referred to as Points of Interest (POIs).

On the other hand, the what and the how might leverage 3-D model rendering, animations and gesture detection. In general, the what can be any piece of digital information (e.g. text, image, video) that the user might also have the ability to interact with (e.g. rotate or move it).

Top 5 Tools for Augmented Reality

Let us now present five of the numerous AR tools that exist at the moment and that can be used to develop apps for smart-phones, tablets or even smart-glasses. The following table contains information about the license(s), under which each one of these tools is distributed, and the platforms that it supports.

Product Company License Supported Platforms
ARPA SDKs Arpa Solutions Commercial* Android, iOS (ARPA SDKs), Google Glass (ARPA GLASS SDK), Android, iOS, Windows PC (ARPA Unity Plugin)
ARLab SDKs ARLab Commercial Android, iOS
DroidAR – Free and Commercial Android
Metaio SDK Metaio Free and Commercial Android, iOS, Windows PC, Google Glass, Epson Moverio BT-200, Vuzix M-100, Unity
Vuforia SDK Qualcomm Free and Commercial Android, iOS, Unity
Wikitude SDK Wikitude GmbH Commercial* Android, iOS, Google Glass, Epson Moverio, Vuzix M-100, Optinvent ORA1, PhoneGap, Titanium, Xamarin

* There is also a free trial available.

ARPA SDKs

Image (multi-)detection and (multi-)tracking, 3-D object rendering in real time, as well as user interaction with 3-D objects (e.g. selection, rotation, scaling) are some of the features that ARPA SDK offers for building AR apps on iOS and Android. ARPA GPS SDK complements ARPA SDK with geolocation-based AR functionality: it allows you to define your own POIs that, when detected, the user can select them and get more information about them or even perform actions on them (e.g. the “take-me-there” action that displays a map with directions to the selected POI). ARPA GLASS SDK and ARPA Unity Plugin offer similar functionality with ARPA SDK for Google Glass and the Unity game engine, respectively. It is worth noting that Arpa Solutions, the company behind these SDKs, have over the years developed their own AR platform, some of the features of which (e.g. face recognition and virtual buttons) might at some point be transferred also to the SDKs.

Update Oct 7, 2015: ARPA website has gone offline – their domain name, i.e. arpa-solutions.net seems to have expired.

ARLab SDKs

With AR Browser SDK you can add and remove POIs independently from the scene in real time, interact with them (e.g. touch them or point the camera to them) and perform actions on them (e.g. send SMS or share on Facebook). Image Matching SDK allows you to create your own local matching pool with thousands of images (loaded both from local resources and remote URLs), and use it to match any image without any connection to the internet, while it also supports QR code and barcode recognition. Except for these two SDKs, ARLab will soon launch Object Tracking, Image Tracking and Virtual Button SDKs. All SDKs are available for both Android and iOS.

DroidAR

DroidAR is an open-source framework that adds location-based AR functionality to Android apps. Gesture (e.g. full turn) detection, support for static and animated 3-D objects (using the model loaders from the libGDX game development framework) that the user can interact with (e.g. click on them), and marker detection are part of the functionality that DroidAR offers and that is only shaded by the poor documentation that exists for the project. There is a section on the project README file on GitHub that gives an overview of a closed-source version of DroidAR, DroidAR 2, which seems to have some interesting enhancements compared to its open-source counterpart (e.g. SLAM tracking and a jMonkeyEngine plugin).

Metaio SDK

Metaio SDK supports among others 2-D image, 3-D object, face, SLAM and location tracking, barcode and QR code scanning, continuous visual search (both offline and online through Metaio CVS), and gesture detection. Metaio has also designed their own AR scripting language, AREL (Augmented Reality Experience Language) that allows you to develop your AR apps using common web technologies (HTML5, XML, Javascript) and deploy them everywhere. Metaio SDK can be used to develop AR apps for Android, iOS, Windows PC, Google Glass, Epson Moverio BT-200 and Vuzix M-100 or using Unity.

Vuforia

Multi-target detection, target tracking, virtual buttons, Smart TerrainTM, and Extended Tracking are some of the features of Vuforia SDK. Vuforia supports the detection of several kinds of targets (e.g. objects, images, English text). Especially for image recognition purposes Vuforia allows apps to use databases that are either local on the device or in the Cloud, The platform is available for Android, iOS and Unity. There is also a version of the SDK for smart glasses (namely Epson Moverio BT-200, Samsung GearVR, and ODG R-6 and R-7) that is currently moving to its beta phase and is open for early access applications from qualified developers.

Wikitude AR SDK

Wikitude AR SDK supports image recognition and tracking, 3-D model rendering and animations (supports only the Wikitude 3-D format), video overlays, location-based tracking and image, text, button, video and HTML augmentations. Wikitude AR SDK is available for Android, iOS, Google Glass, Epson Moverio, Vuzix M-100 and Optinvent ORA1, and as a plugin for PhoneGap, a module for Titanium and a component for Xamarin.

To sum up

There are apps that allow a museum exhibit to tell its own story, that help you decide which furniture looks better in your living room, that bring an elephant you just drew on a piece of paper into life, or that warn you about all the signs you ignored while you were driving. These are examples of already available apps that provide some sort of AR functionality. So, pick one of the AR tools we described above (or one we didn’t, e.g. AndAR, ARmedia SDK, BeyondAR, mixare) and use it to integrate AR in your own apps.

Read more about the differences between AR and VR!

What do you like or hate about these tools? Take the Developer Economics Survey and win new, amazing gear.

Categories
Business Platforms

How to Make More Money with Enterprise Apps

enterprise apps

According to our latest developer research, 20% of mobile app developers primarily target enterprise apps. This decision produces a significant boost to their revenues, with 43% making more than $10K per month versus 19% of those who target consumers above the same revenue level. Similarly at the $100K+ per month revenue level we have 18% of developers who target enterprises versus just 7% of those who target consumers. Aside from selling to businesses, government or non-profit organisations rather than consumers, what are these developers doing differently?

profiling-enterprise-app-devs

Custom apps

Although it’s far from the only thing developers are building to sell to enterprises, 64% of enterprise app developers are making enterprise-specific apps. In some cases this will be apps that are common to a particular vertical that are either re-skinned or sold as part of a service offering. In other cases these will be entirely custom apps designed and built for one company. Automating or streamlining parts of business processes that naturally happen away from a desktop computer via mobile apps can enable significant efficiency savings that businesses are very willing to pay for. Allowing developers to do more of their work whilst mobile can also improve productivity and company efficiency. This type of development can also cover apps that are explicitly designed to help make more money, for example, sales aids, such as product visualisation or demonstration solutions.

The second most popular category for enterprise developers, at 52%, is business & productivity tools. This is likely to include typical cross-vertical apps for functions such as human resources, customer relationship management and accounting. Also, 20% are making more general utilities and 17% are developing communications and social networking apps for enterprises. In the latter case we see [tweetable]some of the innovation in the consumer apps space being brought to the business world[/tweetable].

Globo_03

Better revenue models

Enterprise app developers have a very different mix of revenue models to consumer app developers. By far the most popular revenue model, used by 49% of enterprise developers, is contract work. Part of this is the bespoke app development discussed above but even those selling products into enterprises will often have a significant customization component. In general, the larger the company, the more likely they are to have complex integration needs for a new software product. Subscriptions, in the form of Software-as-a-Service is the fastest growing segment of enterprise software spending and 27% of enterprise app developers are already using this model. Moving software to the cloud, where upgrades and maintenance are continuous and shared with other users, makes a lot of sense for most businesses. Once key software a business uses is in the cloud it’s often highly desirable to have it accessible from mobile devices too, giving SaaS providers with a strong mobile offering a major advantage.

It’s not so surprising that we have to wait for 3rd place in the revenue models list to find app store sales, with 21% of enterprise developers using it. Indeed, although Apple has special volume discount programs for businesses and schools, it’s slightly surprising that the percentage is still so high. For some SaaS offerings, the mobile client or extra utilities to interact with the service are paid extras. This will probably reduce as mobile support becomes the norm rather than a differentiator. App stores for businesses and education are probably still working as discovery mechanisms for some too. This is also likely to reduce, just as the consumer app stores became so full that it’s almost impossible for most apps to get noticed, so will enterprise app stores. Also higher than average in terms of preference for enterprise app developers are selling physical goods and royalties & licensing. Having an app as a component of a larger hardware product is increasingly popular. A tablet can be incorporated into all kinds of kiosk or point of sale systems. Developers can then capture some of the value of the software through higher margins on the hardware. Alternatively, high value software is often sold to enterprises on a per-seat or per-device licensing basis – mobile is no exception. For high value software where sales are typically made directly it’s entirely sensible that this is done as a licensing deal rather than sold through an app store with the store owner taking a cut.

More platforms, much more web

Enterprise app developers are more likely than average to support each of the major platforms. The majority of them support Android and iOS. Most also support at least one other platform too, with the mobile browser and Windows Phone being the top candidates for that. When we look at priorities though, the picture is slightly different. [tweetable]Enterprise developers are slightly more likely to prioritise iOS than average[/tweetable] (with 33% doing so versus 31% for all developers) and slightly less likely to prioritise Android (39% versus 42%). When we consider only full-time professional developers though, these differences are not significant. The major differences are further down the platform mindshare list, with enterprise app developers being significantly more likely to target and prioritise the mobile browser. Also, whilst they are slightly more likely than average to target Windows Phone, they are less likely to prioritise it. Overall the platform picture is one where more platforms must be supported to serve enterprise clients and there’s a heavier emphasis on the web.

Heavier tool users

In order to support more platforms, enterprise app developers turn to cross-platform tools much more frequently than their consumer app developing peers. 41% of them are using cross-platform tools to reduce the cost and complexity of supporting multiple platforms. However, it’s not just cross-platform tools that are more frequently used to create enterprise apps. Other important tools are push notifications (28%), crash reporting (28%) and mobile Backend-as-a-Service (18%). User analytics, at 46%, is still the most popular tool amongst enterprise app developers, as it is in the developer population as a whole, although used slightly less than average. Heavy use of user analytics and crash reporting tools suggests a greater emphasis on quality. Push notifications are key workflow and efficiency enablers, providing access to timely updates and the latest info available at a glance. Last, but not least, mobile Backend-as-a-Service lets developers rapidly build out cloud services to accompany their apps. The features of these BaaS solutions for enterprise apps are likely to become increasingly differentiated from those designed for consumer apps. Most legacy backend systems were designed before mobile access was even a consideration and they often aren’t very suitable for direct interfacing. We expect to see significant growth over the next 5 years or so for solutions that can simplify the integration of legacy systems whilst enabling rapid development of mobile apps. Where we’ve seen consolidation in the consumer tools sector giving rise to mega-SDKs for solving multiple needs, it’s not surprising that several enterprise focused tools vendors are already covering most of these developer needs in a unified package.

Enterprise developers clearly have slightly different tools and tactics from consumer app developers for good reasons. Consumer app developers looking to switch their primary audience in search of better revenues should re-evaluate what they build, how they build it and how they sell it.

Categories
Tools

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

javascript mv*

In the first part of our JavaScript MV* framework comparison we introduced AngularJS, Ember, Backbone.js and the newcomer React, we showed some code examples and discussed their strengths and weaknesses. In this second part we are going to have a look at their market share, community support and estimated growth to help you make the right decision for your SPA.

Javascript frameworks

Market Study

The following table lists the 4 frameworks alongside the year they were introduced, their origin or enduring dependency, their main contributors and an overview of popular sites using them. It’s worth noting that every single one of these frameworks is run by (or mainly used by) one of the big players of the web:

  • Ember is used by Yahoo!
  • Angular powered by Google
  • Backbone is used to realise WordPress.com and is a part time project of Jeremy Ashkenas, currently employed by the New York Times
  • React is introduced and powered by Facebook

While the bare listing clearly illustrates project maturity it does not give any indication about general popularity. Stats generated by web crawlers are usually not very accurate when it comes to back-end frameworks, but in our case – where frameworks are client-side and, needless to say, detected by every web client – those stats can be pretty sound.

Comparing wappalyzer.com with similartech.com and builtwith.com we received significantly different results. To display the results in a more convenient way we recalculated the total numbers to relative percentages. According to builtwith.com, React is used 74 times in the TOP 1 million websites while wappalyzer.com detected 18.582 usages in the entire web for the same framework as of this date. Still, it is possible to get a general idea of the market penetration of these Frameworks. All sources show Angular and Backbone being by far the most used frameworks – similartech.com does not even list the other two since their marketshare is too small to bother. Interesting to note that Backbone.js is used more in the Top 1K sites than in the Top 1M sites according to builtwith.com.

For you as a developer it might be more interesting to have a look at the community built around each Framework as it might reflect the amount and speed of support you will find for your upcoming projects. Therefore it is always a good idea to have a brief look at the few occasions where the community activity is shown. Since every project here is listed on GitHub a brief extraction of their stats should be helpful.

Angular was the winner of our part-1 comparison. It’s no surprise to see Angular again as one of the two most popular frameworks. While it almost reaches Backbone’s popularity it surpasses all competitors from the developer community site: Most stars, most contributors, most watchers, most issues (judge yourself if that’s good news), and a large amount of commits. When it comes to this kind of stats the number of git commits since the initial deployment plays a huge role: Ember, for instance, has the most commits. Impressive! But keep in mind: Ember had six more years to collect these commits compared to React. Taking things into perspective, React has more stars (already) than Ember although it is barely out of its childhood compared to the other almost ancient players.

Despite not being visualised here Stackoverflow.com displays Angular in the best possible light as it counts more than the double amount of posts than Backbone and Ember together and over 65 times more than React!

We do realise this is a snapshot in time and might well be outdated by the time you read this post. Which leads to the following question: Which of those frameworks is worth investing in the (near) future? The question is especially relevant for React as its popular contributor Facebook is well-known for the ability to establish new technologies, be it software (Hadoop) or hardware (open compute). Are we close to witness a new star rising on the MV* Framework horizon?

Google Trends has always been a faithful companion to get an idea of how popular a topic is and, by looking at the development over time, how popular it might be in the future. While different search terms around the same topic might bring different results, you can still get a general idea for each framework. The fact that these terms appear around the same time the frameworks were introduced proves our point as being representative, at least to some extent.

What this graph for sure does is manifesting Angular as the most popular Framework. Moreover, fascinating to note, Backbone’s popularity seems to be stabilized or even decreasing over time. Same can be said by looking at Ember. Are they already over their peak and now losing momentum? While Backbone’s market penetration might already be too deep to just disappear from the market, fate seems uncertain for Ember.

No doubt, the most astonishing trend is React’s. While writing this blogpost, we had to rewrite this section three times in two months:

December 2014: Backbone and Ember are closely followed by React. =>Respect!
January 2015: React catching up and passing by its competitors. => Impressive!
February 2015 (partial data!): React’s popularity outruns Backbone and Ember by far and is the runner-up to Angular. => Speechless!

According to Google Trends, React has risen from zero to a fourth of Angulars popularity within 1.5 years without showing any kind of flattening of their popularity curve. If React keeps up its progress we might see a new rival of the popular Angular at least as far as the View component of the MV* frameworks is concerned.

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

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

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

javascript mv*

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.