In 2011, when the world of mobile conferences was full of “Web vs App” debates, WIP started talking about the rising importance of hybrid apps. Back then we highlighted how prevalent hybrid apps had become in various degrees; noting for example that multiple “native” developers were already effectively using hybrid techniques to accelerate their development, especially for the UI layer. As ap art of this rise of the hybrid apps we talked about the importance cross-platform tools had in supporting hybrid development.
In 2012, starting at MWC, the world of mobile has whole-heartedly adopted HTML5 as the new savior. Boot2Gecko, Facebook, Intel and Blackberry were all heavily pushing developers to give HTML5 a go. All these players justify the push for HTML5 as a way to reduce fragmentation and bring more openness to the mobile space. However, despite the various initiatives by the W3C, HTML5 implementation is still heavily fragmented (see below). HTML5 ‘s popularity is growing despite this fragmentation, and one of the main reasons behind this growth is the number of cross-platform development tools based on HTML5 code authoring. As these tools manage to mask HTML5 fragmentation (through runtimes and js libraries), they are the main growth engine of the mobile web today.
As the major trend from last year and one of the key topics of this year, we decided to dedicate this month’s report to cross-platform development tools and hybrid apps. We’ll use extensively as reference and commenting material 2 reports recently published on the subject:
Cross-Platform Application Developers
Before we look at the tools, we’ll look at the developers behind the tools, in order to explore the actual and potential developer population size for different types of tools. None of the reports gives a quantitative analysis of this space; this is mainly due to the methodology. The surveys were sent to communities of developers using the specific tools with the results being harmonized after the fact to give each tool community equal representation. Despite the difficulty in getting this quantitative approach, we believe segmentation and numbers are essential to understanding this space.
Extrapolating from these 2 surveys the Cross-Platform Tool (CPT) developer is most likely to be:
- A designer or computer enthusiast looking for WYSIWYG tools to create a mobile app or a mobile game without the need for a developer;
- A newcomer to development attracted by mobile and the hype around apps, with knowledge of coding gained at university or at high school;
- An experienced web developer who thinks he can deal with the complexities of mobile development and is attracted by the higher average salaries of mobile developers;
- An experienced desktop / console platform developer (such as a game or .NET developer) interested in bringing his skills into a new and interesting field.
Intuitively, the non-developer population dwarfs the developer population (the usual assumption is that 1/100 of people with access to a computer is a developer), which should indicate that the first category (designer & enthusiasts) should form the majority of potential users of CPT tools. Looking at historical evidence though, both Nokia and Google have launched tools for non-developers to produce apps in 2010 with little success so far (neither Ovi App Wizard or Google App Inventor are present in the Vision Mobile report). This could lead us to think that this CPT segment has no potential.
However, companies catering for this category like Mobile Roadie (20M downloads) have proven that this can be a very successful space, with many apps created, substantial revenues for the tool owner and great success for the user (the singer Adele’s app, created with Mobile Roadie, recently reached 1.5 million downloads). For this reason we believe that this field has been overlooked so far and that offerings targeting niches and allowing strong customization of apps can be successful. For this reason we’d expect Mobile Roadie, WordPress Mobility plugins and the GetJar website packager to grow in importance in this field.
Having looked at the non-developer category, let’s look at the various developer categories:
- new starters
- web developers
- .NET and C.
To understand their motivations we’ll start by looking at the drivers behind their tools decisions shown in the following graph:
The number 1 decision criterion is the supported target platforms. As we can see in the graph below, iPhone and Android are the clear leading targets for a majority of developers despite an increasing interest in new platforms like WP7. Today’s CPT minimum viable product is “support for Android and iPhone”. So effectively there is no real differentiator in the B2C space.
For enterprises, this might lead developers to choose CPTs that support WP7 and Blackberry, but this is still a niche choice. While Vision Mobile reports that increasingly developers target multiple platforms (an average of 3.7), this figure includes tablets as a platform, meaning that most developers will really target phone and tablet variants of iOS and Android.
The number 2 criterion is the rather universal “re-using my development skills”. This is where our three categories of developers will be useful. Based on this point, developers will choose the tool that is the nearest to their programming forte. As a consequence we should see adoption of CPTs roughly matching the size of the various developer communities (assuming an equal interest in mobile development, which seems reasonable in 2012).
A realistic estimation of new developers coming in the market would be almost be impossible to get (as many tech graduates end up not taking a software development role). It is possible, though, to evaluate the skills computer science graduates have
The C developers category is traditionally strongly represented by games developers and traditional mobile Java developers. However their number is dwarfed by the approximately 6 million C#/.NET developers around the world. This number explains the huge success of Xamarin, which sits at #2 on the list of CPT developers are planning to use in the future. We expect them to have a strong influence in the future of mobile development in the coming months.
Now that we have looked at the developers, let’s consider the reasons why they are starting their mobile projects. We believe that many developers are exploring the options to build up their skills, and are making use of free tools to do so. The very high rate of abandon with tools like Appcelerator and PhoneGap are typical of this use case (see chart on below).
The other frequent use case is developers being asked by their company to start a new mobile project. While it’s difficult to evaluate the number of developers in this case, the fact that most companies are looking to accelerate their mobile projects this year is the sign of a mature approach to cross-platform mobile development.
This sense of maturity is reinforced by the fact that most developers are looking to realize entire projects through these tools, not just a one-off app or the porting of an app to a new platform as seen in the graph below.
Verticals & enterprise
In this section, we’ll differentiate vertical tools (tools that help companies build B2C apps in a specific vertical market) from enterprise tools (tools that help companies build tools for internal purposes).
Looking at vertical CPTs a few trends emerge:
- Gaming as a profitable app category has attracted an important number of tools solutions. Other app verticals, which are not as mature, will undoubtedly follow over time, as CPT will look at market niches for differentiation.
- One of the drivers behind th
is verticalization of solutions are app development services companies specialized in a vertical. As they look at broadening their market and offering a wider price range, proposing a CPT solution is a natural growth path (most companies in the vertical category have grown this way).
- Not all verticals will need a full range of tools (from native to HTML to designer); we would expect that only HTML5 and designer types of solutions emerge in this vertical space. However we expect a lot of them to remain fairly unknown outside of their niche.
For reference, here’s a non-exhaustive table of vertical apps creation platforms:
Looking at the enterprise market, a surprising figure is quoted in the Appcelerator survey, with 39% of Appcelerator developers planning to put their apps into enterprise appstores. This figure is left to interpretation, as it does not differentiate between an exclusive deployment into an enterprise appstore versus a possibility of a deployment. However, the high number (much higher than the number of companies with an enterprise appstore), indicates the appetite of companies for internal applications. The fact that Xamarin’s MonoTouch, is used on 41% of projects to port existing apps (most likely .NET desktop apps) to mobile versus an average of 19% for this use case on other tools, could be indicative of the mindset in IT department.
The CPT enterprise field is still in its infancy, with many players looking to bundle distribution mechanisms in addition to app creation tools. We are not convinced that this is a winning approach as teams in charge of development and teams in charge of operations are usually separate. We therefore expect a lot of fluctuation in this space in the coming months.
Hype in mobile Cross-Platform Tools?
The most striking characteristic of this space is the sheer number of companies fighting for developer attention. Vision Mobile’s report lists more than 100 companies in this field (and many are missing, especially in vertical sectors). VCs have been spraying money at CPT companies, with over $200M in financing so far. This CPT vendor fragmentation is on its own a huge issue for developers who are questioning the sustainability of some of these tools vendors, and thus the future of their code investment (this is especially true for runtimes with a very specific set of APIs).
The tools business has traditionally been scorned by VCs. Tools companies are seen as too much of a hidden service business, where the only people using the “tool” are the employees of the company. A few companies in the report fall in this camp, such as Marmalade or Enough Software. Tools companies have also been seen as hardly profitable. Developers hesitate to pay for tools, because large platform vendors give away tools to attract developers to their platforms, tools buying is characterized by a complex decision making process and open source tools erode differentiation. Furthermore, the barrier to exit is fairly high as most tools companies can offer development services to their customers and sustain themselves this way for while.
Finding a potential buyer for a CPT is another issue. Xamarin and their Mono-based offering best exemplify this. Mono is a runtime that allows developers to create applications for Unix (originally) and now, thanks to Xamarin, for iOS and Android using .NET. and C#. This proposal is extremely attractive to .NET developers, one of the largest developers population in the world. A company looking to build a developer ecosystem could thus buy Xamarin and instantly gain a huge developer and application base. The problem is that Microsoft would not let it happen without charging a fee as they own the .NET framework, making Microsoft the only target buyer. But does Microsoft really want to let developers target other platforms other than its own? The answer for now is no. As a consequence, Xamarin’s exit strategy is pretty doubtful.
So what has changed in the minds of VCs? Why so much investment in the CPT business? We believe that most VCs hope to benefit from the platform war. Christopher Kassulke, CEO of Handy Games (one of the only companies making money from Android games), is quoted saying “Fragmentation is now a 4D matrix”. Meaning by this that a so-called platform is not only made of the software platform but also of the payment/distribution, advertising and social platforms. These CPT companies are thus the ideal play for a payment, advertising or social platform looking to eliminate other players’ advantages in the field of software platforms. Even though we believe that similar issues to the one Xamarin faces would get in the way.
On the positive side, the ideal target for these tools should be large enterprise services businesses. IBM and SAP have already been on the purchase trail, but there might be a few more opportunities.
The question of cloud API integration is high on the agenda of developer and developer programs. Developers would like ways to discover, use, find information about and test these APIs easily within the IDE, especially as more and more services are moving to the cloud. Developer programs are looking to increase the visibility and the ease of use of their offerings. CPTs certainly look like the natural integration point. As shown in the diagram below there is actual demand for such an integration. This graph can be obviously be flawed (it’s unlikely that a cross-platform developer will develop middleware). However the need for stronger integration is supported by the observation of developers using cloud APIs.
There are 2 reasons why a CPT user would like to access a cloud API: if the API only exists in the cloud (such as the Facebook API) or if the CPT does not offer an equivalent to a native API (for example, Appcelerator does not offer a native notification API on Android).
Starting with the second type, according to the Vision Mobile survey CPT developers want access to the following native APIs in order of priority:
- device filesystem and notification system (>50%)
- GPS (47%)
- background running, and multi-touch screen input (40%)
- and rounding out the top 10: native media playback/recording, SMS/MMS send/ receive, accelerometer access, address book or call log access and the ability to invoke another app. This would highlight notification, location, SMS/MMS, and call logging as cloud alternatives to native APIs.
In the graph below, Appcelerator does not differentiate between the 2 use cases when they list the cloud APIs developers are planning to use. It is interesting to see that the same priority is given to location and notification, highlighting their high potential among CPT users.
This survey also highlights the lack of understanding of the use of cloud APIs (in this case, social graph in particular). This is something we believe many cloud APIs suffer from.
In the enterprise, targeting multiple platforms is a good idea from a development cost and speed perspective. But are development costs and speed of development the main factors blocking a successful mobile project?
The answers will probably differ between a B2C and and enterprise project. So let’s look at them separately.
From a B2C perspective, most developers still prefer the appstore distribution route to the web distribution route. For these reasons tools that package an app into a appstore distributable file are the most popular. There are tools to support with the “posting” of the app into different stores, which as we studied before can be a bit of a pain. But then comes the real issue of “marketing” the app. For developers with no time to market the app or no marketing budget the results are likely to be poor whether the app is available across platforms or not. For those with big budgets there shouldn’t be a problem in marketing the app -- as a matter of fact it is likely that the development cost of the app is going to be pretty minimal compared to the overall cost of the campaign and therefore, the impact of CPT pretty minimal too. Those in trouble are the ones in the middle trying to answer to the dilemma of whether to bank the entire marketing budget on one platform (typically iPhone) or spread it across platforms.
The typical answer today is “go big” on iPhone and try to hit one of the top 10 spots in the charts. There are companies specialized in this field who can help with this, for a $10,000-100,000 budget depending on the country. Once success has been reached on one platform the others will come. But to minimize risks, most companies would actually go native to avoid any surprise and maximize their chances of getting to this coveted top spot. So why would they need a CPT approach?
Things are changing, though, with some VC-backed companies building services taking a slightly longer term approach to the problem and knowing that these one-time hits will not build a great and passionate user base.
The other commercial reality developers have to face is the speed of innovation, i.e. how can one outpace the average development speed in the market? The corollary question being, how can I create something as quickly as possible that no one will be able to replicate easily or in a reasonable time? The traditional answer to this question is to build an application in native and to include some “special sauce” brought in by an expert in the platform. When we have been reporting about demo days, the number of apps that were uni-platform were a demonstration of the popularity of this approach. CPTs however level out the possible technical differentiation between developers (with the exception of some hybrid tools). This could be a barrier to adoption among technologists and among VCs who require a minimum of IP within a company.
New challenges for CPT
CPTs have always existed because of fragmentation, and historically most CPTs tried to solve Java fragmentation. What fragmentation do they face today?
At first sight, the world is simplifying. At an OS level things are becoming simpler by the day with an overwhelming majority of OSes based on Linux. At a runtime level, things are simplifying too: Dalvik is increasingly becoming a runtime rather than a part of Android, Webkit is the de facto web standard, and all Webkit competitors are keen to be more HTML5 standard compliant than Webkit itself.
What this means that the world is becoming more like the Java space everyday, with so-called standards available across device manufacturers. But the same “implementation fragmentation” issues that plagued Java are bound to re-appear. In this situation tried and tested methods like “device databases” describing the capabilities of different devices are bound to re-appear as well.
For Developer Programs
With the number of CPT vendors constantly growing, developer programs without a tool offering should look at the numerous partnership opportunities in this field. Of particular interest are the component stores offered by some of the CPT vendors (such as Marmalade or Appcelerator) where developer programs can feature their APIs within ready-made components. For operators, fostering vertical CPT relationships can be another way to leverage existing vertical presence. Of particular interest is the rise of .NET developers, which is creating an opportunity as talented developers enter the mobile space.
With the number of tools in the market, differentiation and niches seem to be the only way to progress. Apart from vendors with a very limited, high-paying customer base, we would not recommend to go for a software lifecycle management solution. Instead we would encourage vendors to look at individual tool offerings in unaddressed niches, especially tools for non- developers. As fragmentation in the Android space is remains a persistent problem, fragmentation database solution providers are acutely needed.