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.
Anatomy of a cross-platform tool
A cross-platform tool may involve up to five types of component, which correspond to the five stages in the app lifecycle: develop, integrate, publish, deploy and manage.
The trade-off at this stage is to use a familiar or higher-level authoring environment across all platforms at the cost of flexibility in terms of direct access to the platform APIs. Being constrained by the tools vendor’s roadmap is the price for sharing code and not having to learn a new language, or hire people that know it already. In some cases tools try to provide the best of both worlds by enabling developers to create native platform extensions, maximizing shared code whilst retaining flexibility. This approach is not without drawbacks either; mixed language development adds complexity to the application, making it harder to debug and maintain.
The IDE (integrated development environment), emulator and debugger are core parts of the Develop stage. The open source IDE Eclipse is most often used as a basis, as the development environment is cross-platform itself across PC, Mac and Linux. On top of Eclipse, vendors provide additional plugins and emulators. Some vendors offer an install-free, web-based development environment specially designed for enterprise developers or designers working for a brand.
The Develop stage can also involve source control, collaboration and workflow tools. RhoMobile’s RhoHub uses Git repositories to manage source control and collaboration. Unity, Appcelerator and RunRev provide marketplaces where designers and developers can sell components and assets with the aim of helping others to speed up their development cycle with off-the-shelf components. Sencha soft-launched a similar component marketplace in November 2011, while Corona and Marmalade host a template repository and code community, respectively.
This stage is about integrating with native device capabilities, cloud APIs and enterprise databases.
Many of the most important trade-offs occur at this stage and it will often be the key decider between tools. The more interfaces are abstracted, the greater the level of code that can be reused but the lower the level of control developers have over the final application. If the UI APIs are abstracted then there is either a smallest common set of components, or the application will not provide a native look and feel on each platform. If hardware-specific features are abstracted then developers cannot take full advantage of the hardware provided on each device. On the other hand, if the APIs are not abstracted then code in these parts of the application cannot be shared. Xamarin sits at one end of this spectrum – their Mono Touch and Mono for Android do not share common APIs for UI, multimedia or hardware-related features, simply wrapping the native platform APIs with a thin language binding. At the other end of the spectrum Corona attempts to provide the same APIs for everything across platforms.
Connecting to cloud APIs is another major part of the integration process. Cloud APIs are turning into a market segment of their own. Social gaming networks have become increasingly important to mobile developers, and this is not just Facebook or LinkedIn. The Apple Game Center, Scoreloop, Skiller, Papaya Mobile and Swarm provide cloud-based APIs for social gaming.
Social APIs are only a small part of the picture. There are over 14 vendors providing in-app billing and virtual goods platforms, including Bango, Social Gold and Paythru; more than 27 selling sales analytics tools such as App Annie, Distimo and Flurry; more than eight offering app diagnostics tools such as Bugsense and Testflight. There are, of course, signs of consolidation. Appcelerator in particular has its own analytics and monetization platform and acquired Cocoafish to integrate social sharing and push messaging features.
Application platforms targeting enterprise (B2B) developers often provide services for managing database connectivity. RhoMobile offer the RhoConnect mobile app integration server, which provides data synchronisation by pushing out updates to the device as they happen on the backend. CPT offered by Antenna, Feedhenry, and Worklight provide similar integration middleware. Other notable cross-platform tools dedicated to enterprise development are Stackmob, Oracle (ADF), Aperra and Sybase (Unwired Platform).
The build stage is where the cross-platform “magic” occurs. There are a number of different approaches for building the application. The two most popular are: compiling the code and UI templates directly to native platform binaries; or, packaging code in a native shell and interpreting through a runtime, which could be a ‘naked browser’ packaged with the code, or even the device’s own browser rendering engine.
Another minor trade-off at this stage is that some vendor companies use it to safeguard their business model. In such cases, you can only build with a connection to the vendor’s servers and a valid license. For most this is only a minor inconvenience, although others will find the inability to work offline an unacceptable compromise. There is also the question of the impact to your business if your tools vendor ceases to offer the product for whatever reason. This concern is much larger than the simple case of being able to complete a build though, whether the tools work offline or not, loss of an upgrade path could be fatal to your products.
Publishing an app involves submitting it to the native app store (e.g., Apple App Store or Android Market) or publishing internally with the option of hosting on a private enterprise app store (e.g., with Feedhenry, Antenna, RhoMobile or Worklight). Many CPT products help to manage the App store publishing process to some degree; these include Sencha 2.0, AppMobi’s PhoneGap XDK, and RhoMobile’s RhoHub. Some vendors such as Appcelerator LiveCode and Corona will showcase apps on their websites, while Unity (with ‘Union’) also provide support for publishing to additional platforms.
There is only a minor trade-off of convenience for control in some cases here. In others the self-publishing option is still available and any assistance is just an added convenience.
“App management” functionality is typically offered by enterprise-targeted CPTs (e.g. Worklight, RhoMobile, Antenna, Feedhenry). It may include push messaging and data flow management, along with remote (un)installation, policy management, and inventory management. Management of commercial apps adds performance tracking (i.e., analytics tools) that may be provided by vendor partners. For example, Appcelerator deeply integrates its own analytics into Titanium, while Ansca Mobile integrates Flurry’s analytics APIs into its own Corona SDK.
Having the CPT vendor manage the application simply adds to the impact of the vendor ceasing to offer the service. It would be an unwise gamble with a small or poorly funded vendor for this type of service.
It’s all about the trade-offs
As we have demonstrated, CPTs cover a wide variety of solutions to the same basic problem. Using a CPT can produce maximum reach or device support with minimum effort. Saving more effort will usually involve making more compromises. At one extreme, some CPTs are simply libraries that help smooth out a few of the quirks between different platforms’ browsers at the cost of a dependency on third party code and possibly a little bloat in the application size. At the other extreme are app factories, where no programming knowledge is required but almost no control over the user experience and features of the resulting app is offered at all. Just about everything between those two extremes is available, although the various offerings can be categorised into five different technology approaches along this spectrum. Understanding the platforms supported by each tool and the trade-offs made in doing so is the key to deciding on the right tool for each app. Understanding how the different technology approaches produce those trade-offs is how you identify the right tool.
Looking for a list of cross-platform development tools?