Tools

How to choose a good mobile ad network

Post author By George Makkoulis
Post date June 16, 2014
No Comments on How to choose a good mobile ad network

You probably have already tried a handful of mobile ad networks, spending the good part of a day every time to integrate them and have experienced so far both feelings of disappointment and satisfaction. If it helps, you are not the only one.

The road to building a successful app business is not an easy one and you have to constantly experiment with new ad networks and technologies to find the one that best matches your app’s unique needs.

It doesn’t have to be a painful experience though and here are 5 different angles to look at a mobile ad network before you decide to invest your time and give it a try.

Angle #1 – Fill Rate

A quick look at your mobile analytics provider will show the countries or regions the majority of your users are coming from.

Geography: If most of your users are coming from North America, for example, you should actively search for mobile ad networks that have a high fill rate in this region otherwise you will not be making money at your full potential.

Consistency: This is slightly tricky to evaluate beforehand, but aim for a monetization partner that in the last 3 months had consistently high fill rates in the regions you are most interested.

Many in-app advertising solutions have developed mediation technologies and partnerships with ad exchanges to combat these issues and while touting near 100% global fill rate, make sure you evaluate on hard numbers and not just marketing talk.

Angle #2 – eCPM

Choosing a mobile ad network based only on its average eCPM has a caveat because eCPM measures performance on a relative basis. Only when combined with the fill rate and your estimated monthly ad requests you can get a good sense of your expected earnings in absolute terms.

Have in mind that there are many factors that will cause significant fluctuations on eCPM, including the seasonality of advertising campaigns and the quality of traffic you send from your apps. You should anticipate fluctuations, especially if you are working with a single mobile ad network, and use the network’s average eCPM to get an “order-of-magnitude” feeling on what to expect.

Angle #3 – User Experience

People who download a free app are well-aware that it has to be funded somehow and they expect that the app might include a form of advertising.

App developers, however, have a choice whether they want to deliver a spammy user experience or interrupt the normal user flow to display ads and by choosing to do so they consciously take the risk that user retention can fall dramatically.

If quality user experience is important to your app, some mobile ad networks are more flexible than others and have started embracing native advertising technologies to offer developers more control on how and where ads get displayed.

Angle #4 – Technology

You can also evaluate a mobile ad network based on its technology.

SDK: A lightweight SDK that has been battle-tested enough will ensure your app’s performance will not be impaired at any time.

Dashboard: A fully-featured dashboard can enable thorough monitoring and effortless fine tuning which helps in both maximizing your revenues and increasing transparency.

Ad Server: This component is the most difficult to evaluate but among others, low-latency infrastructure and yield optimization algorithms are the backbone for a good eCPM, so you can use that as a proxy.

Angle #5 – Payment Options

We’ve covered previously the different payment options offered by major mobile ad networks and is important to be familiar with them well in advance in order to avoid unpleasant surprises.

Payment methods: Mobile ad networks often support a limited number of payment methods and you have to make sure your individual circumstances can be covered before you start integration.

Payment schedule: This is usually not a deal breaker, but some networks offer a faster payment schedule than others.

Sum Up

Experimenting with various solutions to find the ones that best match your needs is critical for a successful app monetization strategy but due to the sheer volume of mobile ad networks out there it can get quickly overwhelming.

Avocarrot have explored here 5 different dimensions that can hopefully help you get a well-rounded picture of any mobile ad network you come across and quickly decide whether or not you will invest some of your time to give it a try.

Tags ad networks

Languages

Understanding Swift: 5 things app developers should know

Post author By Mark Wilcox
Post date June 10, 2014
No Comments on Understanding Swift: 5 things app developers should know

The most surprising thing to come out of Apple’s WWDC event this year was a new programming language for iOS and Mac development – Swift. To the sceptical this might not seem like anything more than a way to entice more new developers to build apps exclusively for Apple platforms and lock them in. While investment in developer tools is always partly about making a platform attractive to developers, this move has far more benefits and strategic implications.

1. What is Swift?

Swift is a statically typed, compiled language, interoperable with the Objective-C and C code that are currently used to build Apple’s platforms and the native apps that run on them. However, it also has the feel and features of more modern scripting languages. In creating Swift, Apple has attempted to give developers the best of both worlds, the performance of native code but the convenience and productivity of a scripting language.

2. Faster, Safer and Less Code

In fact, Apple claims that Swift is faster than Objective-C, yet at the same time developers are freed from the burden of explicitly declaring types (they’re inferred), or manually managing memory (it uses automatic reference counting). With features such as “optionals” (a generic way of checking if things exist before using them) and type safety (no default attempt at an implicit cast), the compiler is able to prevent many of the worst bugs that crop up in the C family of languages while reducing the amount of code that has to be written and maintained. Another productivity enhancing change from the legacy of C is the elimination of header files, keeping interface definitions and implementations in one place.

3. Interactive

Although reducing the amount of code required to perform simple tasks is productivity enhancing on its own, even greater benefits are obtained by reducing feedback cycles. In the same way that a simulator allows more rapid testing of new code and ideas than building for a device and installing, live coding environments provide almost instant feedback as the code is written. Such tools are not traditionally available to compiled languages but Apple has created “Playgrounds” for Swift. These don’t provide live coding for an entire app but allow developers to experiment with new algorithms or bits of UI in such an environment before copying them into an app. Similarly, whilst being able to inspect variables in a debugger is useful, it’s even better to be able to interact with an app while it’s running. Swift provides a REPL (Read-Eval-Print-Loop) for this, much like the debug console for JavaScript in most browser development tools.

4. Functional friendly

The language also has functions (and closures) as first class objects with a much more readable syntax than Objective-C’s blocks, making it easier to apply functional programming techniques. This could be particularly helpful for fans of Functional Reactive Programming (FRP) – a programming paradigm that has been gaining in popularity for app development amongst a lot of smart developers. It helps to eliminate complexity when dealing with things like user input and asynchronous network communication – two key areas for most mobile apps. A team at GitHub actually created an FRP library for Objective-C, called ReactiveCocoa, which is extremely well thought out but forced into the most painful syntax by the language.

5. What’s the catch?

Sounds a bit too good to be true, right? Being a compiled language and using reference counting, rather than a garbage collector, developers are still responsible for avoiding memory leaks due to strong reference cycles. These happen when two objects refer to one another, directly or via a chain of other objects. So, while the language may be beginner friendly, it makes it fairly easy to write code that leaks memory. To avoid this, developers need to understand how the memory is managed for them and how to break these cycles. It’s not horribly complex but it’s a long way from not having to worry about memory management at all. That said, most iOS apps will get away with leaking a bit of memory – usually the device will just silently kill them in the background when the memory is required for another app.

Being compatible with C and Objective-C makes Swift a fairly big language – there are quite a lot of concepts and bits of syntax to learn for a new developer, rather than one coming from an Objective-C background. Also, as a type safe language, Swift is going to be much less forgiving to the novice that would prefer the compiler just figured out what they meant when comparing the integer 1 with the floating point value 1.0 or the string “1”.

Swift is currently an iOS & Mac only proprietary language. Unlike Objective-C, which has an open source compiler and runtime (used by Apportable) there’s not likely to be any way to use the code on Android or other platforms. However, most developers wanting a cross-platform approach are unlikely to have started with Objective-C anyway, so this is not really creating significant extra lock-in. It might just persuade some developers choosing a cross-platform tool to target iOS because it’s easier, to create a fully native app instead.

Why does it matter?

First, more developers. Although modern Objective-C has a lot of good points, it’s an evolution of a very old language. Syntactically it’s quite different from most other modern languages – it borrowed from Smalltalk while the rest of the world followed C/C++. This creates a barrier to entry for developers in other languages because the code initially looks alien. Additionally, any language that has pointers is a hard sell and steep learning curve for complete beginners. Swift fixes those things and should make developing for Apple products attractive to an even wider audience.

Second, more productive developers. Greater productivity means lower cost of development and/or shorter time to market. The combination of more rapid development and lower fragmentation versus Android should help to keep iOS as the first platform developers target, even as its market share continues to shrink through the faster growth of Android globally. This is very important if Apple intends to stay exclusively at the premium end of the market.

Last but not least, happy developers. Although several cynical commentators have latched onto the proprietary language lock-in angle, it seems rather unlikely that giving developers a new language to learn is going to lock them into developing for a platform when the barrier to exit is, well, learning a new language! Instead consider that Apple is primarily aiming to retain developers through loyalty rather than lock-in with this particular move. It should not be underestimated how much good tools can contribute to the enjoyment of daily development work. If Swift can deliver on its promises then other platforms will have to be that much more attractive to tempt the best developers away.

Tags functional-programming, ios, objective-c, swift

Platforms

Confessions of a BlackBerry developer

Post author By Alex Christou
Post date June 5, 2014
No Comments on Confessions of a BlackBerry developer

The BlackBerry developer initiative

It’s been almost 2 years since the first beta release of the BlackBerry 10 SDK. Back then, RIM decided to launch the “happy developer” initiative, which was comprised of two parts. The first was targeted at some of the largest software houses and the second, at the long tail of developers. The first part was successful, since most of the big software houses are now supporting BlackBerry10 either by building native apps or by porting their existing Android apps into BlackBerry World.

The second part of the initiative, which was aimed at indie developers and hobbyists, is a different story. It seems to me that BlackBerry tried their best, shipping beta devices all over the world, getting the developer relations team on the road, in order to help developers face-to-face, giving incentives like the 10k$ commitment (money that was delivered every month, just as promised), and, most importantly, engaging with all developer communities or individuals from around the world 24/7.

The need for change

BlackBerry went through some difficult times during the past 2-3 years. The company seemed to be unable to get it right, and the negative media attention wasn’t helping. The BlackBerry 10 launch was not as successful as the company would have liked.. The legacy BlackBerry devices were outselling BlackBerry 10 devices quarter after quarter,..
A change was sorely needed in the company’s direction and plans. Cue John Chen. Once Chen was named CEO he brought a whole new set of ideas to BlackBerry, and a new plan of action.
Success comes after a company becomes viable and profitable at the same time. Under the new leadership, BlackBerry started adhering to timetables and deadlines and showing all signs of following a specific plan.

There’s just one thing that did not change, and that’s their commitment to developers. Yes, they are shorter on staff (the developer relations team was merged into another team under Martyn Mallick), the VP of Developer Relations, Alec Saunders, is now in charge of QNX cloud, aka Project ION. But the tools are still getting updates, and the roadmap, which is more important in my opinion, is active, showing that there is a plan for the BlackBerry 10 platform. BB 10.3 is now just around the corner new devices are on the way, and the future looks a little brighter for a company that went through hard times but now looks ready for a comeback!

There’s also been a change in the central message that BlackBerry is attempting to communicate to developers. When BlackBerry 10 was first introduced, this message was “Flow-Connect-Extend”. It was all about the core basics of the new platform.

For the 10.2 update the message was changed to “Adapt-Sense-Understand”. BlackBerry had more features available for developers, such as headless mode (i.e. apps running in the background), and use of geolocation in apps. Now this message has changed once again, and it’s all about the Internet of Things (project ION). We still don’t know too many details, but it has to do with big data in a secure environment (QNX cloud) that can be used by developers to create a whole new breed of apps.

The decision

Back to reality. As a developer targeting BlackBerry 10 myself, I realize that publishing an app is a twofold process.
The first step is developing the app. BlackBerry offers a completely risk-free environment, with fully engaged support and tool options. During the past couple of years, the SDK has been updated many times, each cycle an improvement over the previous one.

The second part is what comes after publishing the app. This is where success/time spent in part 1, takes place. Success means different things to different people. It might be measured in terms of money earned, number of downloads or even a high rating for their app in the BlackBerry World app store. The truth is that developers don’t have many tools at their disposal to reach their goal, whatever that may be, and BlackBerry’s current status in the top markets is not helping improve this situation..

But what about the countries and regions in which BlackBerry is still a best-selling handset manufacturer, such as Indonesia, South Africa, Nigeria and the Middle East? It might not be as easy as it sounds to target specific markets. Let’s take a look at the distribution of downloads and revenues around the globe (I’m using my own app as an example).

Downloads vs. Revenue maps of a freemium app with more than 125k downloads (May 2013 – May 2014)

It’s clear that BlackBerry has to improve its standing in major markets. Many think the main reason for low device sales in key countries is the lack of apps – but maybe it’s actually the other way around. Perhaps we have a formula that looks something like this: device sales -> more users -> more profit for developers -> more developers -> more apps
At the end of the day, engaging with BlackBerry is going to be a personal decision. There are some important parameters still missing from the BlackBerry platform, which might be keeping many developers from migrating to, or at least adopting, BB 10. A lot of these parameters, however, are not strictly related to actual development, i.e. coding.

But developers should keep two important factors in mind: BlackBerry 10 is still one of the newest OSs out there, which means there’s a lot of room for growth. Also – BlackBerry still is, and will continue to be, a leader in enterprise solutions, which is translated as a strong brand name. This combination indicates that there’s potential for BB10.

If I were to give developers some advice on whether to adopt the platform, I would say go for it. Built it or bring it – i.e. either go native or bring over your Android app. The tables may turn sooner than you think.

Tags BlackBerry, mobile developer, platforms

Languages

Is HTML5 about to make a comeback?

Post author By Mark Wilcox
Post date June 2, 2014
No Comments on Is HTML5 about to make a comeback?

The web is losing and apps are winning. At least that’s what the most recent data from Flurry says – 86% of time on mobile devices is spent in an app other than the browser, up from 80% last year. Does that really mean the web is losing? What about apps built with HTML5? Is the implementation technology more important than the distribution mechanism? Why should anyone care? A number of new tools and frameworks are maturing that should make it much easier to build great mobile sites and apps with HTML5. Could they stop the shift from web to native apps, or even reverse it?

Why the web is losing on mobile

Modern web browsers and standards were designed for a desktop computing environment and they built upon a base that was designed for sharing linked documents. Mobile computing environments have capabilities and constraints that desktops don’t. Native mobile app platforms were designed for building highly interactive, animated, apps utilising hardware graphics acceleration. The result is that apps running in a mobile browser are disadvantaged in terms of performance, user experience and access to device functionality versus their native counterparts.

The app is the new browser bookmark. People have favourite services and sources of information or entertainment even though a great deal of substitution is possible in most cases. Providers have to compete on user experience and that creates a bias towards native apps. You want to check the weather every day? You don’t search for a weather forecast every time, or find a favourite weather site and bookmark it, you download a weather app. Need to catch up with your friends on a social network? You don’t open the browser, type a URL or go to a bookmark and wait for the latest updates to download, you get update notifications pushed to you by the native social network app, or when you open the app it has already downloaded the latest content in the background. For frequently accessed apps, the native versions have much less friction, as well as a nicer user experience.

What about hybrid apps?

Delivering a web app in a native wrapper allows it to access device functionality and reduce some regular usage friction. However, it doesn’t fix performance (indeed on iOS it makes it worse), nor make it easier to deliver a great user experience. Another problem with delivering a packaged web app that uses a system WebView is that the functionality of the WebView itself can change with OS updates. Android recently switched to a new Chromium-based WebView and broke or crippled lots of hybrid apps. The flip-side to this problem is that WebViews upgrade slower than browsers; on Android the WebView is currently tied to OS upgrades (which are still lacking from most manufacturers) while the Chrome browser continuously auto-updates. This means it’s a long time before it’s feasible to start using new standards added to the browser specifically to tackle mobile issues. A hybrid app is also still subject to app store reviews and policies. It may be possible to update functionality without an app update in the store but the platform owner still controls what developers can and can’t do.

Another popular complaint about hybrid (and native) apps is the loss of ability to cross-link versus the web. I believe that Facebook’s recent App Links project puts all native apps (including hybrids) about on a par with web apps here. It may be possible to link to any web page but many modern web apps only have a single page. What’s actually needed with a web app rather than a web site is the ability to link to app states. This is only possible if the developer enables it by setting up routing for URLs to app states – native apps can already do this and App Links solves the “what if the app isn’t installed” problem with web fallbacks or store links. If platform providers enhance app interoperability then native (and hybrid) apps could significantly exceed the capabilities of the web here.

Engagement versus ease of access

As discussed above, any content or services you access frequently create less friction by providing native apps. Less friction enables more engagement and a virtuous cycle of greater usage. On the other hand, new or infrequently accessed content and services have extremely high friction if you need to download an app before you can do anything else. Here the web has significant advantages over native apps. The companies who really don’t get this are the ones that have a full screen popup asking you to download their app every time you visit their website on a compatible device! Another way to look at the Flurry stats linked at the top of the article is this: exclude games (which have almost always been native for performance) and social networking (which falls firmly into the frequent access category, plus a lot of the time will be using an in-app browser anyway) and the browser still has more than a third of the remaining mobile usage time. That doesn’t sound quite so bad.

New frameworks fill the gaps

With the threat of being relegated to the “infrequently accessed” category of apps, the web development community has not been sitting around doing nothing. A new framework recently into public beta, famo.us, attempts to solve the major performance problem for animated web app UIs. Their current approach is a series of clever hacks involving minimal manipulation of a very flat DOM structure. However their JavaScript APIs will also render to WebGL in future (when it’s sufficiently widely available, ahem, Apple). The approach is promising and the demos are impressive. Currently their homepage (on both my retina iPad Mini and Nexus 4) kinetic scrolls with a stutter that makes my 2006 Symbian device look slick, so there’s a way to go before they’re ready to come out of beta. Note that using Famo.us JavaScript APIs starts to make building web apps look more like creating a native app.

Another framework close to its 1.0 release is Meteor, a new way to create real-time web apps very rapidly. They fix common issues with the responsiveness of web apps out of the box – having to poll the server for new data and wait for it to update the UI after user interaction. The latter is achieved with a technique called latency compensation (UI is updated with local data immediately, then fixed if the server returns something different). The former is down to having long-running bi-directional connections between client and server rather than a more traditional RESTful API. Meteor actually supports native client apps too but with the ease of creating the web front end it would be unusual for developers not to have both web and native options if they go down that route.

Although there are lots of new and interesting frameworks in development I’ll highlight just one more that’s in a fairly mature beta stage. Ionic is a framework designed specifically for building hybrid apps. It’s built for performance and to provide common UI components and interactions out of the box so it’s easy to make an app with a native feeling user experience. The default styling is very similar to, although deliberately not exactly like, iOS 7. The major disadvantage to this approach is that while it works on recent iOS and Android versions you lose the broader cross-platform and device compatibility. It’s not for building mobile websites or desktop web apps. As such Ionic is building on HTML5 purely as an implementation technology and abandoning the browser. However, as it’s still running in a WebView developers retain the privileged position of being allowed to download new code on iOS.

Native user experience

I listed performance and user experience as two separate issues for a good reason. Despite all the great efforts at resolving performance issues for web apps, native user experience is not just about performance. For some apps it’s natural to take over the full screen and provide an immersive user experience. Games fall into this category, unfortunately they’re also the category of app most in need of full native performance. The majority on non-game apps use some standard platform components and need to follow platform user experience conventions. This makes it easy for users to learn how a new app works; navigation and controls work in the same way as most of their other apps. In this sense when we say “native” user experience we mean aligned with the platform culture and conventions rather than compiled to native binary code. The folks at Ionic are right not to mimic iOS 7 too closely. The more native looking an app’s UI, the more users will expect it to behave exactly like one (and get frustrated when it doesn’t always). A phenomenal amount of effort is required to make an app look and feel just like a native one when it’s not actually using native controls. Even if this can be achieved, the platform will change and the app won’t, making it stand out like a sore thumb until it can be updated (again at significant effort). This is an issue for all cross-platform environments that have their own rendering engine rather than wrapping native controls.

What the technology wants

Marc Andreessen famously said that the eventual application model on mobile will be the web application model, because the technology wants it to work that way. Having every app stored on a remote server and the latest version always updated to the device when it becomes available is a superior model to downloading and periodically updating local apps. This technological advantage applies almost equally to hybrid apps, assuming the native wrapper rarely needs changing. Native apps that automatically update is a step in the right direction but doesn’t aid lean development practices like split testing and continuous deployment. The latter are so valuable in figuring out what to build quickly that there are plenty of entrepreneurs and businesses out there who would build mobile apps with the web model if they were good enough for their customers.

The next wave?

Consumer apps that don’t have highly desirable unique content or features are going to have to compete on user experience for the foreseeable future. For most that will mean native apps. However, building native apps is significantly more expensive than building cross-platform web apps. Not all of the people who pay for apps are going to prioritise user experience. The next generation of software for large enterprises right down to small businesses is going to need a much better user experience than the last but the current state of web technology is probably good enough.

Revenues from consumer mobile software may look quite attractive but the bulk is in Free-to-Play games and is highly concentrated amongst a handful of publishers. The majority of the growth in that market is in Asia. A more interesting opportunity for many developers may be the only slightly smaller but faster growing Software-as-a-Service (SaaS) market for businesses. As mobile devices become increasingly essential in our work lives as well as our personal lives, maybe we’ll see more of that total usage time in business and productivity apps.

Conclusion

So, is HTML5 about to make a comeback? In a way. If the first wave of mobile computing adoption was primarily about consumers, the next wave will see many more businesses getting serious about using mobile devices to enhance productivity and collaboration. I suspect the use of HTML5 in business apps to be much more successful than in the consumer space. Possibly we’ll see a return to the browser but for now the hybrid app looks more likely. General purpose business apps like time and resource tracking or project management will have large enough user bases to justify native client apps, although of course they’ll need web access too. The more specialised the app, the more likely it is to be a hybrid app than a fully native one.

Tags HTML5, hybrid apps, Native

Platforms

Which top platforms are easiest to develop for?

Post author By Mark Wilcox
Post date May 26, 2014
No Comments on Which top platforms are easiest to develop for?

In the mobile software world, developers are considered vital to the health of platforms, of which they have several to choose from. Platform owners have to work very hard to make sure their SDKs and tools are easy to use. Too much friction, too little documentation or too steep a learning curve can drive developers away. Which platforms are the easiest to develop for? More importantly, does ease of development translate into popularity? Or is it just a hygiene factor?

A lesson from history

Mobile platforms have not always tried to make things easier for developers. Before the iPhone, Symbian dominated the smartphone market and had a policy of making developers jump through hoops to ensure both the resource efficiency of apps and the security of the platform. Nokia tried to add a developer friendly layer on top of the OS with Qt but it was too little too late to capture developer attention, even with an existing large installed base. So, a terrible developer experience can ruin a platform’s chances but does greater ease of development lead to success?

Interpret with caution

In our last developer economics survey we asked developers how easy it was to use a common set of APIs on their primary platform. Before diving into the data, there are some caveats:

Comparison between platforms is slightly unfair because the API categories are broad and not all platforms will enable access to the same level of functionality
Not all developers target multiple platforms, so some do not have a good basis for determining ease of use (although purely subjective ratings are still valid for comparison)
The APIs that were included in the survey primarily focus on native functionality, so this comparison in somewhat unfair on HTML5
The APIs do not include UI functionality and building the UI is a significant part of the work in most mobile apps.

Bearing those points in mind, below is what developers think of their platforms.

Easy != Popular

Our data shows that the challenger platforms, BlackBerry 10 and Windows Phone are the easiest to develop for, with BlackBerry 10 having a slight lead. In the middle are the leading platforms, iOS and Android, with iOS fractionally easier to develop for overall but with Android having several APIs where it leads.

In a distant last place we have HTML5, suggesting that it’s still very difficult to build apps that take advantage of uniquely mobile features with web technologies. In this regard it’s interesting that the recently appointed CTO of Mozilla, Andreas Gal has this to say:

“For Mozilla, anything that the Web can’t do, or anything that the Web is not faster and better at than native technologies, is a bug. We should file it in our Bugzilla system, so we can start writing a patch to fix it.”

There appear to be a few more entries for their Bugzilla system above. Web technology has matured a long way and makes it very easy to develop web sites across a wide range of screens – mobile apps are not the same thing and pose a different set of challenges.

To answer the question we posed at the beginning, it seems that ease of development is mostly a hygiene factor. The top platforms are not the easiest to develop for. BlackBerry 10 seems to have surprisingly high levels of continuing loyalty amongst developers despite the very poor sales for the platform to date, so perhaps there is some value in creating an environment developers really love to work with rather than one that is simply not painfully difficult.

The next frontier?

As we move towards a world of connected sensors everywhere and wearable devices are being hyped as the next big thing, an interesting sidenote is that Bluetooth was rated as the hardest API to use by developers across all platforms. After years of failing to reach its potential, Bluetooth is emerging as one of the key technologies enabling smartphones to talk to wearables and other external devices without sufficient power to maintain their own permanent internet connection. Perhaps this is an area for all platforms to consider revisiting, or an opportunity for an Internet of Things platform provider to abstract away the details.

Tags BlackBerry, bluetooth, Developer satisfaction, HTML5, Mozilla, Platform selection

Business

How much does it cost to create a successful app?

Post author By Mark Wilcox
Post date May 13, 2014
No Comments on How much does it cost to create a successful app?

The app stores contain a range of apps from hobbyist creations built for fun to the carefully crafted output of venture backed startups and mega-corporations that have had millions of dollars spent on their development.

Even though the market is maturing and exceptionally well-funded developers have taken over the store charts, the occasional small independently developed app that goes viral can still break through and achieve a decent level of success. The question is, how likely is a small budget developer to succeed? What platforms give them the best chance of success? Where should the budget be spent? With all the competition out there, how much does a bigger budget improve your chances of turning a profit?

What are the odds?

In order to look at how budget can impact profitability it’s worth calibrating by the average chances of making a profit on each platform.

The figures in this chart are probably more positive than most industry observers would expect. Looking at the data it seems likely that many solo developers have valued their time at zero when reporting costs. For hobbyists and explorers, working in their spare time this might make rational sense. They don’t expect to be paid for the time anyway and their small app profits more than cover their other development costs. This is reflected in the slightly lower level of Android developers losing money versus iOS (there are far more hobbyists on Android than iOS).

Leading platforms

On the most popular platforms – iOS, Android and HTML5 – there’s a general correlation between spending more on an app and making more revenue. However, not all spending produces equal results. Spending more on development only slightly increases the chances of making a profit, while increased spending on design and marketing are strongly correlated with higher probability of making significant profits. Higher spending on customer service is almost always associated with greater profit probability but here the causation is almost certainly in the other direction; successful apps incur greater customer service costs because they have a lot of customers! These platforms show very similar patterns but they aren’t identical. The biggest difference between them is that spending more on design for HTML5 apps seems to produce much less of a boost to profit probability than for either of the leading native app platforms.

The second tier

BlackBerry 10 and Windows Phone show similar patterns of spending versus profit probability that are very different from the leading platforms. For small amounts of spending, there are similar patterns to the leading platforms. More investment, greater chance of a profit, with better returns from design and marketing spend. However, before reaching a level that would sustain a full-time designer or developer, the trend reverses; investing large amounts in any aspect of apps for these platforms reduces the probability of a profit and increases the chances of making a loss. This suggests that these platforms have not yet reached sufficient scale in terms of app revenues to sustain many highly complex or polished apps.

Opportunities everywhere

On the leading platforms, developers with budgets in the multiple thousands of dollars a month have roughly twice the chance of turning a profit on their apps as those spending minimal amounts. Even at lower spending levels, the probability of breaking even or better is reasonably high across all platforms, particularly for those investing in design and marketing. While it’s clear that only some of the platforms discussed above are likely to support scalable app businesses at the moment, there are plenty of opportunities to build profitable apps on any these top 5 platforms.

Want to know more?

I’ve only scratched the surface of our data here. What scale of profit or loss can be expected on different platforms with different levels of investment? Are there optimal investment levels to maximize the chances of success? Which app categories are most likely to product a profit. What do successful app development companies look like at different sizes? All this and more is covered in our App Economy report.

Tags app revenues, developer segmentation, Platform selection, profits

Platforms

Which top platforms are easiest to develop for?

Post author By Mark Wilcox
Post date May 6, 2014
No Comments on Which top platforms are easiest to develop for?

In the mobile software world, developers are considered vital to the health of platforms and they have several choices. Platform owners have to work very hard to make sure their systems are easy to develop for. Too much friction, too little documentation or too steep a learning curve can drive developers away. Which platforms are the easiest to develop for? Does ease of development translate into popularity? Or is it just a hygiene factor?

A lesson from history

Interpret with caution

In our last developer economics survey we asked developers how easy it was to use a common set of APIs on their primary platform. Before diving into the data, there are some caveats:

Comparison between platforms is slightly unfair because the API categories are broad and not all platforms will enable access to the same level of functionality
Not all developers target multiple platforms, so some do not have a good basis for determining ease of use (although purely subjective ratings are still valid for comparison)
The APIs that were included in the survey are biased towards native functionality, so this comparison in somewhat unfair on HTML5
The APIs do not include UI functionality and building the UI is a significant part of the work in most mobile apps.

Bearing those points in mind, below is what developers think of their platforms.

Easy != Popular

Overall we can see that the challenger platforms, BlackBerry 10 and Windows Phone are the easiest to develop for, with BlackBerry 10 having a slight lead. In the middle are the leading platforms, iOS and Android, with iOS fractionally easier to develop for overall but with Android having several APIs where it leads. In a distant last place we have HTML5, suggesting that it’s still very difficult to build apps that take advantage of uniquely mobile features with web technologies. In this regard it’s interesting that the recently appointed CTO of Mozilla, Andreas Gal has this to say:

“For Mozilla, anything that the Web can’t do, or anything that the Web is not faster and better at than native technologies, is a bug. We should file it in our Bugzilla system, so we can start writing a patch to fix it.”

It looks like they still have a lot of work to do! Web technology has matured a long way and makes it very easy to develop web sites across a wide range of screens – mobile apps are not the same thing and pose a different set of challenges.

The next frontier?

Business

Top revenue models by screen

Post author By Mark Wilcox
Post date April 29, 2014
No Comments on Top revenue models by screen

Screens are everywhere. We’re rapidly being surrounded by bits of glass with some app or other running behind them. Developers have an ever increasing choice of screens to target. There’s a clear and increasing trend towards greater use of mobile screens. However, where is the money? Which screens are users most likely to pay for apps and content for? Are different revenue models better suited to particular screen types?

Mainstream screens

Our developer surveys are only for developers who target mobile devices. However, the developers don’t exclusively target such devices and some don’t even consider them their primary target. The only screen types considered a primary target for large numbers of developers are smartphones, tablets and PCs; all other screen types are relatively small niches. There is some interesting variation in the success of different revenue models by screen type. However, developers earning very high revenues (>$100k per app per month) are fairly evenly spread across revenue models and so they significantly distort averages towards less popular revenue models. It turns out that nearly all of these developers actually use several revenue models simultaneously (far more than the average developer) and we don’t have the data to split out which ones are actually bringing in the bulk of the revenue. Excluding these high earners from our analysis we see the spread of revenues across screens and models in the chart below.

Where’s the revenue?

The most obvious pattern is that [tweetable]revenues for developers who primarily target PCs are generally higher than for those who target smartphones[/tweetable], which in turn are higher than those for tablets. Now, remembering that these PC developers also target mobile platforms, we are most likely looking at more mature businesses and almost certainly more developers targeting enterprises. Affiliate or CPI (cost per install) scheme revenue stands out for PC developers in particular. Affiliate marketing is a fairly big and mature business on the desktop web but CPI schemes for mobile app developers are a relative new and high growth business. Currently, anyone who can reach mobile app users and provide paid installs below the expected lifetime value of an average user is seeing significant demand. With development costs essentially fixed and the marginal cost of serving a new user extremely close to zero, successful consumer focussed mobile apps are willing to pay handsomely for installs.

The notable exceptions amongst tablet first developers are those selling subscriptions; [tweetable]median revenues for tablet subscription apps are by far the highest across all screens and revenue models[/tweetable]. It’s easy to speculate, with tablets being such excellent media consumption devices, that these subscriptions are mostly for media content (magazine, news and video) apps. Obviously there are high costs associated with producing the content, so those high revenues don’t necessarily translate to high profits. Additionally, the higher than average median revenues for developer services on tablets may be related, since tools and platforms for content publishers on tablets are fairly popular.

The e-Commerce mystery

On the desktop web e-Commerce is a giant industry and yet we see smartphones ahead of tablets, with both quite a long way ahead of PCs for e-Commerce revenues. All the e-Commerce spending data says the opposite, with PC spending still ahead of tablet spending and smartphone spending the lowest. Perhaps the scale advantages in online retail mean that there aren’t many businesses able to compete in sub-$100k / month revenue filter we’ve applied here and there are just some niche mobile first e-Commerce solutions starting on smartphones. Indeed our top end revenue band of $500k+ in the survey is probably not large enough to reflect successful e-Commerce businesses. Possibly our survey just hasn’t attracted a representative cross-section of e-Commerce developers.

Continuous clients

Currently PC-first developers are still making the highest revenues for most types of business. Indeed, even the simple paid download model that seems to be almost dying on mobile platforms is looking fairly healthy on PCs. Tablet-first software developers aren’t yet seeing fantastic results despite the growing penetration of the iPad in enterprises and educational institutions. The giant installed base of smartphones does not yet offset the low revenues per user from what are mostly consumer apps. Mobile developers need to focus more on which users are willing to pay for software and what they’re willing to pay for in order to grow revenues. [tweetable]Mobile-first may be an excellent design philosophy but it shouldn’t also imply mobile-only[/tweetable]. Subscription-based businesses are working very well across all screens. Most developers offering subscriptions provide clients for all of the screens their customers use to access their content or service. It seems increasingly likely that the future, regardless of revenue model, will reward those who offer services that work seamlessly across all the screens a person owns, rather than focussing on one over others.

Tags cross-screen development, revenue models, tablet

Business

7 things you need to know before developing a car app

Post author By Stijn Schuermans
Post date April 14, 2014
No Comments on 7 things you need to know before developing a car app

Are you bored with the same old smartphone apps? Why not try developing for cars?

Which tools do you use to develop apps? Have your say in our Developer Economics survey and you could win awesome new gear.

Car makers have started a major offensive to get more apps in their vehicles and open up to outside developers. Their efforts have sparked an interest in the developer community. “A year ago there was very little interest from mobile developers because the automotive market was perceived as being too insignificant,” says Linda Daichendt, Executive Director of the Mobile Technology Association of Michigan, a trade organisation for the mobile/wireless industry located in the heart of automotive country: Detroit. “In late 2013 there was a tremendous surge in vehicle manufacturer outreach to mobile developers with extensive marketing programs. Now there is a much higher level of interest from developers in trying to understand the needs of the automotive companies and how they can profit from working with this market segment. As a result, 2014 is seeing a large number of Connected Vehicle conferences and training programs that are very well attended by the mobile developer community.”

According to Linda, education will be the key to unlock developer engagement and creativity. We thought we’d put in our own 2 cents with our latest report: “Apps for connected cars? Your mileage may vary””. In the free report we describe the state of automotive developer programs in 2014. Here are already 7 things you ought to know before getting into car apps. Many more details inside!

[tweetable]There are 4 ways to develop a car app[/tweetable]. If you want to build an in-vehicle infotainment app, you can run it either on the car’s head unit (the dashboard) or run your app on a mobile device (smartphone or tablet) that is linked with the car. In the latter case, your app’s UI can be mirrored on the dashboard screen using APIs like Mirrorlink or CarPlay. If you want to make an app (in the car, in the cloud or on any device) that uses data from the car, you can use a car maker’s vehicle data API or access the On-Board Diagnostics port (OBD-II) using a bluetooth dongle.
[tweetable]There are 3 routes to market for car apps. Two of them are painful. The third is very early stage.[/tweetable]
- Partner with car makers to get the app pre-installed in the vehicle or featured on a car maker app store. This process takes 2-6 months in the best case. You’ll have to audition with car makers to be allowed to distribute your app, and you’ll be at their mercy for much of the UI design.
- Distribute apps on major mobile app stores (iOS, Google Play). Still, the approval of car makers is needed to distribute apps using their APIs. You’ll need to sign a distribution contract with the car maker in most cases.
- Distribute apps on major mobile app stores (iOS, Google Play) while using an OBD-II dongle to get vehicle data. In this case, you need to convince your user to buy and install a hardware dongle. Platforms like Dash and Carvoyant that allow you to access data from an installed base of dongles have only recently launched, and don’t have a large user base yet (in the tens of thousands at most).
[tweetable]The addressable market for car apps is in the lower millions of app installs[/tweetable]. If you were to produce a car app today and push it in the market with all your might, you can expect at most a few million installs across all platforms. It will probably take you several years to get there. Consider the example of Pandora, one of the most popular car apps around. It took them 3 years and over 30 partnership agreements to reach 4 million unique users. Nokia HERE, the navigation platform, claims to be behind 4 out 5 in-car navigation systems. They have sold 10 million licenses in 2013. Compare this to a potential of hundred of millions of installs on iOS or Android for the top apps. (Apps like Gmail or Facebook will probably count billions of installs when adding up all the platforms.)
[tweetable]…but you’ll face much less competition in car apps than on the mobile app stores[/tweetable]. In our Developer Economics report series, we talk about millions of individual mobile app developers on each major platform. There are hundreds of thousands of app publishers on an organisational level. Based on data from analytics firm Priori, we estimate that each distinct app sub-category or use case has on average 1,500 apps competing for the user’s attention.
In contrast, VisionMobile currently estimates the amount of car app developers at around the ten thousand mark, based on reported figures from car makers that have developer programs. It is still possible to “ride the wave”, i.e. to have an early-mover advantage on car apps just like it existed on smartphones in 2008 or tablets in 2010.
[tweetable]Revenue opportunities for car apps are fuzzy and unproven at best.[/tweetable] Most car makers and car app platform players have not thought through the revenue model question. A common answer is: “the developer can use whatever revenue model he chooses or he is already using”. As we know from mobile apps, it’s not that simple. If you’re relying on an App Store based app for revenue generation, then paid downloads are all but dead in terms of revenue (except navigation apps perhaps), display advertising seems like a no-go and an in-app purchase during normal use seems pretty unlikely, or at least high-friction.
[tweetable]You must design an app that can be operated at 65 mph / 100 km/h without crashing (not your app! your user!).[/tweetable] Safety concerns around driver distraction are absolutely paramount for the car makers you’ll be working with. This is the single biggest difference between car apps and the mobile apps you’re already familiar with. The feeling among car makers is that developers tend to underestimate the importance of new UI paradigms quite a lot – and you’ll be thoroughly scrutinized on it. Expect a learning curve.
This of course doesn’t apply for car apps that are not used while driving or don’t require user interaction – by no means a niche area! Think insurance, fleet management, car sharing, maintenance and reselling: the list is endless.
[tweetable]Things are moving fast. Your life is about to get easier as platform plays similar to iOS and Android are set in motion[/tweetable]. The introduction of Apple’s CarPlay and Google’s Open Automotive Alliance (and to a lesser extent Windows in the Car) seems to herald a tipping point in the industry. Here are two players that have a deep expertise in solving fragmentation, in building developer communities and in enabling developers to add value. There is now a realistic and acute possibility that these new entrants will sweep away the existing car app platforms with a dominant, over-the-top solution, just as they did in the smartphone world. You can find an overview of all the important platform contenders in our report.

Do you consider car apps part of our future? Have your say in our Developer Economics survey and you could win awesome new gear.

Business

Emerging developer opportunities in Enterprise & Productivity apps

Post author By Andreas Pappas
Post date April 7, 2014
No Comments on Emerging developer opportunities in Enterprise & Productivity apps

Andreas Pappas shares our latest findings, from our Business & Productivity Apps report which takes a look at developer opportunities created by emerging trends in enterprise mobility (such as bring-your-own policies and mobile SaaS) and professional and vertical app markets (e.g. healthcare apps). This market was worth $28 billion in 2013 and is set to grow to $58 billion by 2016.

[Want to help us with data for our reports? We’ve just launched our latest Developer Economic survey – take the survey and have your say on the latest trends]

[tweetable]Apps are changing the way people communicate, work and play[/tweetable]. App development has grown into a huge industry, that we estimate to be worth $67 billion in 2013. We expect the app economy to more than double in size by 2016.

Most of the publicity and media spotlights currently fall on superstar consumer apps like Angry Birds or Candy Crush Saga and communication apps like WhatsApp. These success stories have certainly highlighted the massive scale and revenue potential of mobile apps, reaching from zero to tens of millions of users in record-breaking time.

At the same time, a growing audience of prosumer and business users depend on Box, Evernote and Trello to help them be more productive in their work. Enterprises are now allowing employees to use the apps they love at work, inside the corporate Intranet. Organisations of all shapes and sizes are integrating mobile apps within their business processes. This mobilisation creates a demand for off-the-shelf or custom mobile apps and services, translating into new and bigger opportunities for mobile app developers.

Most app developers currently target consumer app markets (think games and lifestyle apps) but they could be missing out on opportunities in the enterprise (aka business & productivity) market. Our research indicates that the business & productivity app market, is not only growing at approximately the same rate as the consumer app market but is also less congested, and offers better revenue potential, for more developers. Read the report to find out more.

Consumer vs. Enterprise & Productivity apps: how do revenues compare

App publishers that target business and productivity markets have a much better chance of generating sustainable revenue than those targeting consumer markets, with just 32% of them below the “app poverty line” ($500 per app per month) compared to just under half of consumer-focused publishers (48%). At the same time, [tweetable]publishers that target businesses or professional users have a much higher chance to generate very high-revenues[/tweetable]: 16% of those targeting the business & productivity market generate revenues exceeding $500,000 per app per month, compared to just 6% among consumer-focused publishers.

While consumer apps and particularly games (e.g. Angry Birds, Candy Crush Saga) can generate extraordinary revenues, it is quite clear that this is not the case for the vast majority of developers that target consumer markets. Business & Productivity apps allow developers to build a sustainable business around more solid business models with recurring revenues from a loyal customer base.

As bring-your-own policies and enterprise app stores become increasingly popular among businesses, the market and the opportunity for developers is likely is set to expand in the next three years.

Which platform should you prioritise if you build business and productivity apps?

While Android is dominating the consumer market in terms of market share, iOS maintains a healthy lead among professional and business users. Data provided by enterprise cloud content platform Box, indicates that 94% of their tablet users are on iPads, while enterprise mobility management services provider Good Technology indicates that 54% of enterprise smartphone activations came through iPhone devices in Q4 2013. It is clear that Apple has an edge in the business device market and this is also reflected in revenues generated via iDevices: VisionMobile estimates that revenue generated via iOS devices accounts for at least 60% of the total revenue in the business and productivity market.

For developers that target the business & productivity sector it makes sense to prioritise iOS for development over the other platforms they develop for. However, there are several considerations to take into account such as integration with existing enterprise services, which may call for an HTML approach or the specific market that you target.

Where are the opportunities in the enterprise app market?

There is an inherent unpredictability associated with the future use of apps and it is exactly this unpredictability that empowers developers to create innovative apps that continue to redefine whole markets and industries. Nevertheless, we can still identify a number of areas that currently attract considerable attention among businesses and where we see future value being unleashed in the business & productivity market:

Vertical apps
Specialised industry apps such as healthcare, real estate, finance or automotive. Vertical specialisation provides a great opportunity for differentiation and for building strong brands as the app economy diffuses into every single industry. Existing industry stakeholders can leverage apps as a differentiation strategy against “un-apped” competitors, integrating apps and exposing APIs across their product offerings. For independent developers, specialisation is a means to capture a niche and survive the discoverability labyrinth.

Productivity/BYO
Apps that cross the boundaries between private-use and work-use, such as storage, lists, calendars, office-type apps are key drivers behind the consumerisation of enterprise IT. Once into an organisation or an enterprise app store, such apps can spread rapidly within organisations.

Mobile SaaS
Software-as-a-Service, delivering CRM, HR, ERP, BI services to small businesses and large enterprises is a booming sector. Mobile apps extend these capabilities much further by allowing anytime/anyplace access to these core business services.

Custom apps/services
Bespoke mobile solutions delivered outside of app stores will continue to take the lion’s share of revenues within the business and productivity app market. As we discussed, the dominance of this model will erode during the next few years as app store purchases increase among enterprises.

MDM/MAM
Apps and services that tackle security and complexity of the decentralised IT department are already essential for any enterprise that adopts BYO policies. More sophisticated app & device management models, that tackle some of the key issues associated with this trend (e.g. managing private/work services, remote deletion of work content) will continue to be hot areas in the next few years, catering to an increasing number of use cases.

Download our free “Business and Productivity Apps” report to find out more about the developer opportunity in this market and the reason you should be developing business and productivity apps.

Have your say in Developer Economics research
Help us continue bringing you great insights about the app economy and app development. Take part in our 7th Developer Economics survey that is launching today! Help us break our earlier world record of 7,000 app developers that took our 6th survey. Take part, spread the word, win prizes and help us do great research !

Tags app business, app economy, Enterprise, forecasts, productivity apps