Month: September 2014

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

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.