Categories
Platforms

Cross Platform Apps – Qt vs. HTML5

Although building a separate native app per platform is currently proving to be the most successful approach for mass market consumer apps, there are still a lot of situations where it makes more sense to go cross-platform. In this article we’ll look at the most popular option, hybrid web apps built with HTML5, versus an up-and-coming challenger, Qt.

Cover_2

How do you build web apps? Take the Developer Economics Survey and let us know. Cool prizes await you.

Why Qt?

Those who know the history of Qt may be surprised to see it described as “up and coming”. Qt was originally designed for building cross-platform desktop apps, it’s creators started working on it in 1994! However, Qt became interesting for mobile development after Nokia bought Trolltech, the company developing Qt at the time, and invested heavily into making it the ideal toolkit for building mobile apps. Unfortunately, Nokia was making this strategic decision shortly before the iPhone launched (the acquisition was completed afterwards). This changed the game from building apps for devices with numeric keypads and Qwerty keyboards, to large touch-screen based devices. The former Trolltech engineers recognised that they needed a very different way of creating apps for Nokia’s offering to compete.

When Steve Jobs said that the iPhone was 5 years ahead of the competition at launch, he was not far wrong. Android had managed to close some of that gap, probably due to executives at Google having some advanced warning about the iPhone. Unfortunately, Nokia eventually gave up on it’s own Qt based devices in favour of Windows Phone as the software efforts were taking too long and they were falling a long way behind in the ecosystem wars. They sold Qt to one of their major services company suppliers – Digia – who have recently established a fully-owned separate entity for the product, The Qt Company. Only after being fully disentangled from Nokia has Qt been able to return to its roots as a cross-platform framework and start supporting the major mobile platforms. However, in the mean time, others had seen the great foundation for mobile apps that Nokia’s investment created. As a result the BlackBerry 10, Jolla Sailfish, Ubuntu Mobile and Tizen platforms all have Qt as a core framework.

From a personal perspective, I re-wrote a popular iOS game for Symbian using Qt in early 2011. The UI design and general debugging tools were a bit immature at the time but it was one of the simplest learning curves and most pleasant development experiences I’ve had on any platform (note: I was not paid to say that), even though the core of Qt is using the less than developer friendly but high performance C++. I was able to achieve smooth 60fps performance on some rather low-spec hardware. It was easy enough to learn their new UI technology, Qt Quick, and build the menu screens for the game with it in a couple of days.

Why HTML5, or why not?

HTML5 is the most popular option for developers building cross-platform mobile apps, however, it appears to be falling out of favour a little. Web browsers and web views are available on every platform and web developers are able to transfer their skills from building websites to building mobile apps. Open source frameworks like Cordova (PhoneGap) allow developers using HTML5 to access additional mobile specific functionality and make it easy to package apps in a native format for each platform. The added bonus is that you can usually have a version of your app on the web as well as in the app stores for minimal additional effort. HTML5 is generally more productive for building UI centric applications than native apps. There is also an embarrassment of riches when it comes to libraries and frameworks for building mobile web apps. Hybrid web apps are in the privileged position (on iOS at least) of being able to update their code directly, avoiding the App Store review process for all but major changes.

Slide12

Given its ubiquity and large developer base, why isn’t HTML5 the default cross-platform approach? [tweetable]Despite many advantages, hybrid web app developers have been struggling with performance[/tweetable] (partly due to crippled or outdated webview implementations, an issue which has been fixed in the latest versions of iOS & Android, although this will take a while to penetrate the entire installed base). There is also an issue with varying levels of support for standards across mobile browsers (again, this is something that’s improving but not entirely fixed yet). Web technologies have also not really been designed for the highly animated UIs that are now expected by mobile users. This is something that the much hyped Famo.us framework aims to resolve.

A number of very high profile consumer startups have publicly switched from web hybrid to native mobile app approaches. The most common reason stated for these switches has been lack of adequate tooling. It’s certainly possible to make web apps perform well on mobile devices within their limited memory budgets but with the current state of debugging and profiling tools, that’s still not an easy thing to do compared to producing native apps. This said, not all apps need flawless UI animations and we’re not comparing HTML5 with native, so lets look at how it goes head to head with Qt.

Qt vs. HTML5 – Pros & Cons

Supported platforms:

  • HTML5 is supported almost everywhere.
  • Qt is supported on all major platforms (and minor ones that happen to use it for their UI).

Although in theory you can target more platforms with HTML5, this is not how most developers are using it in the real world. [tweetable]HTML5 developers are increasingly abandoning the browser and building hybrid apps[/tweetable]. Most mobile developers are targeting some subset of Android, iOS, Windows Phone, Windows 8 and BlackBerry 10. Qt supports all of these and more. In fact, in practice our data shows that Qt developers actually target fractionally more platforms on average than HTML5 developers. As a result, this is basically a tie for most developers with a significant advantage to HTML5 for those who really want to run their software everywhere (feature phones, Smart TVs etc.).

Slide24

Learning curve:
This one depends whether you’re already a web developer. If you are, learning to build mobile web apps is probably easier than learning Qt. However, if you’re new to either then Qt has significant advantages in terms of having one framework to learn rather than 10s of them to choose from before you even start. Qt also has great documentation, which isn’t necessarily true for all web frameworks. In a fair contest, this is a clear win for Qt.

Openness:

  • HTML5 is open standards based and there are multiple open source implementations.
  • Qt is open source but dual licensed and effectively controlled by a single vendor.

Clearly HTML5 is more open than Qt. This isn’t always an advantage. The process of creating standards and getting multiple vendors to implement them is slow, Qt can be more agile. If you really need something fixed or a new feature added in open source you can do it yourself or pay someone to do it. If you need to support Internet Explorer and there’s an issue with it, you have to work around or wait for Microsoft. Then again, there’s no vendor lock-in with HTML5 and the web isn’t going anywhere. Someone else could buy Qt and take it in a direction that doesn’t align with your goals. Or they could just put the price up beyond your budget. HTML5 has the edge but it’s not a clear win.

Cost:

  • Building for HTML5 is free. There are some non-essential paid tools that can help.
  • Qt requires a commercial license for most commercial use on mobile.

Qt’s open source licenses are not compatible with distribution on most app stores. Although the iOS port of Qt is developed in open source, you need a commercial license to ship apps in the store. The lowest cost subscription that allows developing mobile apps for the iOS & Android stores with Qt is $25/month. HTML5 wins.

Cross-platform compatibility:

  • HTML5 has multiple independent implementations of a standard.
  • Qt has one vendor implementing the same runtime on multiple platforms.

Multiple implementations, with several in open source and a large community reporting on and working around compatibility issues makes for a very robust platform. Even so, having a single vendor making sure all platforms behave in the same way is almost always better for compatibility of your app. Qt wins.

Performance:

  • HTML5’s DOM was not built for modern mobile apps.
  • Qt Quick’s (QML) scene graph is built directly on top of OpenGL ES.

Both environments use JavaScript. However, with Qt it’s much easier to drop down to native code if you really need native platform functionality or performance. The performance penalties for switching between JavaScript and native code are much lower with Qt. The biggest difference however, is graphics performance. People looking for serious graphics performance with HTML5 resort to complex schemes to avoid touching the DOM as much as possible. Building the entire UI on top of WebGL seems like the most promising path to future performance, now that WebGL has much wider support (Apple adding this in iOS8 is key). Qt has a massive advantage here, it also has more extensive animation options than CSS3 for web app developers.

Native user experience:

  • With HTML5 you rely on either a 3rd party framework like Ionic or building your own clones of native interface elements.
  • With Qt you can use components that clone native interface elements, or use real native UI calls.

Being able to call native APIs in Qt potentially gives it the advantage here but in reality this loses cross-platform compatibility. In practice neither option is really well suited to situations where you need a genuinely native user experience. Both can emulate one adequately for a subset of possible apps. In general it’s best to use a cross-platform approach where a fully custom UI is needed, or a native look and feel is not essential.

Conclusions

Comparing across these metrics, Qt has a slight edge over HTML5. However, there are other metrics you could use that would give the opposite result. In practice the technology needs to be selected to fit the project. Both options have merits and if you’re an HTML5 developer who’s not already familiar with Qt’s offerings, they’re worth a look. I also didn’t mention that Qt apps can display HTML5 content in a webview, meaning that it doesn’t have to be one or the other, it can be both.

 

Which one do you prefer? Take the Developer Economics Survey and let us know.

Categories
Business

What Does Native Stand For In Native Advertising

Native advertising is not a recent buzzword.

[tweetable]Native advertising has been around for quite some time in the print and digital world[/tweetable]. Keyword-based search ads on a search results page, or an advertorial in a newspaper supplement are examples of such ads. But it’s only in the recent past that we have seen native advertising on mobile phones really take off. Traditionally, mobile advertising was limited to banner and interstitial ads but these ad formats compromised user experience. Native ads are a step-up from traditional ad formats and are designed to offer an in-context experience to the user.

Native-Content-Ads-1

What Makes Advertising Native

For an ad to be native, these are 3 things that matter – content, form and function.

  • Content: Does the ad unit have content that resembles the rest of the content on the page or does it stick out like a sore thumb?
  • Form: Does an ad become part of the content screen that the user generally takes notice of, or will it be a part of his blind spot?
  • Function: Does the ad unit match the functionality of the rest of the content or elements of the app in which it is displayed?

Native ads are deeply integrated into the mobile app. They mimic the look and feel of the content stream in which they are placed. This is completely different from traditional ad formats like banners, which due to their sticky position at the top or bottom of the screen have become a victim of banner blindness.

Native-Content-Ads-2

Consider a news app which has a feed with each news item consisting of a headline and an accompanying thumbnail. The content, form and function framework for native ads will then look like the following:

  • Content A native ad in this app should look similar to news feed, which means it should contain a headline and a thumbnail.
  • Form The visual elements of the native ad should be the same as that of a news feed. For example, if the thumbnail of every news item has a border, so should the thumbnail of the native ad.
  • Function If the news app requires users to scroll for news feed, then any native ad in this news app should also scroll along with the rest of the content.

Native ads sound great, but do they work

While the desktop world boasted of 1 – 2 percent Click-Through Rates (CTR) on native ads, mobile users seem to be more welcoming of this new ad experience. [tweetable]CTRs on native ads are 8X higher than traditional formats and advertisers are seeing 6X higher conversions[/tweetable] [source: InMobi network].

According to research by IPG Media, consumers looked at native ads 53% more frequently than display ads. The study also showed that users visual attention for native ads was nearly equivalent to the visual engagement of original editorial content.

Getting creative with Native Ads

There are a numbers of ways in which publishers can use native ads. The most commonly used ones are the app wall, carousel, chat list, content stream, content wall and news feed.

App wall

app wall

Carousel

carousel

Chat list

chat-list

Content stream

content-stream

Content wall

content-wall

News Feed

newsfeed

What to look out for while adopting native ads

Native ads are still relatively new to the mobile space and the level of customization offered varies amongst ad networks. Choosing the right ad network is therefore very critical when it comes to using native ads in your app.

Up until recently, native ads were implemented only by publishers with big teams, on a case by case basis with special effort required for every advertiser that they integrated with. The ease of integration offered by an ad network in terms of minimal programming overhead is another aspect to consider when integrating native ads.

Scale is the third thing you should look out for when monetizing your app with native ads. This wasn’t very scalable though. With more ad networks embracing the self-serve model, it is now possible to integrate native ads in your app without significant effort and in a relatively short time.

Focus on the user

The mantra behind native advertising is placing the user’s experience at the center. If not done well, native ads could boomerang on a developer’s monetization efforts. Editorial content and sponsored content (native ads) need to be clearly demarcated. Convention is to mark every native ad unit as an “Ad” or “Sponsored” content to ensure that users aren’t ‘tricked’ into clicking a native ad. As long as publishers and advertisers keep the user’s interests in mind, native advertising is set to transform mobile advertising.

Categories
Tools

Why Developers Should Embrace User Analytics

In our latest Developer Economics survey we were really surprised to see a dramatic fall in the level of adoption of User Analytics tools. A year ago they were the most popular category of third party tool with 38% of mobile developers telling us they used them. This time, only 21% of developers said the same thing. Why has there been such a significant drop? Are the hordes of new developers flocking to mobile just unaware of what’s available? Is all analytics being tainted by the spying scandals? Why does it matter?

user-analytics

The new mobile developer tsunami

At WWDC this June, Apple said that they’d gained almost 50% more developers in the last year. The vast majority of those will be iOS developers (rather than OS X and Safari). Android has been growing even faster in terms of new apps, so it’s likely there was even greater growth in the mobile developer population there. Windows Phone also saw significant growth in developer adoption. With so many new developers getting started building mobile apps we’d expect that they’re not all aware of the tools available to help. However, the reduction in user analytics adoption was greater than for other tools, indeed some tools categories saw increased adoption. So, although lack of awareness is clearly a contributing factor it’s not the whole story.

Tracking behaviours, not people

Information on government spying activities leaked by Edward Snowden has turned sentiment amongst many of the technically aware against digital surveillance. Perhaps some developers feel they shouldn’t be spying on their users’ actions? [tweetable]Does adding analytics to your app violate user privacy? Not usually.[/tweetable] User analytics tools are primarily for examining correlations between user behaviours and changes in the product or its marketing. If you make changes to a sign-up screen you need to see if it improves the fraction of users who sign up. If you’re trying to convert free users into paying users, it’s vital to analyse which changes in design or pricing result in greater revenues. Even to improve a paid up front or entirely free app, understanding what users do when they’re using it is incredibly valuable. As long as you’re not collecting personally identifying data and associating it with activity then it’s hard to see this as spying. Even segmenting users for behavioural targeting of functionality or advertising seems harmless as long as they’re anonymous. When analytics providers aggregate data across apps to build up user profiles for advertising, that may cross the creepy line for some. If this bothers you then choose an analytics provider appropriately, or collect your own data. If it doesn’t then having a privacy policy that clearly states who sees what data and what it’s used for is the responsible thing to do.

Coding blind

[tweetable]Updating and iterating on apps without analytics is apparently incredibly common[/tweetable]. It’s unlikely that all of these developers are regularly running user testing panels to get detailed feedback. Is everyone coding blind? To avoid constant app updates which would annoy users (and not even be possible with the review cycle on iOS) developers need to include multiple changes in every new version. If user sign-ups or revenue goes down after an update, how can you tell what went wrong? If things improve, which changes helped? Which parts of your app do people use the most? Are you working on improving features that no-one is using anyway? Without some kind of analytics, how do you find the answers to these questions? Might you be wasting a lot of effort?

Just integrating a third party analytics tool isn’t enough to answer these questions either. Apps need to be instrumented to log analytics events for every major action in the application and how long users spend on various activities. Beyond that, to really understand the effects of changes, users need to be analysed as cohorts – groups that started using the app around the same time. The value of an app to its users may increase or decrease over time and users who have got used to a UI are more likely to be unhappy with any changes. For an app that’s just starting to grow a user base, a change that causes it to lose 10% of existing users might still be positive if it increases revenues from new users. To know the real effects of some changes, it’s necessary to analyse specific sets of events as funnels. For example, in a registration or purchase process, increasing the number of people that start the process is no good if the number that end up completing it is reduced because they feel misled.

Tool choices

Developers that decide to embrace analytics have a lot of choices, however, the market is quite polarised. By far the most popular tools are Google Analytics and Flurry. These are (mostly) free. Google Analytics has the advantage with Android developers because it is integrated with Google Play, allowing direct tracking through the acquisition and download process into usage. It does have a (very high) limit on usage. If your app gets incredibly successful you’ll have to use the premium tier, which has a flat annual fee of $150k. Flurry on the other hand is free at every scale, although not as advanced as Google Analytics in terms of segmentation, funnels and visualisation of data. Both services are collecting data across apps, effectively to sell to advertisers.

There’s also a premium-only market with better support for cohort analysis, funnels, segmentation and visualisation. Paid offerings also link the analytics direct to actions, allowing automated real-time messaging to users, or the sending of push notifications to specific groups. Mixpanel and Localytics are two examples of tools in this space. These premium tools are also designed to be a lot more usable by non-technical staff, allowing a marketing team to analyse and react to analytics without always needing help from the development team. These tools have a fairly low user or datapoint count for a free tier and then start charging hundreds of dollars per month for successful apps. However, this means that they don’t sell the data from your app to anyone else.

A third option is the relatively little known Amazon Mobile Analytics solution. So far it’s relatively basic on the analysis front and doesn’t have the prettiest interface. However, you can collect 100 million events per month for free and beyond the free tier it’s just $1 per million events. By contrast, Mixpanel charge $2,000 per month for 20 million events. Amazon don’t share your data with anyone or report on it (no word on whether they use it internally for their own purposes).

Give it a try

Thinking about your apps as places to experiment and measure how the users react takes a change of mindset. If you’re not just building apps for fun then this shift can make a massive difference to your success.

If you’ve had a major change in results because of something you discovered using analytics, share your story with us in the comments.

Categories
Business Platforms

The 3 key Apple Watch features that nobody talks about. Yet.

[If Apple wants to create a new, large product category out of smart watches, they need to create mass-market demand for their new product. What are the 3 most important features that will define the future of the Apple Watch? The ones that enable developers to innovate on top of these devices and create demand for smart watches.]

apple-watch-09

“We believe this product will redefine what people expect from its category. … It is the next chapter in Apple’s story.” With these words, Tim Cook made it very clear that the Apple Watch is more than just an excellent product. As with the iPod, the iPhone and the iPad before it, the Apple Watch aims to shape the future of wearables and create a whole new market reality.

As it stands, the Apple Watch v1 is a nicely designed timepiece, an engineering wonder, but competition will be fierce. Since fashion is about self-expression, by definition, there will be no single winner.

If Apple wants to create something bigger than fashion accessories, the Watch needs to be a functional tool. If it’s a tool, [tweetable]Apple must answer a fundamental question: what is a smart watch for?[/tweetable]

https://twitter.com/brianshall/status/509405381857013760
https://twitter.com/BenedictEvans/status/509431691207659520

Will notifications become the killer app for smart watches? Unlikely. Not only is it unclear that we really want more interruptions, but it’s a bit of a dead-end for innovation. There can only be so many improvements in notifications, and only so many companies making those improvements.

If Apple wants to create a new, large product category out of smart watches, they need to become something much more that a timepiece with notifications and sensors. Something that allows people to do things that were not possible before. How Apple can do this? By following the same path that worked so well for iPhone and iPad: Tap into the limitless innovation power of co-creators to discover new use cases and possibilities we cannot imagine today.

The most important features of the Apple Watch going forward are the ones that enable developers to innovate on top of these devices and create demand for Apple’s smart watches. What are these features?

WatchKit

WatchKit

The straightforward way to expand the functionality of the watch is the WatchKit SDK, which allows developers to create “watch apps”. Other smart watch players like Android Wear, Pebble and Razer have made similar capabilities for developers. Developers are already showing strong interest in smartwatches. For example, the developer program of Pebble boasts 20,000+ developers and thousands of apps,.

HealthKit

The Apple Watch has a strong emphasis on embedded sensors for fitness and wellness. On the launch event, the company dedicated an entire section on it. Tim Cook: “This is a very important area for me and a very important area for Apple.”

But a few sensors and apps do not make a platform. The real potential lies in the HealthKit SDK that Apple launched at its WWDC event earlier this year. While its not technically a feature of the watch itself, it is this SDK that can take the device’s functionality and expand it in a whole new way to monitor activity and other wellness data . Could it be that the category that Apple wants to redefine is not the watch, but wellness and healthcare (in the broadest sense of the word)?

Certainly several other companies seem to go after that opportunity. Among them Google (Google Fit), Validic, Samsung (SAMI), Human API and most recently Jawbone (Jawbone UP API).

Identity

Like the Nymi wristband, the Apple Watch has all the technology in it to identify you personally. Apple has already demonstrated how digital identity combined with the Apple Watch can be used to make payments or even open hotel doors. (The clever integration with the new Apple Pay can drive adoption for both.) However, the possibilities are much broader. Biometric identification can be the end of not only passwords, but other kinds of ID as well. Another product category for Apple to redefine and absorb into its iOS universe?

Digital identity is a key control point for many digital leaders, including the likes of Google, Facebook, Twitter, LinkedIn and Salesforce. They are all actively working to hold your identity information and build your online persona on their platform. For Apple, the importance of identity is also evident in their deepening integration between devices and in their introduction of fingerprint sensors in all new phones.

Users first

What is a smart watch useful for? Beyond fashion and self-expression, a new kind of health monitoring and identity are prime candidates for the title of killer use case. Apple is going at it with their proven recipe for launching digital ecosystems: users-first. Apple starts by releasing a well-designed device for hardcore fans with a lot of value built in by default. Once there is a critical mass of users, Apple connects them with developers, who create real mass-market demand for the product.

It will take the ingenuity of a community of developers to explore all the possibilities and create a category killer, and Apple knows it very well.

Categories
Tools

Top Game Development Tools: Pros and Cons

According to our survey, a surprisingly high [tweetable]29% of games developers are primarily building their apps without a third party engine[/tweetable]*. They have either written their own engines, or are building everything from scratch. Large games studios very often build their own engines and tools, or customise open source solutions to suit their own internal processes and workflow. However, two of the most popular developer segments going for this option are Hobbyists and Explorers. It doesn’t make much sense for part-time game developers, or even small studios, to spend a lot of time working on their own tools rather than building games. In this post I’ll take a look at some of the most popular tools they could be using instead.

TOP-MOBILE-GAMES-TOOLS-FINAL

Which are your favourite tools for games development? Let us know in our new Developer Economics Survey and you might win an Occulus Rift Pro and other hot prizes.

Unity – the people’s champion!

unity

As developer tools go, Unity is incredibly successful. A massive [tweetable]47% of developers in our survey use Unity for some of their projects and 29% use it as their primary development tool[/tweetable]. This is not just Hobbyists taking advantage of the free licensing options, Unity is more popular with professionals in general and most popular with the Hunters (53% of them) who are trying to earn their living from the app stores.

 

Unity supports both 2D & 3D game development, which is quite unusual for a game engine. That said, Unity was really designed for 3D games with 2D support bolted on afterwards; the 2D features were initially just for building menus and other 2D screens needed in a 3D game, to avoid the need for an external tool. The features were quite generic and developers started building games with them; probably due to the broad cross-platform support. To their credit, Unity have supported this and continue to invest in the area.

Supported languages

Three development languages are officially supported: C#, UnityScript (basically JavaScript with type annotations) and Boo. The last of these, Boo is not widely used and probably best avoided. Given its name, you’d be forgiven for thinking that UnityScript is the main development language, it’s not. The Unity community has widely adopted C# and you’ll find the majority of plugins and examples use it. If you prefer JavaScript and only have a very simple project in mind then UnityScript is a good option. Once you start using plugins written in C# that potentially need to call back into your UnityScript you’ll find issues with compilation order and wish you’d gone with C# from the beginning.

Pros

Unity has a lot of great features:

  • Unity has a very strong community of asset and plugin creators – there’s lots of free and reasonable priced content available.
  • Unity’s visual editing tools are excellent and the editor can be extended with plugins.
  • It supports a wide range of asset formats and converts automatically to optimal formats for the target platform.
  • It supports a very wide range of platforms, mobile, desktop, web and console.
  • Deployment to multiple platforms is very easy to manage.
  • The 3D engine produces high quality results without any complex configuration (I’ve personally written a licensed game with Unity that Apple has featured in lots of countries).
  • There is a free license that covers the majority of features.
  • Paid licenses are very affordable for most professional developers, available on subscription for $75 per platform currently (some platforms are free).

Cons

There are a few issues which are worth considering before choosing to go with Unity:

  • Collaboration is difficult. Unity has an expensive asset server product to help teams collaborate. If you don’t use it, sharing code and assets between team members can be painful. The best option is to enable and use external source control but there are several binary files (which don’t need to be) that can’t be merged and updating assets often causes them to break things in scenes, losing connections to scripts and other objects.
  • Performance is not great – until very recently Unity ran almost entirely in a single thread and made almost no use of the extra cores in most mobile devices – this is improving in Unity 5. The compilers are not at all well optimised for the ARM processors in almost all mobile devices – Unity have decided to transpile to C++ and use LLVM to get a more optimised build rather than solve this problem directly in future releases.
  • The engine source code is not available. Even paying users don’t get to see the Unity source code, which means if you come across a bug in the engine you have to wait for them to fix it or work around it. It’s always going to be more critical for you than it is for them. This also limits the ways in which you can extend or customise the engine.

Overall, Unity is a great choice, particularly for solo developers who aren’t trying to push the limits of what the platforms can do.

Cocos2d – perfect for casual games

cocos2d

Cocos2d is, as the name suggests, a 2D games engine. It originated around the same time as the iPhone SDK and quickly switched to Objective-C, growing in popularity as the best free and open source option for mobile games. However, Apple released their own highly performance optimised 2D engine for Objective-C developers called SpriteKit. That, along with the rise of Android, has caused the focus of Cocos2d development to shift towards the cross-platform Cocos2d-x branch written in C++. The Cocos2d family of engines is the most popular open source option in the world, used by 19% of game developers in our survey and by 8% as their primary tool.

Supported languages

There are different versions of Cocos2d available in Objective-C, C++, C#, Java, JavaScript and Ruby. As mentioned above, the C++ version is the most actively maintained, it also has the widest range of supported platforms. There are also scripting language bindings to the C++ version in both Lua and JavaScript, enabling developers to write in their preferred scripting language but get the full native performance of the underlying engine.

Pros

As with most thriving open source products, there’s a lot to like about Cocos2d:

  • Broad range of supported platforms, particularly mobile ones.
  • Free and open source (MIT license).
  • Wide range of extensions, tools and open source code available.
  • Lots of community created examples and learning resources.
  • Large peer support community.
  • Hardware accelerated graphics and good performance.
  • Audio support (in most versions).

Cons

Nothing’s perfect, here are a few issues with Cocos2d:

  • There’s no large commercial entity providing support and bug fixes. It’s great that you can fix it yourself, or hire someone who knows how. The community might even fix your issue for free but sometimes when a big project hits a bug or performance issue close to a deadline you just want to be able to pay someone to make it go away.
  • The APIs are somewhat unorthodox. The history of the project is such that it started in Python and moved to Objective-C very early. The Objective-C wasn’t exactly following standard practices and then that got ported to C++, retaining the Objective-C idioms.
  • It doesn’t do much to encourage good structure. Some developers like frameworks that don’t impose a style on their apps but Cocos2d goes a bit far. It’s possible to write code that’s hard to maintain in any system but it’s easy to find examples of Cocos2d games with really long functions and a lot of global state.

OK, the cons are nit-picking and more warnings that really negative points. After all, poorly structured code and unusual APIs are not exactly barriers to success. I’ve ported a game from iOS that was written with Cocos2d (the Objective-C version, before the C++ variant existed) and almost one giant method with tens of global variables. At one time it was the number 1 paid download on iOS in several countries. Cocos2d-x is an excellent choice for a 2D game.

Adobe AIR – what remains of Flash

Adobe AIR

In 2007 Adobe seemed to be winning the casual games runtime battle, with Flash having become the defacto standard for games on the web and Flash Lite almost ubiquitous on more advanced mobile devices. Then the iPhone came along and Steve Jobs said it wasn’t going to support Flash. This knife wound wasn’t immediately fatal but Flash has been slowly bleeding to death ever since. By 2011 Adobe eventually produced a version of AIR that compiled Flash to native iOS apps but by then the damage was done. Android initially supported Flash, poorly, in the browser but Adobe eventually gave in and stopped developing the browser plugin to focus on AIR. There are still a lot of Flash developers in the world, 15% of mobile game developers use it and 6% of them as their primary tool. It’s also still, just about, the only way to target rich gaming experiences to the majority of the world’s desktop web browsers. Adobe is now focussing on tools for HTML5 developers and Flash/AIR has not really evolved in a long time. Given this background, I won’t focus on detailed technical pros and cons as with the other tools.

Supported languages

Adobe AIR applications are developed in Flash, coded using ActionScript. There’s an integrated web view which can be targeted with HTML, CSS and JavaScript. It’s also possible to build native extensions for AIR apps, individually for each targeted platform.

Pros

Flash is still a capable environment for simple 2D games. If you already know Flash it’s one of the fastest ways to build a mobile game.

Cons

The platform is a dead end. I couldn’t recommend anyone who doesn’t already know Flash to learn it. Those who are fans of ActionScript but don’t like HTML5 should probably look at Haxe.

Unreal Engine 4 – the AAA king goes mass market

Unreal-Engine

The Unreal Engine has a long history as one of the top 3D games engines for PC and console platforms. The 3rd generation of the engine supported mobile platforms but it was really only for hobbyist developers tinkering with their limited UDK or the multi-million dollar licensees of the engine for console games porting their titles to mobile devices. In March this year, Epic Games released the Unreal Engine 4 to anyone for $19/month plus 5% revenue share. This offering includes full access to the engine source code and their suite of tools. This change was not long enough before our survey was launched to see significant adoption by developers but 13% were using it with only 3% as their primary tool.

Supported languages

The Unreal Engine is written in C++ and that’s the only supported development language. However, it’s possible to do a lot of development without writing any code using Blueprints – a visual programming environment where nodes are connected with lines.

Pros

The Unreal Engine is AAA game quality:

  • Incredible performance. The Unreal Engine was demoed using Apple’s new Metal graphics interface at WWDC. It can produce the most realistic graphics ever seen on an iOS device. The same will be true for (high end) Android devices.
  • They have state of the art tools for all aspects of game development.
  • Full source access enables extension, customisation and engine bug fixing.
  • The pricing model is an excellent match for the high risks of failure on the App Store.

Cons

The Unreal Engine is designed for professionals:

  • Development is in C++, not a beginner friendly language.
  • The learning curve for the tools and engine is significant, greater than Unity.
  • The engine has limited support for older devices.
  • The pricing model is very expensive for a successful title, unless you expect significant success and use the engine under a different licensing model.

The Unreal Engine is an excellent option for high quality 3D games on high end mobile devices but it won’t be for everyone. I expect to see increasing adoption across the next couple of years. If you’d like a free 3D engine with scripting language support it might be worth checking out Project Anarchy by Havok. It’s effectively subsidised by Intel (owners of Havok) for mobile devices. There’s a co-marketing option in the license and you have to build an x86 variant if you build for Android (or Tizen, if that ever happens), otherwise it’s completely free, only the PC version is paid.

* Apple’s SpriteKit on iOS is actually a fully functional 2D game engine but as it’s part of the platform, developers may legitimately have said they were only using native code. If this is popular then it may significantly reduce the 29% figure.

Which are the best and worst aspects of each tool? Here’s your chance to have your say. Take the survey.

Categories
Tools

Five popular databases for mobile

More and more mobile applications need data to work, and databases have for quite a while been the most common way of storing and managing data. So, in a typical scenario, a mobile application uses a database that is hosted in the cloud, and connects remotely to it in order to access its data. This, of course, implies that, in order to be responsive, a mobile application needs an active and quite fast network connection.

shutterstock_126489872

Where is mobile development heading to? Take the Developer Economics Survey that is now live and shape the future of mobile development.

But what if you could move your database from the cloud onto the mobile device, thereby allowing your mobile application to satisfy its storage needs without having to rely on any back-end storage service? Or what if you could keep your database in the cloud, but at the same time maintain a local up-to-date replica of it that would allow your application to be fully functional even when no network connection is available and to sync with the remote database periodically or when going back on-line? And what if you could do all that by using the same or similar tools with the ones that you are using now?

Embeddable databases are lightweight, self-contained libraries with no server component, no need for administration, a small code footprint, and limited resource requirements. Mobile applications can be (statically or dynamically) linked to them, and then use them in order to create and manage their own – private or shared – databases locally on the device. Behind the hood a database-management-related action typically involves only a few function calls within the same process.

At the moment there are several embeddable databases out there that you can use in a mobile application. Let’s examine the most popular of them and highlight some of their characteristics that have contributed to their widespread use. The next table gives an overview of the type of the data that each one of these databases can store, the license under which it is distributed, and the platforms it supports.

Database Type of data stored License Supported platforms
BerkeleyDB relational, objects, key-value pairs, documents AGPL 3.0 Android, iOS
Couchbase Lite documents Apache 2.0 Android, iOS
LevelDB key-value pairs New BSD Android, iOS
SQLite relational Public Domain Android, iOS, Windows Phone, Blackberry
UnQLite key-value pairs, documents BSD 2-Clause Android, iOS, Windows Phone

Berkeley DB

berkeleydb

Berkeley DB is a family of open-source libraries that allow you to manage your data either in the traditional relational way (using SQL) or as key-value pairs (where both keys and values are byte arrays) or as Java objects or as XML documents. Regardless of the API you choose, Berkeley DB promises indexing, caching, transactions, single-writer/multiple-reader access, full-text search (for the SQL interface), automatic failure recovery, replication, compression and encryption. It also supports both in-memory and on-disk databases.

Another intriguing feature of Berkeley DB is that the SQL API it provides is fully compatible with that of SQLite. As a result, you can make your SQLite applications use Berkeley DB as the underlying storage engine without having to re-write them. All you need to do is link them to a suitable version of the Berkeley DB library. This combination of SQLite and Berkeley DB has been reported to perform better in case of highly concurrent, write-intensive applications.

Berkeley DB provides API bindings for several programming languages, including C++ and Java, and has been compiled, run and tested on several operating systems, including Android and iOS. Nevertheless, you might be put off by its AGPL license, in case you want to use it in your application, but you do not want to distribute your own source code in exchange.

Note also that, mainly because of its effort to provide features that are expected in traditional client/server databases, Berkeley DB is considered as a relatively heavyweight solution. So, unless you absolutely want a feature that is only offered by Berkeley DB, then there are other more lightweight alternatives you can choose from.

Update: Even though Berkeley DB technically supports iOS, it can’t be used in App Store apps due to license incompatibility with App Store terms & conditions.

Couchbase Lite

CouchbaseLite

Couchbase Lite is a document-oriented database: data is stored as JSON documents. Each document may have one or more attachments, which are essentially uninterpreted binary data that is stored and loaded separately from the document itself. Couchbase Lite supports persistent indices (called views), and uses map-reduce to manage and query them.

Couchbase Lite, together with Couchbase Sync Gateway and Couchbase Server, are the three components of the NoSQL JSON mobile database solution offered by Couchbase called Couchbase Mobile. One of the key features of Couchbase Mobile is built-in synchronization (through Couchbase Sync Gateway) between local databases (Couchbase Lite) and databases in the cloud (Couchbase Server), which relieves the developer from the burden of writing their own sync code. In order to support this feature, Couchbase Lite comes with a conflict resolution mechanism that is quite similar to the one used by Git.

Couchbase Lite provides a Native API for both Android and iOS, as well as plug-ins for two widely used cross-platform tools for mobile development: PhoneGap and Xamarin.

LevelDB

leveldb

LevelDB is an open-source library (written at Google) that implements a key-value store, where keys and values are byte arrays, and data is stored ordered by key (based on some, probably custom, comparison function). LevelDB supports atomic batch updates, forward and backward iteration over the contents of the store, snapshots (i.e. consistent read-only views of the entire store), caching, data integrity (using checksums), and automatic data compression (using the Snappy compression library). An important limitation imposed by the library is that at any moment at most one process can have access to a specific database.

“LevelDB has good performance across a wide variety of workloads” state its authors, and here are the results of a benchmark they put together to prove their claim by comparing LevelDB with SQLite and Kyoto Cabinet (another key-value store implementation).

LevelDB is written in C++. iOS developers can use it directly in their applications or through one of the several Objective-C wrappers that are available for it. Android developers can use LevelDB via JNI and NDK.

SQLite

sqlite

SQLite is an open-source C library for managing relational databases that can be stored both on disk and in memory. It supports dynamic typing (types are assigned to values, rather than to columns), transactions, full-text search, single-writer/multiple-reader access, efficient range queries (useful when storing geographical data), and shared caching (across connections opened by a single thread to the same database).

SQLite stores each database as a single disk file in a cross-platform format. This implies that you can create an SQLite database on one machine and then use it on another machine with an entirely different architecture by simply copying the corresponding file.

The authors of SQLite believe that it is “the most widely deployed SQL database”. Bindings for SQLite are available in most mainstream programming languages. SQLite is also included in both iPhone and Android operating systems.

UnQLite

unqlite

There are a lot of people that incorrectly believe that UnQLite is the NoSQL counterpart of SQLite, although the two products are completely independent. UnQLite is an open-source database that exposes both a key-value and a document store interface. It supports both in-memory and on-disk databases, transactions, multiple concurrent readers, and cursors for linear traversal. Like SQLite, UnQLite uses a cross-platform file format, and stores each database in a single file on disk.

No matter which store interface you use, UnQLite’s storage engine works with key-value pairs. A distinctive feature of UnQLite is that you can change at run-time the storage engine that is used. At the moment, UnQLite comes with two built-in storage engines, one for on-disk and one for in-memory databases.

UnQLite is written in C, and can thus be used in both iOS and Android applications (in the latter, through JNI).

 

Our Developer Economics Survey is now live. Have your say, shape the future of mobile development and win amazing prizes and gear. Start now.

Categories
Business

Is the Indie App Opportunity Gone?

The app stores created an opportunity for any developer to build their own products and reach a global audience with them. For some developers this offered the promise of an independent app business, giving them creative control of their work and hopefully a comfortable income. Recently there have been lots of posts (great summary list here) from current and former independent app developers about the state of the market and how much harder it is to earn a living from your own apps. If it’s tough for established indie developers then is it still possible to get started? We’ll look at how the market has changed and share some data on the revenues of over 500 solopreneurs and small indie developers versus their bigger rivals.

indie_game

The indie developer gold rush

[tweetable]A key advantage of small indie app developers is their agility[/tweetable]. They can shift their strategy to take advantage of new opportunities incredibly quickly. The success story that may have started the iOS app gold rush was built before there was an official SDK or App Store. Steve Demeter was working on ATM software for a bank and built the game Trism in his spare time, initially releasing it for free to the jailbreak community. When the App Store launched it was initially a $5 paid download that earned $250,000 in profits in the first two months. Demeter quit his day job to become one of the first full-time iOS indie app developers. Trism was reduced to $3 to stay competitive but went on to sell around 3 million copies. Four months of evenings and weekends, just a few weeks equivalent in full time development, earned a life-changing amount of money.

It’s the overnight success stories like these that continue to drive lottery-like behaviour from some developers. Playing for the outside chance of winning big. Even the media coverage at the time noted the increasing competition with more than 1500 iPhone games available in the App Store! Today’s developers would love so few apps to compete against; there are now hundreds of times as many.

Raising the bar

By 2011 life-changing solo developer success on the app store looked rather different. A $5 app created in a matter of weeks wouldn’t stand a chance. Andreas Illiger is a gifted musician, artist and coder. His Tiny Wings took 7 months of full time effort to create and sold for just $0.99. The increased scale of the platform meant he was able to sell more than 10 million copies. In 2014 it’s debatable whether a solo developer will ever repeat the feat. Monument Valley looks like the modern benchmark for a chart topping paid game title but developer UsTwo primarily serves clients in three countries and has over 100 staff in the London studio that created the game. Sirvo’s Threes! is a better comparison yet it was created by three people over a 14-month period (not full time). Threes! was almost immediately copied with numerous free alternatives to the $1.99 original springing up. Whilst Tiny Wings enjoyed a year as a top 10 game and another two inside the top 50, Threes! is already in danger of heading out of the top 100. [tweetable]There’s just so much free-to-play competition[/tweetable]. Making a more complex game to differentiate from the crowd is just beyond the scope of most small independent developers.

Not just games

Those examples have focussed on games and it’s tempting to think non-game apps might be a different story. However, consider that our data shows only 33% of developers are making games. Those developers collectively earn over 80% of store revenues across iOS and Android. So [tweetable]67% of developers are competing for less than 20% of store revenues[/tweetable].

Lets take a look at what Hunters (our name for developers that are aiming for direct revenues from their apps) can expect to earn at different company sizes.

As you can see, iOS is still a much healthier place for an indie app developer to be than Android but unless your cost of living is very low then the chances of making a comfortable living aren’t great. The bigger developers are taking over the top charts. [tweetable]If you’re outside the top app charts then it’s incredibly hard to get noticed[/tweetable]. Some of the successful smaller developers in our survey already have established apps with a strong history of downloads and ratings that keeps them high in the search results. If you’re just starting out, is it still possible to join them?

Find the right sized niche

The key difference with non-game apps is that they don’t all compete for the same attention. If your indie developer dream is to build the app you really want to use and be richly rewarded for it, you’d better have a fairly unusual problem that you want solved. Jared Sinclair’s Unread is the cautionary tale for those wanting to build for other technology lovers like themselves. An RSS reader (or client for any popular internet activity), however beautifully executed, has to compete with a vast array of free alternatives. Many of those other apps will have been built by hobbyists with no need to make any revenue at all. Anyone wanting to succeed as an indie developer today needs to think like a small business. Trying to compete with hobbyists is as futile as trying to compete with Google.

The right sized niche for an independent app is one that’s small enough not to be interesting to much bigger competitors but big enough to earn a living. Even winning the niche is not going to support a big team. The best niches will need specialist knowledge or intellectual property that make them both unattractive to hobbyists and defensible. Ben Thompson provides a great case study of Pleco, a Chinese dictionary app with some high-value in-app purchases. This example has two key advantages worth replicating: unique licensed content and a natural channel to market outside of the app stores.

What about getting rich?

If that sounds more like hard work than the indie developer dream of becoming an overnight app millionaire, it is. It’s also many, many times more likely to succeed. [tweetable]If you want to be an app millionaire then build contract apps for businesses and grow a team[/tweetable]. Then build some products for enterprise customers in niches that won’t attract immediate competition from much better funded rivals. Or get some venture capital and think really big! If you prefer the dream of being a millionaire, stick to building apps in your spare time. Better yet, buy a lottery ticket, it’s much less effort for about the same odds.

Categories
Business

The European App Economy 2014: Europe is losing ground to Asia

We have just published a research note with an update to last year’s an European App Economy report. The good news is that Europe’s app economy still accounts for 19% of global revenues and is growing strongly at a 12% annual rate. The bad news is that the rest of the world, particularly Asia, is growing much faster. The global app economy is growing at 27% annually and the share of revenues captured by developers in the EU28 is falling. We estimate that around 1 million European jobs have been created by the app economy so far. If policymakers want to see this job creation continue then there’s a lot more they could do to support developers attempting to create businesses.

European-App-Economy-2014_final

A $16.5 billion market

In our App Economy Forecasts 2013-2016 report we estimated that apps and app related products and services would generate $86 billion in revenues globally in 2014. The 19% share of this generated by European developers will contribute $16.5 billion to EU28 GDP this year. This is many times more revenue than is generated directly in the app stores. However, the EU is home to the top 2 app store earners globally in Supercell (Finland) and King (UK) – masters of the Free-to-Play games market. At the same time, European policymakers are some of the most vocal in attempts to enhance consumer protection with respect to the Free-to-Play model. So far there is only strong encouragement to reform practices around cost transparency but this could (justifiably) lead to regulation if insufficient voluntary action is taken. Significant changes in this area would undoubtedly impact the revenues of Europe’s most high profile app market success stories.

1 million jobs

We estimate that the number of direct European app economy jobs is up 26% from 2013 to 667,000, this breaks down as 406,000 professional developers and 261,000 non-technical roles in app-related business. Using a conservative multiplier we also estimate another 333,000 jobs have been created indirectly by the app economy in the EU28 for a total of 1 million jobs. A large fraction of these jobs are in software services companies taking the low risk route to profitability building apps on a contract basis. Contract software development is the most popular revenue model in Europe, favoured by 31% of developers. This may be partially due to the relative lack of seed capital for startup ventures in the region along with a relatively high cost of living versus most global competitors, making bootstrapping products more difficult.

2a

Slower growth

Although the European app economy is growing at less than half the global rate, some loss of share was unavoidable. Europe was very quick to reach high levels of smartphone penetration and most of the device sales growth is in developing markets. A significant fraction of demand for apps will always be filled by local developers with better market knowledge. As smartphone penetration increases in developing countries their local app economies are growing rapidly. European developers are well placed to export to English-speaking markets and South America but it’s not so easy for them to succeed in Asia. It’s likely that developers based in the EU will need specialist support or local partners to maximise app export opportunities in some of the fastest growing markets.

The enterprise opportunity

As smartphones reach saturation, businesses will play an increasing role in the growth of the app economy in Europe. In our Business and Productivity Apps report we forecast that this sector would experience rapid growth, reaching $58 billion globally by 2016. We have identified 5 areas where app developers and startups can add value in the business & enterprise app sector:

  • Vertical market specialisation
  • Productivity/BYO apps
  • Mobile SaaS
  • Bespoke enterprise apps
  • Mobile application and device management

While European developers are well placed to win bespoke enterprise app development business, they may struggle to compete with better funded rivals from other regions for the larger opportunities. Starting a technology business has never required less capital but scaling an enterprise software business is incredibly expensive to do quickly. The biggest mobile SaaS, application management and vertical market opportunities are likely to be venture capital fuelled land grabs. To ensure that Europe makes maximum gains from the future growth of the app economy, policymakers need to do all they can to keep app entrepreneurs from relocating to Silicon Valley in order to access the expertise and capital they need to compete.

Categories
Tools

Agile tools for the Samurai Coder

This post is not meant to help you understand agile methodologies. A simple Google search will be enough to reveal tons of posts presenting, explaining, analyzing and suggesting how to make agile methodologies work to your advantage. And we have to keep in mind that they all usually apply to teams of 3 or more people. This post is about the freelance developer who just needs a simple way to manage tasks and projects. I do not claim that I present the absolute and irrefutable Truth; every person has their own way of working. This post simply intents to be a starting point to another way of doing things.

Meet Sally. Sally is a developer, a Samurai Coder, a hero of the day and she absolutely loves writing code. She works as a freelancer and the other day she got a new project from a customer.

Before starting work, she picks up a piece of paper. She writes down the day’s tasks (to-do’s, appointments, ideas etc) and crosses off the completed ones. She repeats the same process every day. These sheets of paper pile up and follow her everywhere… until she finds Evernote. Evernote replaces the paper and uploads her notes to the cloud, but still…. The notes multiply just as much and just as quickly as the papers do. They only stop creating piles on her desk.

Sally is desperately in need of solution – a way to capture and track her customer’s numerous requests as well as the 100+ things she has to do. What about a bit of agility and organization? How about combining simple methods and tools to get things done? Sally gave it a thought and found out the 5 most important things to her:

  1. Ability to separate projects and tasks.
  2. Clean visual overview, i.e. understand what needs to be done, watch the progress or the big picture, and prioritize accordingly.
  3. Sharing and Collaboration features.
  4. Accessibility, i.e. ability to retreat her work through any device in real time.
  5. Speed, i.e. Sally’s work is programming, not using tools. Tools should work for her, helping her save time, and not the other way around.

The simple process

  1. Here’s a really simple and basic five step-process that Sally could follow. This kind of flow is Kanban-like (but I will talk more about Kanban on another post).
  2. Create a repository for every project.
  3. Separate it virtually in 3 areas: to “To Do”, “Doing” and “Done”.
  4. Add new tasks, requests or bugs in the “To Do” area.
  5. While working on a task, move it from “To Do” to “Doing”.
  6. Move the task to “Done” when completed.

image00

The tools

There is a great variety of software tools in the web; tools for small teams, big teams, distributed teams… But how about one single person? We will see how Sally can follow this process with the use of 3 simple tools: a) Trello, b) Asana and c) Wunderlist

a) Trello

Trello’s visual layout is very intuitive. Imagine a dynamic whiteboard with columns (lists) and cards (like advanced sticky notes).
How to use it:

  1. Create Project with the use of Trello Boards: Each Trello board represents a project. Add lists (columns) to simulate progress. Add cards as tasks. And that’s all…
  2. Managing Tasks: A new Board has by default three basic columns: “To Do”, “Doing” and “Done”. You can drag a card over these columns anyway you like and you can always visually track both the card and its status.
  3. Handling of requests or bugs: Trello has a color mapping that you can apply on the cards (e.g. red color for bugs). You may add lists, comments and much more.

image01

b) Asana

Asana is an advanced task list oriented application with an equally intuitive visual layout to Trello. It is fast, easy to use and quite popular.
How to use it:

  1. Create Project with the use of Asana Projects: Start a new project and add tasks in the center column.
  2. Managing Tasks: Tasks added in the center column get a level of hierarchy and may be stacked. You can start by creating the three high level tasks “To Do”, “Doing” and “Done” and then fill them with specific tasks accordingly. You can easily create a task, drag it to move and edit its details on your right hand side (add sub lists, comments and more). There is a checkbox in front of every task and may be checked if the task is completed. By doing so the task is removed from sight but if you prefer you can manually drag it bellow “Done”.

image02

c) Wunderlist

Wunderlist is a pure task list oriented application, though their newest update has many improvements including Collaboration and Public Lists. It has a clean UI and is much simpler than Asana, quite fast and user friendly.
How to use it:

  1. Create Project with the use of Lists. Add a new list and add tasks in the main column. Just like a true boss…
  2. Managing Tasks: Add tasks in one column. In order to create some kind of flow for your tasks, create more lists (see the example in the pic below). Wunderlist is quite easy to use, but not as advanced as other tools, i.e. missing collaboration features, ability to assign subtasks, etc.

image03

All of the above tools are equally fast, have the ability to collaborate (add more people to your list/project) and can sync to other available devices.

Quick Verdict:

Trello

 

+ Nice visual and collaboration.

 

– No task sub lists (there is a great checklist feature, but there is a minor problem: you cannot assign tasks to these lists. As a result you need to create separate cards).

 

– The visual style with the cards may overcrowd the board making it look messy.

 

Asana

 

+ Nice interface, quick.

 

– Not a nice “big picture” or “flow” visibility

 

Wunderlist

 

+ Nice simplistic UI, powerful task list.

 

– Missing advanced features the other tools offer.

 

+ Their recent update added collaboration features.

 

Sally in our story has therefore many great tools in her disposal. All she has to do is put her pen and paper aside and work easier and faster. And you can all join her!

Categories
Tools

Users Are People Too: The Key to a Successful App is Knowing Your Users

Given the staggering odds against the success of any app in the marketplace, it is surprising that so much effort is devoted to the creation of apps, many of which never see the light of day.

Today, there are over 1.2 million apps in both Apple’s App Store and Google Play, of which just 500,000 are ever downloaded. Out of the 500,000, 20 percent are only opened once in the first 6 months after download, and almost 50% are used no more than 5 times.

brains_thumbnail

Growth hacking relies on incomplete data

With very few exceptions, pure word-of-mouth and organic growth without additional effort on the developer’s part is not enough for an app to surface above the noise. As a result, an entire cottage industry of “growth hackers” has emerged, one which takes traditional marketing approaches and combines them with rigorous metrics to make sure that every step of the process is measurable and actionable. For example, Quora closely monitored the behavior of their most active users. They found patterns that were used to stimulate other users to behave in the same way.

[tweetable]One of the limitations of the growth-hacking approach today is that the mobile ecosystem is still a Wild West[/tweetable], similar to where the desktop software industry was some 10-15 years ago. The most established mobile tools, such as Flurry and Google Analytics are really good at telling developers how users are using the app… which version, operating system, for how long a user engages in the app, which buttons are being pressed, etc… but do little to tell you anything about the wants and needs of the people using the apps.

While these descriptive analytics are critical, there is another piece of the puzzle for creating a successful app, which has been undiscovered by developers today: human understanding.

Human understanding is defined as the knowledge about a user’s demographics, interests, and intents. While tools like Flurry and Google Analytics are starting to provide more of these user insights, they are typically presented in aggregate form, which makes a user hard to understand on an individual level.

Understanding your users

So what can be seen as an improvement? How do you know if you are providing more value to a user or if you’re slapping on features your users don’t care about? The answer lies in understanding your users.

A good place to start in trying to understand your users is to use analytics tools. This seems obvious but only 21% of app developers use these. The most basic information that could provide significant value is to know the demographics of your users. Are they mostly male or female? What is the age distribution? What is their income distribution? Also, from what countries are your users and what languages do they speak? With this data it is possible to make broad categorizations of users. For example, data can show that your app is popular in France among middle aged women. Without being prejudiced, one can assume their English is not great. Translating your app can boost its popularity even more and increase overall satisfaction with your app among these group of users.

The subsequent step is to find out what interests your users have. Integrating social media login possibilities in your app and asking for the right permissions can provide you with all the self-declared interests of the user. Combining this with their demographic data gives you improved segmentation options, which is another step towards a true understanding of your users.

Contextual information is important to consider as well. Where are people using your app; at home, while commuting, at work or in the gym? When are they using it? Only at night? Several times a day? How does this correlate to other users and what conclusions can you make from this? Also, on which devices/operating systems are they using your app at home and which ones while travelling? Figuring this out can direct your creativity and efforts to build features that cater to the context in which your app is used.

Given the vast amount of apps that are offered, no matter how unique your app is, your app has competition. To understand your user isn’t limited by figuring out who they are and how they behave in relation to your app, it’s about the competition as well! How often and how much do your users log in to competitive apps? What are the unique features of the most used competitive apps? Knowing this provides valuable information of what users appreciate in competitive apps.

When all these questions are addressed there is a huge opportunity to grasp. Combine the segmentation information with the usage data from your app – sessions, time in app, ads clicked, screen flow, transactions, returning user, etc.- to identify your most valuable, most engaged and/or most loyal users. Who are they? How are they using your app? If you find answers to these questions, you’ll have identified the people who value your app the most, as well as how they use it and which features create value for them. Having this insight can mean the difference between the life or death of an app. However, it’s important to consider that ultimately the actions that are taken based on these insights decide the future of the app.

What to do next

When you know who are your most valuable (whether this means most loyal, engaged, contributing to revenue, etc.) users you can start targeting and catering to the needs of those users. For example, when implementing changes in the user interface, most developers use some form of A/B testing to figure out what the effects are. This acclaimed method of improving your product can be even more effective when you filter out the effects of those users that are of little value to you. For example, you can be A/B testing an ad in order to optimise clickrate, but seeing very small differences between the two groups. However, if you segment your audience you may see vastly different results; your target group of ‘valuable’ users might be much more engaged with the content than other user groups. The same technique can be implemented for building new features, expanding your offering of in-app purchasable items and personalizing content. [tweetable]By knowing your users you are able to make better and more timely decisions to improve your app[/tweetable]. Over time, your most valuable users are perfectly catered to which makes them love your app even more. This results in a higher retention rate, more engagement and a higher chance of getting recommended to their peers.

Financially, knowing your users makes sense as well. You can offer your ad space to advertisers that are targeting the segments you identified to be your most loyal and engaged users, which raises the eCPM and lowers idle time of your ad space. Additionally, marketing efforts to obtain new users yourself can also be highly targeted. Most developers greatly underestimate and are dissatisfied with the cost of acquiring new (valuable) users. With true user understanding it is possible to specify efforts and use your marketing budget efficiently and effectively, simply getting more bang for your buck. This is especially relevant for developers who are trying to make a decent living from their apps. These findings correspond with those of advisory company Gartner. They concluded that in order to make an app profitable, developers need to win customer’s loyalty and satisfaction by delivering a well designed and top-performing product.

Building your next app

Success is a concept that can mean different things to different people and different kinds of apps. Some developers don’t like to discuss marketing and the business side of developing and maintaining an app, but it’s an indispensable part of making an app successful. For the people that are in it to make a living, knowing your users is crucial. Raising your ads’ eCPM, lowering its idle time, getting a higher return on marketing investments and a higher Life Time Value (LTV) is worth taking the time to get to know your users. Your efforts will be focused to cater to your most valuable users which greatly improves effectiveness across all your activities, from building new features to marketing your app.

Having these insights doesn’t have to be limited to just one app. Building your next app based on this vital information can give you a head start. You can use it to answer questions such as: What platform should I focus on? iOS, Android, both or try other platforms with less competition? Optimize for smartphones, tablets or both? What sort of features were most appreciated by the most valuable users in your other app? Who were the users that did not show any improvements in usage after an update? What can you do to turn the least valuable users of your other app into the most valuable for your next one?

Having a successful app is every developer’s dream when they push their app live. However, given current statistics on overall user retention in the app stores, there is a lot of room for improvement. The old saying “to measure is to know” is very applicable in this matter, but it’s only half the work. Turning what you know into actionable information is when the real magic happens. Only then you are on the right track towards systematic improvements to your app and getting that elusive success you are dreaming of.