Tag: Cross-platform Tools

Categories
Platforms

Benefits and Challenges of HTML5 App and Game Cross-Platform Development

HTML5 web app development had its ups and downs but it is undeniably one of the most promising technologies for the upcoming years. The best example can be found on desktop systems, where users are spending more time inside a browser than ever before.

HTML5

Hundreds of traditionally native apps are turning into web apps as they provide advantages like interoperability, ubiquity and cross-platform. The features added in the new HTML5 standard allow a much more dynamic web content and the development of applications never before imaginable on the web, such as videogames, one of the most performance and resource demanding type of app. But this cross-platform promise is still in the making and it is key for developers to understand the benefits and challenges before committing to a fully web based approach. In this web Vs native controversy it is important to remember that [tweetable]the adoption of a technology should always be driven by the needs of the project to be developed[/tweetable].

Benefits

In order to provide the most accurate view of the status of web based project development and make the right decision, let’ summarize the benefits of the web first to identify the opportunities it offers.

Cross-platform

This is the main feature why developers have originally turned into web technologies looking to fulfil the promise of coding once and deploy everywhere. As some of the other advantages of the web, cross-platform is in its nature, as it is meant to run on any device (hardware) and operating system (software). The web can be accessed from a PC, Mac, laptop, desktop, mobile device, smart watch, car and even home appliance. We know one thing for sure about any futuristic new device: it will be able to access the web.

Content on demand

Many developers do not identify this feature as a benefit because they take it for granted as, once again, is in the nature of the web. But [tweetable]being able to provide content on user demand is one of the biggest benefits the web puts on the table[/tweetable]. Applications can easily vary and adapt with none or little effort from the developer perspective and new paradigms and user cases can be easily accomplished, like promoting the use of an app or a new feature while communicating with others. The messaging app Kik is a great example of an application that is showing the benefits of on demand web applications as provides its users with the option to run apps and games without having to leave the messaging environment.

Full technology stack

This is a feature that goes hand in hand with cross-platform as its goal is to ease the process of building a product for developers. Web technologies can be used full stack, from client to server, thanks to platforms like Node.js. Many products need a desktop based UI/UX and their mobile versions could be developed using the same technologies and reusing plenty of the same code. Same thing happens in the server side as many data structures and even algorithms can be reused speeding up development cycles, lowering possible mistakes and bugs and increasing maintainability in the long run.

Based on open standards

This is more important than meets the eye. There have been various technologies in the past that made the cross-platform promise but did not completely deliver. Amongst other reasons, they failed because of being closed and tied to a specific company. Open standards allow both vendors and developers to contribute and improve the final product. This is one of the key success factors of the web. There is no head controlling it so it can evolve according to the needs and interests of many.

Supported by big companies

The web is supported by the biggest technology companies in the world like Google, Amazon, Microsoft, Facebook, Samsung or Apple. Most well known and used browsers are developed by some of these companies that also are part of the standardization committee. This support is a good example of why the web is here to stay and why it will continue gaining momentum as a development platform.

Big developer community

The web is also driven by its developer community, one of the biggest as it involves front-end and back-end developers that are always providing new tools and support. Mobile is the frontier to conquer but there is no doubt the web has won on desktop environments. There is no company, product or service that doesn’t have presence on the web both directly or indirectly. This whole ecosystem of applications is developed by a thriving community of developers that not only need to understand the backend side of the equation but also how browsers and client side technologies work.

WebGL

This feature might change the perception of the web for both apps and games. It provides access to high end graphics and to a more interactive web crossing the boundaries of 2D to enter the third dimension (and even improving the 2D experience with hardware accelerated graphics). All the big browsers support it out of the box now as the last two players, Internet Explorer and Safari, have finally committed themselves to promote it too.

The list of the benefits of the web could even be longer. After reading this set of features, the web could be the first (and maybe the only!) option when it comes to implement a project: be everywhere, anytime and with the the option of using the same technology full stack. But the truth is that web technologies are not widely used in many scenarios (specially when it comes to mobile).

Challenges

Let’s review the main challenges that developers need to overcome and some tips on how to do it.

Cross-platform is more than devices and operating systems

It also involves markets, stores, destination sites, … deployment targets in the end.[tweetable] The holy grail of code once and deploy everywhere comes at a price: handling the particularities of each deployment scenario[/tweetable] can be tricky. Developers need to create accounts, understand the packaging details on each platform, install and learn how to use the tools provided, etc. There are some solutions in the market based on cloud services to be able to configure and deploy a product to different targets with simple to use interfaces taking all these burdens out of developers shoulders. Some examples of this kind of services are Intel’s XDK, Adobe’s PhoneGap Build and Ludei’s CocoonJS.

Cross-platform does not really mean same code or user interface/user experience

It is important that developers understand that cross-platform does not mean the same exact app will mandatorily be the one that will end up going to the different markets. Mobile devices have some inherent particularities like the different input method (touch screens) and limited screen resolutions that must be taken into account. Also, users on mobile are used to different set of interaction paradigms especially when it comes to social media integration or access to native features. [tweetable]A good advice is to think on mobile first if mobile is key for the product[/tweetable]. Mobile device memory, performance and feature limitations should also be taken into account. Having good tools for rapid prototyping, testing and debugging is also key. Many HTML5 app development frameworks provide tools for what is called responsive design. However, this challenge is still less of a problem compared to developing an app in different technologies (web for the desktop, Objective-C for iOS, Java for Android, C# for Windows Phone, …).

Browser feature fragmentation

Yes, the web is an open standard and that is a benefit, but the adoption of these standards rely on browser vendors that have their own agendas, as they are private companies in the end. Standardization takes time too and it is important to take that into account if a feature is a must inside a project. This situation leads to an API and feature fragmentation that has hurt the web application development from the origin of the internet (remember Internet Explorer Vs Netscape “browser wars”). Use of prefixes, incomplete or different implementation of some of the APIs, promotion of non standard ways of handling certain situations are just some of the examples of this challenge developers have to face. Vendors are improving their old day practices and the auto update of the browsers has helped a lot in order to allow users to benefit from the latest additions in a daily manner. There are also initiatives to mitigate the negative side-effects of these practices like some open source libraries to ease the handling of supposedly standard features, e.g. Modernizr. Still, this might be a challenge for some developers. On mobile, this problem is magnified as mobile operating systems (specially Android) and browsing technologies are still in their infancy. Technologies like Ludei’s WebView+ or Intel’s Crosswalk help overcoming this problems as they offer a unified execution environment regardless the Android operating system version. One less headache for developers.

Low performance, especially on mobile

Execution speed has been one of the main problems holding HTML5 back as a widely used cross-platform app and game development technology. Mobile has been the platform where this problem has been more notorious as mobile devices have more limited processing power. As hardware has evolved, the performance gap between mobile devices and desktop computers is shrinking. Improvements on browsing technologies has also helped on solving this issue. Still, the biggest problem related to performance is, once again, due to fragmentation. To be able to develop a native web application, the system webview element is used. The issue with the webview is that it’s tied to the OS version, so that the user needs to update the OS for the webview to get new features and updates. Android fragmentation makes the webview a poor choice when it comes to deploying HTML5-native hybrid apps. But there are solutions to this problem. Once again, projects like Crosswalk and Ludei provide a huge improvement in order to solve the performance issue. Actually, Ludei provides multiple options (WebView+ and Canvas+) to help on this matter depending on the type of project (a general purpose app or a canvas based game). The bottom line is that there are solutions for the performance problem that prove that HTML5 can be a good execution environment for cross-platform apps and games.

Access to the native features on each platform

The web, as many other technologies before it, because of its cross-platform nature could be limited in its access to platform-specific features. This is a fact and in many cases, a limitation. Either way, the huge support that the web has over the whole technology community makes it a primary target for the adoption of new products and technologies. Good examples of this are devices like the Leap Motion controller or the Oculus Rift VR Head Mounted Display. Thanks to new APIs like websockets, these completely over the edge technologies are present from day one on the web. A similar situation arise on mobile with an increasing need to access hardware features and many of the interesting APIs only available in the OS/native level. The good news are that browsing technologies are rapidly adopting these important features. Moreover, thanks to hybrid approaches, there are JS to native bindings that allow accessing any native feature from a web app. Cordova is the de facto standard for building these bindings called plugins. Literally, there is no limit on what can be accessed: In-App Payment APIs, Push Notifications, Advertisement SDKs, Social Network SDKs, and a long etcetera.

[tweetable]The benefits of HTML5 and the web are undeniable; the web is here to stay[/tweetable]. The devices of the future might support software languages like C, Java, Swift or a new language we’ve yet to see – but the common denominator will always be the web, a technology that has brought us together and has enabled a much richer communication and access to information. The true strength of the web and HTML5, its most recent standard, lies in its ubiquitousness and its flexibility. HTML5 has advantages and limitations, and knowing how to leverage the former and overcome the latter is what sets apart good from bad engineering teams. It’s just a matter of choosing the right tool for the right job.

Categories
Tools

Pros and Cons of the Top 5 Cross-Platform Tools

As the market temperature for cross-platform tools (CPTs) continues its steep climb into hotter territory, it’s understandable why many feel we are witnessing a mobile fragmentation that is perhaps much larger and more significant than the recent wars waged over the desktop. If this fragmentation tells us anything, it’s that [tweetable]cross-platform tools for mobile development are often not a “one-size-fits-all” solution[/tweetable] – and that there are numerous veteran users of these tools that do not believe the problem has been solved as well as it could be….yet. In our Developer Economics Q1 2013 report, the breakdown of the top CPTs looks like this:

18-01

How many of these tools do you know? Test your skills in the new Developer Economics Survey and win awesome prizes.

As you’d expect, each approach comes with trade-offs. Let’s examine the top five cross-platform tools (PhoneGap, Appcelerator, Adobe AIR, Sencha, Qt), as identified in our research, and list out the more salient pros and cons of each. This is not an exhaustive list, of course, as each platform can’t be explored in depth in one post alone. Want toexplore more cross-platform tools we’ve identified? Check out the CPT section on our ToolFinder tool atlas

Apache Cordova/PhoneGap

Apache Cordova (known by many as “PhoneGap“) holds the top slot in developer mindshare. Cordova/PhoneGap developers write their mobile applications using HTML, JavaScript and CSS. These assets run in a “WebView” inside a native application container on the target platform. It is, conceptually, a web application packaged within a native application container where your JavaScript has access to device-level APIs that normal web applications would not (more on that below).

The name “PhoneGap” is quite possibly one of the more recognizable names in this space. Originally created by Nitobi, the name was changed to “Apache Cordova” when it was donated to the Apache Software Foundation. Adobe purchased Nitobi – including rights to the PhoneGap name – and now distributes Cordova under that name.

Pros

  • Regardless of server side platform & language experience, a significant number of developers have experience with HTML, JavaScript and CSS. Apache Cordova allows developers to immediately leverage these existing skills. The value of this can’t be overstated – as it reduces training and can enable a quick-to-market stance in companies ready to adopt it.
  • Cordova apps install just like a native application, and are able to leverage app store discoverability.
  • Cordova follows a plugin architecture, which means that access to native device APIs can be extended in a modular way. There are a lot Cordova/PhoneGap plugins to choose from – enabling developers to focus on the web-based skills they already have. (This is a weakness as well, as we’ll see in a moment.)
  • Cordova is open source and free, so there are no licensing costs (also a potential weakness, mentioned below).
  • Cordova/PhoneGap solutions existed in this space early on, and have matured to the point where value-add offerings on top of the basic CPT are the norm. For example, both Adobe’s PhoneGap Build and Telerik’s Icenium enable developers to build for supported target platforms in the cloud, without local SDKs (meaning non-Mac users can build iOS applications). In addition to Icenium’s cloud build services, Telerik also provides Kendo UI Mobile (an MVVM framework targeted for performance on mobile), app analytics via EQATEC and a Backend-as-a-Service (BaaS) offering named Everlive. Adobe has integrated PhoneGap Build capabilities into Brackets (a web based IDE) and Dreamweaver.

Cons

  • Of course, being free is no guarantee of success. In fact, the emergence of PhoneGap Build and Icenium are clear demonstrations that a “bare bones” Apache Cordova is woefully incomplete. The strength of being open source – and leveraging the talents of a wide array of contributors – is both a blessing and curse. If you need to extend your app with a custom Cordova/PhoneGap plugin, odds are you will find one. Yet it may be out of date and not support the target platforms you need.
  • The plugin architecture works well if you can find the plugins you need or if your web developers are capable of changing gears to write their own custom plugin(s) as needed. However, odds are that you chose Cordova, in part, to avoid the need for specialized native platform skills.
  • The performance of Cordova/PhoneGap apps has often been criticized. Native UI will always outperform a hybrid solution, but improvements in device hardware and WebView implementations have narrowed the gap. Your web developers will need to pay close attention to performance, which means their knowledge of profiling tools as well as which web UI frameworks are mobile-friendly is essential.

Appcelerator

Appcelerator’s Titanium provides a unified (across devices) JavaScript API, coupled with native-platform-specific features. Developers write JavaScript and utilize a UI abstraction (the Alloy MVC framework) that results in the use of native UI components, greatly aiding UI performance compared to other hybrid options.

Pros

  • The use of native UI components is a performance win, and the Alloy framework attempts to normalize UI across platforms.
  • The use of JavaScript to normalize code across platforms enables you to leverage existing skills on multiple target platforms.
  • Appcelerator provides value-adds such as a Backend-as-a-Service (BaaS), app analytics and a marketplace for 3rd party components.

Cons

  • Developers are required to manage target platform SDKs locally. It’s highly recommended for your team to establish a controlled build environment/CI process if you choose to manage SDKs locally, especially if you target multiple platforms. SDK version & build-related issues can be a horrific time sink, when you really need your team delivering features.
  • Normalizing the UI across platforms, while arguably a “pro”, is also a “con” in that your team will need to train on a proprietary technology to gain skills that are not directly transferrable outside Titanium.

Adobe AIR

Adobe AIR is “a cross-operating-system runtime that lets developers combine HTML, JavaScript, Adobe Flash® and Flex technologies, and ActionScript® to deploy rich Internet applications (RIAs) on a broad range of devices including desktop computers, netbooks, tablets, smartphones, and TVs.” The problem with that description is that you cannot use HTML & JavaScript to write Adobe AIR applications for mobile applications (Flash/ActionScript skills need only apply).

Pros

  • Adobe AIR has impressive reach – running on a wide array of desktop and mobile devices. In addition, if you plan to have a more involved/animated UI (and don’t plan to use a native approach), using AIR over a HTML/JavaScript/CSS approach may help.
  • Most Flash/ActionScript developers consider the IDE tooling for these technologies as mature.

Cons

  • The “elephant in the room” for many mobile developers is the fact that Adobe purchased Nitobi (and the rights to the PhoneGap name), clearly signaling to many that AIR may not be a long term strategy for mobile development. This combined with the rapid decline of Flash erodes the confidence many developers might otherwise have in choosing AIR.

Sencha

Sencha Touch is an HTML5 mobile application framework for building web applications that look and feel like native applications. Apps built with Sencha Touch can be used with Apache Cordova/PhoneGap or Sencha’s native packager – either which will package the application in a native container and enable access to select device-level APIs unavailable to traditional web apps.

Pros

  • Sencha have produced a larger quite of interoperable products, from “Sencha Architect” (a visual HTML5 app builder) and “Sencha Touch Charts” (for data visualization) to IDE integration with the Sencha Eclipse Plugin and an secure Enterprise app deployment story with Sencha Space.
  • Sencha Touch offers an MVC style architecture, a library of UI components, an extensible API and UI themes among other features.
  • Native packaging is possible via Apache Cordova/PhoneGap or Sencha’s SDK.

Cons

  • Mobile apps written with Sencha Touch can suffer from the same performance pains as Cordova/PhoneGap apps if developers aren’t disciplined in writing efficient JavaScript and DOM structure(s).
  • Many developers already have established opinions and experience with preferred frameworks for building HTML5/JavaScript/CSS based apps. Sencha’s emphasis on its own stack will be perceived as vendor lock-in.
  • Extending a Sencha Touch app with access to additional native APIs will likely involve writing custom Apache Cordova/PhoneGap plugins. This will require specialized platform skills (or training to acquire them).

Qt

Qt (“Cute”) is a cross-platform development tool that targets a number of embedded, desktop and mobile platforms. Developers write using “QML“, touted as a “CSS & JavaScript like language”, and apps are backed with an extensive set of C++ libraries, and utilize graphics/UI components written in C++. [UPDATE: As clarified by @qtproject, “Qt exists as a free and open source version from @qtproject and a commercial offering on top, from @QtbyDigia“]

Pros

  • Qt provides a substantial set of libraries containing intuitive APIs for things like threading, networking, animations and more.
  • Qt’s IDE tooling (Qt Creator IDE & Qt Designer) appear to be solid development tools, and code profiling is available in QML Profiler.
  • Qt Linguist enables translation and internationalization in applications – giving you the support of multiple languages within your app (in a single binary).

Cons [updated thanks to new information from Digia]

  • Qt’s tools are advertised as a “complete tool chain”, and QML is a proprietary language specific to Qt’s stack. Committing to this approach could be seen by many companies as ‘platform lock-in’, given that most businesses are seeking to re-use existing skill sets when adopting a CPT, not fragment skills further. (The leap from JavaScript to QML may not be as far as a leap from web-based skills to Objective-C, for example – each team just needs to evaluate what it can handle).
  • [Updated] Originally we listed pricing as a “con”, since full commercial support could exceed €4,000 (this includes plug-in development, platform development, device modification as well as unlimited support and updates). The cost of this kind of support is significantly higher than support costs for the other CPTs we’ve looked at. However, Digia reached out with a link to the recently announced Qt Mobile Edition. According to Digia the monthly fee will be $149 (approximately €110) and will launch in the coming weeks after the release of Qt 5.2.  This pricing level puts Qt’s mobile development costs more in line with the alternatives we’ve discussed. (It’s also important to note that Qt supports an open source LGPL v2.1 license.)

Reality: You’ll Probably Use More Than One

In our Developer Economics 2013 report, we noted the following:

Developers most often use several cross-platform tools; on average CPT developers will use 1.91 CPTs, confirming the lack of maturity and niche nature of cross platform tools much like we observed in our dedicated CPT survey just over a year ago. Moreover, we found that one in four developers will use more than three cross platform tools.

What CPT(s) do you plan to investigate or adopt? Check out the full list of CPTs we’ve identified.

 

Which of these are your favourites?  Test your skills in the new Developer Economics Survey and win awesome prizes.

Categories
Tools

Cross-Platform Tool Trends – Freemium & Flexible

CPT trends

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.

Categories
Tips

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

BaaS Shootout - Parse Alternatives

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 sencha.io 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 sencha.io 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.

Categories
Tools

Cross-Platform Tools Shootout

Cross-platform tools

The “write once, run anywhere” concept may be pure fantasy for most apps but sharing code across platforms is desirable and in some cases essential to making projects economically viable. With the application frameworks for all the biggest platforms being in different languages, the market for Cross-Platform Tools (CPTs) to enable code reuse is understandably the largest one (in terms of number of competing solutions) we track. The time required to evaluate all of them is far beyond what most developers can afford to spend on such research. So, which tools are the best?

Balancing mindshare with developer ratings

In our last developer survey we asked CPT users to tell us what they considered most important when choosing a CPT and also to rate their primary tool (some developers use several) across multiple criteria. Because that report was primarily about tools, several of the CPT vendors promoted the survey to their developers. Although we try to weight responses resulting from different promotions to attempt to remove this sampling bias in our statistics, it’s not possible to eliminate it entirely from the relative popularity of the tools themselves. As such, although the developer mindshare is a useful indicator of quality tools, we shouldn’t trust that alone. Amongst the most popular tools, it turns out that CPT users are generally very happy with their choices.


The average score out of 5 for all of the tools with more than 30 sets of developer ratings is close to 4 and weighting that by the relative importance of each aspect increases the average for all of the tools except Qt.

Compare with care

[tweetable]It’s important to be careful when comparing scores for individual tools[/tweetable], since they may reflect the typical backgrounds and expectations of developers using them rather than some absolute rating. For example, Sencha scored 4.08 for “Native UI look and feel” despite having pure HTML5/JS/CSS components while Appcelerator only scored 3.86 here despite binding JavaScript logic to actual native components! Haxe (pronounced Hex) also shows a couple of issues like this. It’s a relatively unknown code translation tool which seems primarily targeted at former Flash developers, although by no means limited to that audience. Since the Haxe language can be compiled to most of the major programming languages it scores very highly on “Availability across platforms”. However, it’s important to note that unless developers want to build their own application framework from scratch or integrate with one in the target language manually they’ll also need NME, which does support a very wide range of platforms but not as many as some other CPTs. NME’s feature set is fairly gaming oriented, with access to further native APIs via native extensions, much the same as most of the other CPTs – there’s certainly not sufficient additional API coverage built-in to justify the increased score. Clearly it’s important to make a more thorough evaluation of tools before making a selection, even so, lots of satisfied developers can be a good indication of an interesting tool to evaluate.

And the winners are…

Using the weighted average score as our benchmark, overall Haxe came out as a clear winner in developer satisfaction. Second place went to Sencha, which seems to come out top on almost all metrics (except popularity) amongst general purpose web-centric CPTs. A very close third was RunRev’s LiveCode, which has recently gone open source with a dual-licensing model. None of these top 3 tools by developer satisfaction have more than 12% mindshare amongst CPT users, let alone the wider developer population. They all cover mobile and desktop platforms and between them cater to most tastes – there’s a strictly typed language (Haxe), web standards (Sencha) or a very high level dynamic language (RunRev). All of them are free to get started with, why not give one of them a try and find out why their users are so happy? After all, a happy developer is a productive developer.

Categories
Tools

Cross-Platform Tools – Does it pay to use them?

Cross-platform tools

In our January 2013 Developer Economics Report, we revealed that multi-platform developers are better off. Our survey data also reveals, rather unsurprisingly, that users of cross-platform tools (CPTs) target more platforms than those building separate apps for each platform. Of those interested in making money, users of CPTs target 4.33 platforms (3.1 mobile platforms) on average vs 3.46 platforms (2.57 mobile) for those building separate apps. We also know that the most popular class of CPTs (using web authoring languages) tradeoff app capability to get the increased portability. At the same time, popular opinion on the internet and amongst venture capitalists is that a cross-platform user experience can’t compete with using the platform native frameworks. So how do these tradeoffs translate into revenue for CPT users?

CPT users make more revenue

On average, CPT users make slightly more revenue per app per month than developers not using such tools. With the reduced cost of development provided by the CPT, this suggests that they’re significantly more profitable.

Averages can be deceiving where the distribution of results is far from normal, as with app revenues, so it’s worth examining the details. App revenue is heavily concentrated at the top end of the market, with a large fraction of the (mean) average coming from a small number of very high earners. If we exclude all developers earning more than $50k per app per month then the result holds – CPT users still generate more revenue.

Not all CPTs are created equal

There are also several different types of CPT. Games have been responsible for close to half of all app revenues (at least those generated directly through app stores) and since they typically don’t require many platform-specific APIs or UI elements, they’re a good candidate for building with cross-platform. This suggests that users of primarily games-centric CPTs like Corona, Unity 3D & Marmalade might be responsible for the out-performance of CPTs, while users of the low development cost tools taking advantage of web authoring languages, such as PhoneGap, Appcelerator, Brightcove & Sencha, generate slightly lower revenues. However the data shows that the opposite is in fact the case.  Users of the games-centric CPTs are generating below average revenue, whilst the web-centric CPT users are significantly better off. These results also hold whether or not we include those earning over $50k per app per month.

A plausible explanation for this is that most of the larger and more successful game developers are managing their own cross-platform compatibility or code re-use whilst many smaller independent game developers relying on 3rd party tooling are struggling with the fierce competition in the games market. At the same time it seems that, when it comes to revenue, a fully native user experience and native performance are not as important as their proponents suggest. The very high earners using web-centric tools are most likely to be existing publishers selling their content through mobile app subscriptions and our revenue estimates are probably too low, since the top income band in our survey is everything over $100k per app per month.

Both ends of the revenue spectrum

For several CPTs in our survey we didn’t have enough respondents to be sure differences in revenues for individual tools are statistically significant, however, there are a couple of individual ones worth highlighting. At the low end, revenues for Qt developers were significantly below average – this probably reflects the fact that Qt does not yet have official support for iOS or Android (planned for this year). At the high end, although we only had a relatively small sample, revenues for Brightcove App Cloud users were more than 3 times the average making the difference statistically significant, whether or not we include those generating over $50k per app per month. Brightcove appear to be focussing their solution on a particularly profitable market segment.

Tool selection – do it for the right reasons

Finally, if you’re looking to select a CPT, make sure you do it for the right reasons. Main selection criteria including access to native APIs and the ability to create a native UI look and feel are correlated with above average revenue, whilst the availability of third party extensions and choice of authoring languages are correlated with below average revenue. The former criteria look to minimise some weaknesses of the cross-platform approach whereas the latter criteria focus on reducing one-off costs. The latter are not necessarily bad reasons for choosing a tool but if they are amongst the most important reasons for your selection then it’s worth re-evaluating priorities. Work out what will enable the creation of the best product at acceptable cost rather than simply minimising cost. If the lowest possible development cost is critical to make the app concept viable then it’s probably time to come up with a higher value concept.

Categories
Languages

HTML5 vs Native – What are the tradeoffs?

HTML5 vs Native

In our latest developer survey we asked developers who use or plan to adopt HTML5 why they do so and also what the technology needs to compete with native alternatives. The results show a tradeoff of increased portability and lower development cost against capability, in the form of reduced API access and a poorer development environment. In this scenario, the key to success with web technologies is taking advantage of their strengths in areas where their weaknesses are less of a handicap.

Developer Economics 2013 - HTML5 trades off native optimisation for portability and cost

HTML5 is becoming a viable alternative to native development across a number of app categories. We found that HTML developers mainly focus on specific app categories such as Business & Productivity (42% of HTML developers), Enterprise (32%) and Media apps (28%). On the other hand, Games are not a common category among HTML developers (12%).

We asked developers that use or are planning to use HTML about the reasons for platform selection. The majority indicated code portability as the main incentive for using HTML5. Low cost development is the second driving force for HTML5 adoption, highlighted by 51% of developers. HTML is still an “extension platform” in that only 26% of developers who use it consider it their main platform. We asked developers that use, have used or are planning to use HTML what they think HTML5 needs to compete with native platforms. Access to native APIs is a top challenge with 35% of developers indicating this as a critical success factor. HTML5 will always be a step behind in support for native APIs, given that cross platform tools and browser vendors will always have to implement support for a new API after it is released to developers by the platform vendor. In addition, the HTML5 development experience is subpar, with developers indicating that a better development environment (34%) and better debugging support (22%) are needed. More importantly, optimised HTML5 devices were not seen as important as the native API access or dev environment. This leads us to conclude that HTML proponents such as Facebook, Mozilla and Google should focus on cross platform tools and development environments on at least equal levels as they focus on full platform efforts like Facebook Platform, Firefox OS and Chrome OS.

[doritos_report location=’DE13 Article – HTML5 vs Native’]

Categories
Business

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.

DE13-18-01

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’]

Categories
Platforms Tools

Cross-Platform Tools – Functionality and Trade-offs

CPTs components

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.

Continue reading “Cross-Platform Tools – Functionality and Trade-offs”
Categories
Tips Tools

Mapping Cross-Platform Development Tools: Technology Approaches

cross-platform development tools

In our 2012 analysis of the cross-platform development tools (CPT) sector, we have identified five distinct technology approaches being used:

  • JavaScript frameworks
  • App factories
  • Web-to-native wrappers
  • Runtimes
  • Source code translators

Each technology targets a slightly different developer audience – from non-developers to seasoned programmers – and addresses different application use cases. These technology approaches are not mutually exclusive; many tools use a combination of technologies. For example some runtime-based CPT solutions are adding a webview component, which enables them to create hybrid web app wrappers.

Continue reading “Mapping Cross-Platform Development Tools: Technology Approaches”