Cross-Platform Tool Trends – Freemium & Flexible

CPT trends

Creating versions of an app for multiple platforms (at least iOS & Android) is an increasingly common requirement. Building and maintaining native code for every platform supported is both difficult and expensive. Cross-Platform Tools (CPTs) offer a solution to this problem by enabling sharing of code across platforms and in many cases a single code base can target multiple platforms. With such significant cost savings available, why don’t all developers use CPTs?

Learning curves & licensing

Unfortunately the platform spanning magic provided by CPTs doesn’t come without any costs. Most CPT vendors depend on licensing revenue – developers have to pay to use the tools. Of course the cost of licensing most of these tools is far less than the cost of a full native port of an app to one additional platform. However, there are more costs associated with adopting a tool than the license fee; learning to use a CPT and building confidence in it’s suitability for future projects requires a significant time investment. The potential future cost of switching away from a tool that isn’t working out as hoped is also something that developers must consider.

The spread of Freemium models

In order to build sufficient confidence in a CPT to build their businesses around it, some developers need lots of time for evaluation, perhaps building a side project before risking major apps or customer projects. For many the 30 day trials that were typical in the sector just weren’t sufficient. One of the first mobile CPTs, MoSync, was very early to recognise this and had generous free options early on, they even went open source with a dual licensing model back in 2009 around the time many of their competitors were just launching. This year has seen a tipping point, possibly partly due to increased competition in the sector but also to capture a larger share of the ever growing demand for mobile development – Appcelerator, Corona, RunRev, Unity and Xamarin have all either switched to freemium models or expanded their free offering for mobile. RunRev has also joined MoSync in releasing their code under an open source license, Appcelerator have open sourced more of their code and Xamarin have just open sourced some of their cross-platform API wrappers. Having access to the code for the cross-platform layer can help remove developer fears of getting blocked by a bug in their chosen tool and being entirely dependent on the vendor for a rapid fix.

Technical tradeoffs

In many areas platforms are sufficiently different that it’s not possible to unify them under a single API. CPTs get around this in a number of different ways:

1) Not providing access to the problematic functionality – this restricts what developers can create.
2) Providing a lowest common denominator API – this prevents developers from using the full power of the native platforms.
3) Providing their own implementation of the functionality – this can bloat apps and often prevents them from having a fully native experience.
4) Providing thin wrappers or separate extensions for each platform – this gives maximum control but adds complexity to the code, reducing the benefits of a cross-platform approach.

Different apps, or even parts of apps, will have different priorities that determine which of the above approaches are acceptable. For example, a mass market consumer utility app is likely to require a completely native look and feel for the UI, while an internal app for a large enterprise may want to look and feel exactly the same on all platforms to minimise both development and staff training costs. The same tradeoffs won’t always apply to every part of an app either; most games have a completely custom UI and don’t require access to the native platform UI components at all, however, they may well want access to the new Google Play game services, or the iOS 7 Game Controller APIs as soon as they are available.

A flexible future

Faced with a still growing list of platforms to support and wide array of new features in each new platform version, CPT vendors now have to specialise for a sufficiently profitable subset of the market that has fairly narrow requirements or become increasingly flexible. Most vendors currently provide flexibility through a native interface that enables the creation of third party extensions or plugins. Xamarin’s approach to flexibility enables developers to (semi-)automatically generate wrappers for any native API or library, which is ideal for developers who want to stick with C# for all of their own code yet build on the work of native developers for each platform.

Even greater flexibility is possible though. What if you could just build the parts of an application that made sense to be cross-platform with a CPT? RunRev has a beta for an embeddable library version of their engine to enable this, although currently only for iOS. They are also re-architecting their engine to put 3rd party extensions on an equal footing with the core functionality – even allowing them to extend the language where necessary. Another interesting option going forward here is Digia’s Qt, the open source cross-platform framework that was acquired and re-purposed for mobile by Nokia before they dropped it in favour of Windows Phone. Qt is now the native framework on BlackBerry 10, Ubuntu Mobile and Sailfish OS and is close to production readiness for iOS and Android; it also has a Tizen port ahead of the release of that platform. The core of Qt being C++, it can easily interface with native code on most platforms and has always been delivered as a library, so it’s also embeddable within native apps.

Flexibility enables greater agility

This library format means that developers can start cross-platform and add or optimise parts of their app with native code later. It’s possible to just add a full native experience for the platforms that get the most traction. Alternatively, starting on a single platform and then adding new functionality that works across all platforms after achieving some success and starting to port to other platforms is also an option. Last but not least, the library format also removes any concerns about lock-in. If a developer decides to migrate away from a CPT, they can do so gradually, without having to port/re-write everything in one go. It’ll be interesting to see how many vendors can push flexibility this far and how many developers take advantage of it.


Backend-as-a-Service Shootout (the best alternatives to Parse?)

Using a Backend-as-a-Service (BaaS) can reduce development cost and time-to-market. It’s a simple way of getting a highly scalable backend solution without significant upfront investment. This avoids the technical risks of having to scale your own service to meet demand as your user base grows; in a world where an app that hits the store top charts might gain more than a million new users before you complete your next iteration of development this is worthy of serious consideration. In most cases the tradeoff is giving up control of your backend. This tradeoff was brought into the spotlight recently when the most popular BaaS, Parse, was acquired by Facebook. This created a predominantly negative reaction from developers who went from buying a service from a neutral party to hosting their backend with someone many already distrust that has an interest in mining their app data. So, if you’re looking for a BaaS for new project but don’t want to share your data with Facebook, or want to migrate away from Parse, where do you go? Our last survey asked developers using BaaS offerings to rate their primary tool against a range of criteria – the results could highlight some attractive alternatives.

Splitting out the 8 tools which had more than 10 ratings each, the “other” category is still almost 25% of responses and includes a further 11 tools that developers had selected as their primary BaaS. Our own sector page lists 43 vendors at the time of writing, suggesting that the sector is still very fragmented and likely to see consolidation in future.

BaaS Shootout

Some popular BaaS options tied to other tools

Parse was by far the most popular with almost 2.5 times as many responses as Appcelerator’s Cloud Service as the next most popular. Appcelerator’s service is fairly heavily tied to their popular Cross-platform tool (CPT) much like the Sencha offering, which had a very similar number of responses. However, while Sencha’s BaaS had the highest developer satisfaction in our survey, Appcelerator’s was the lowest of the top eight. This situation is the same as the satisfaction levels for the corresponding CPTs. While may look attractive on developer ratings, adopting it implies using (at least some of) the Sencha libraries for cross-platform web development too – although this tool scored highly on cross-platform availability (the web works everywhere) there are no native SDKs.

Applicasa switched focus

Just behind for developer satisfaction was Applicasa. However, while our survey was running Applicasa were in the middle of a mini-pivot from a generic BaaS to a “Mobile Game Management Platform”, having recognised that the generic BaaS sector was exceptionally crowded. They haven’t yet come out of beta or announced pricing, although this is likely to reflect their value-adding services for game developers. If you’re looking for a BaaS offering with extra functionality for mobile games then Applicasa may be worth a look.

Open source or specialised

Behind Applicasa comes Parse, closely followed by Deployd and CloudMine. Deployd does not yet have a production hosting solution, so it’s currently just an open source project that you host your own instance of on Heroku or Amazon. That’s also an advantage in that you can modify the code and you’ll always control your own data. Another open source BaaS option like this, Helios, was recently launched by Heroku themselves. If you can take on responsibility for some of the maintenance of the backend in order to maintain control of your backend code and data then this kind of open source option is very attractive. CloudMine on the other hand is focussing on larger corporate clients – they’re targeting enterprises and agencies producing lots of apps. Like Applicasa, they’re specialising to target what they see as a more profitable niche and trying to avoid mass market generic BaaS competition.

Further acquisitions likely – select with care

The remaining popular BaaS options in our survey scored below the average for “others” on developer satisfaction. However, just by looking at the top handful we can see some trends for the still immature sector emerging. The generic BaaS space is all about scale. The remaining vendors fighting for this market are likely to get acquired by a larger company, or run out of cash trying to compete. It was implied that there were multiple parties interested in acquiring Parse who are presumably still in the market for a similar solution. If the acquiror of your chosen BaaS is a PaaS vendor then the service should continue to evolve and developers’ data remain private. The large PaaS vendors are likely to build or buy a more complete BaaS solution – we already see this with Helios and Windows Azure Mobile Services. Other companies interested in buying a BaaS vendor might want to integrate with their own analytics (as with Flurry buying Trestle) or other developer services, secure a key supplier or just get a closer relationship with mobile developers. There may also be large enterprises that snap up a small BaaS vendor for their own internal use. Other BaaS vendors will specialise towards specific developer segments.

If, like most developers, you’re still experimenting in the market and not yet building your own services with a long term view then a BaaS that’s specialised to your app category might be a great option. For those looking to select a common backend architecture that they’ll re-use across multiple products, or platform to build on top of for the longer term, the open source frameworks look like the safest option in the current market.


PhoneGap and Appcelerator lead developer mindshare across tens of CPTs

Cross-platform tools (CPTs) address real challenges for developers. Cross-platform tools allow developers to create applications for multiple platforms – usually mobile, but increasingly tablets or TV screens – from almost the same codebase or from within the same design tool. CPTs reduce the cost of platform fragmentation and allow developers to target new platforms at a small incremental cost. More importantly, cross-platform tools allow software companies targeting multiple platforms to reuse developer skills, share codebases, synchronise releases and reduce support costs.

CPTs can be used to develop native, hybrid and web apps and come in several technology flavours: JavaScript frameworks, App factories, Web-to-native wrappers, Runtimes and Source code translators. There are over 100 CPTs that we identified in our Cross Platform Tools 2012 report.

Developers most often use several CPTs; on average CPT users will use 1.91 CPTs, confirming the lack of maturity and niche nature of cross platform tools much like we observed in our CPT survey a year ago. Moreover, we found that one in four developers will use more than three cross platform tools. The lack of a one-size-fits-all and immaturity in the CPT landscape is what is stalling cross platform tools from shifting the balance of power in the iOS / Android duopoly towards alternative platforms.

Cross platform tools are most popular for developers focusing on HTML development, with 38% of of them using CPTs for development. CPTs and particularly JavaScript frameworks and Web-to-native wrappers, provide a relatively smooth transition to mobile apps for web developers: in our Cross-Platform Developer Tools 2012 report we found that 60% of developers using CPTs have over 5 years experience in web development. Usage of CPTs is popular among iOS developers, while usage among Windows Phone developers is much lower, presumably due to historical lack of support for the iOS platform from CPT vendors and Microsoft’s financial incentives for the creation of native apps.


PhoneGap tops CPT rankings, used by 34% of developers, followed by Appcelerator and AdobeAir with 21% and 19% developer mindshare respectively. With over 100+ cross platform tools available, the choice for developers can be a challenge. Choosing between CPT technologies is not always straightforward (i.e. whether to go for a web-to-native wrapper or a JavaScript framework). Moreover, developers need to try out a cross-platform tool to see if it aligns with their needs in terms of performance, learning curve, access to native APIs or look & feel. It’s never a black or white decision.

The most important selection criterion for CPTs is their availability across platforms. Due to their deep platform integration, CPT tools support iOS/Android platforms first, and others secondly. Beyond cross-platform availability, 38% of developers using CPTs select their tools based on development speed and 33% based on the learning curve. Since CPTs aim to expedite and facilitate development across platforms, they should provide a clear advantage over native platforms when it comes to speed and ease of development to justify their use. Amidst differentiating features for CPTs are access to native APIs, performance optimisation and the ability to reproduce native UI elements on each platform.

[doritos_report location=’DE13 Article – CPT’]

Which CPTs are other developers using?

[toggle title=”Important things to know about this interactive graph”]

  • All the filters in the graph refer to survey questions in which respondents could select multiple answers. This means that there is no direct link between the filter and the use of the tool. For example, filtering on “Android” means that the respondents develop Android apps. It doesn’t imply that they use the tools for their Android apps specifically, or even that the tool supports the Android platform. Use filters as a guideline only.
  • Keep an eye on the sample size. If the sample size is low, the graph doesn’t offer strong conclusions about the popularity of different tools. Use your good judgment when making decisions.[/toggle]

Find the best CPT for you!

[sectors slugs=’cross-platform-tools,app-factories,hybrid’]


How Much Time Could You Save With Backend-as-a-Service?

Backend-as-a-Service (Baas) provider Kinvey published an interesting infographic on the average time taken to build an iOS or Android app (with a backend service) this week. The data comes from a survey of 100 developers with their estimates averaged. Before interpreting the data, it’s worth bearing in mind the following:

  • This is only to build a Minimum Viable Product (MVP) – it’s nowhere near the total that would be spent on a successful app.
  • The features included create an app with a relatively rich backend service and a fairly basic client.
  • This is only building a client app for one platform rather than several.
  • Building a robust API versioning system would not normally be part of an MVP.
  • This survey has been created specifically to promote the benefits of BaaS.

Even so, the the items included in the infographic would be common to a wide range of applications.

Platforms Tools

Cross-Platform Tools – Functionality and Trade-offs

Cross-platform tools (CPTs) are a class of developer tool that aim to enable a single implementation of application functionality to run across multiple platforms. If that definition seems very broad it’s because the category covers a wide range of use cases, technology approaches and forms of app deployment. In our analysis of this sector from February 2012 we identified over 100 tools across three forms of app deployment (native vs. web vs. hybrid) and five different technology approaches.

Fundamentally the various platforms are not compatible and the use of a third party tool to solve this issue comes at a cost. The effort saved through a CPT often has a financial cost but more often the largest trade-off is against a loss of flexibility, control or performance. Different tools produce different compromises. In many cases what is lost is not required to deliver the desired experience, so it’s worth understanding the different approaches and choosing the right tool for each project.

Business Platforms

How to select a cross platform development tool

With the wide selection of cross-platform development tool (CPTs) available in the market, how should a developer select a development tool? The exact selection criteria will vary depending on the project and the individual developers involved. However, it’s valuable to look at the criteria other developers have used to select development tool and, even more importantly, the reasons they’ve stopped using them. Fortunately, we have this data from our cross-platform tools survey earlier in the year.

Business Tips

Crowdfunding: Leanest Way to Launch?

One question that divides opinion among developers is when to start marketing your app. Some say if you start marketing too soon, the early interest you create will dissipate before you actually have something to sell. Others argue that you can’t start talking about your app soon enough, build a following of early adopters and you have great word of mouth marketing and an initial sales boost to climb the store charts. What if you can have the benefits without any of the downside? It might just be possible with crowdfunding.

Business Tips

The App Localization Opportunity

As we showed in our Developer Economics 2012 survey, there is a massive gap between the number of developers creating applications for local languages (other than English) and the demand for local language content. For many app types, app localization is only a relatively small incremental investment on top of the original app build costs and yet has the potential to generate significant new downloads and revenue. How should developers decide if it’s going to be worthwhile?

Business Platforms Tips

Backend-as-a-Service – Should You Use One?

Many of the most engaging and popular apps connect to cloud services which either regularly deliver new content, enable users to interact with one another or both. Unlike a standalone application, such apps can incur ongoing hosting costs throughout their active usage life. Ideally your revenue model should mirror the cost structure. Using a Backend-as-a-Service (BaaS) reduces execution risk and time to market as well as removing server maintenance and scaling headaches, however, it typically increases the ongoing service costs making the revenue model fit even more important.  Obviously the technical requirements of the app constrain the selection of service and for basic backend features Cloudspring has a good overview article. The variation in pricing of backend services is even greater than the diversity of their technical capabilities but this post will provide some generally applicable advice.

Business Platforms Tips

The Developer Platform “Lean Factor” and Why It Matters

There’s a lot of buzz about Lean Startups in the software community in general and amongst mobile developers in particular. How lean a startup can be is strongly influenced by the tools and processes available on their chosen platform. Which platforms enable the leanest product development processes? How and why does lean framework matter?