Keeping up with cross-platform tools
One of the great challenges of the rapidly changing mobile environment is that development tools are generally vendor specific. If you want to write native apps covering the majority of the mobile landscape, you need developers who can code in Java for Google and Objective-C for Apple, two very different languages with a host of different APIs and frameworks. Add Windows Phone or BlackBerry, and your development toolkit expands even further.
With these challenges, it's easy to see why cross-platform development tools have become popular, with the most common being Apache Cordova, formerly known as PhoneGap. Rather than attempting to produce native code, Cordova essentially creates a web application, and is based on web technologies like JavaScript and CSS. Cordova also has a rich catalog of libraries that allow cross-platform apps to access the device's hardware and native APIs, so you can do anything from capturing a picture from the camera to browsing the device's contacts application to find an email address.
Know thy stack
Like any development environment, there are some nuances and peculiarities to Cordova, but it's relatively mature and works fairly well. Where cross-platform tools break down is when device manufacturers update their mobile OSes. If I'm developing an Apple or Android app using native tools, I generally have a "one stop shop" for my development tools and associated libraries, with Apple or Google providing updates that accommodate any major OS changes. However, with Cordova I am relying on third parties that have the difficult task of updating their code to support the OS manufacturer's changes, potentially changes that are still in flux.
Furthermore, most cross-platform apps rarely use Cordova, and nothing else. Generally, a UI framework like React or Ionic is applied, along with a Model View Controller (MVC) like Angular.js or Backbone.js. Add a complement of libraries that might support the device's Camera or GPS module, or provide functionality like barcode scanning, and suddenly you have a minimum of a half-dozen components that could be affected by the latest Android or iOS release, or worst case, an event like we've had recently with Apple and Google releasing major updates about a month apart.
Documenting and understanding all the components in your mobile application will make researching the effects of a mobile OS upgrade significantly easier. This can be difficult, since it's so easy to drop a new library into mobile code that the urge to document and manage updates can be lost in the shuffle. Half the battle of managing cross-platform tools is knowing exactly what components comprise your application.
Some vendors have sold development products that extend the functionality of Cordova, and have promised "zero day" support for new mobile OSes. While these promises vary in delivery, you'll still likely be required to upgrade individual components and track the various libraries and third party tools that all but the simplest applications utilize.
Test early and often
Major mobile players Apple and Google both provide pre-release versions of their mobile operating systems in advance of their release to developers, with Apple requiring a paid developer subscription, and Google providing OS previews and most other Android-related tools for free. Timelines, however, are tight; an early beta might be three or four months in advance of the release date, and the first release is generally unstable and not representative of the final code. There's a delicate balance between spending significant effort diagnosing and fixing defects identified in an early beta of a new OS, versus waiting for a more "production quality" release that may resolve some of the issues you've identified.
Use an early release of the new OS to take stock of your application, and identify defects and broken components of your application to get a sense of how much work lies ahead. Wait for a later release of the OS, generally one produced four to six weeks before the new OS goes live, for repairing defects and performing a regression test on the app. Make sure you regression test all supported platforms, since that tweak you made to support Android Lollipop may break something on iOS 8.1. Automated testing can help in this area, but if that's too difficult or expensive, at a minimum make sure you maintain a comprehensive regression test suite that exercises all key functionality and visual design, so anyone on your team can frequently check the app against changes to the underlying mobile OS or upgraded application components.
Know the price of cross-platform
It's tempting to consider abandoning cross-platform tools, especially now when anyone with a cross-platform app is facing simultaneous major OS releases. However, the benefits still largely outweigh the costs, as long as you realize that cross-platform tools are not a magic panacea that completely absolves you from dealing with the underlying OS. As the foundation of a mobile platform changes, you'll have to do extra legwork to manage breaking changes and upgrades to your app's components, and also plan for significant extra testing that might otherwise be minimized with native tools. While cross-platform saves significant development time, it's also subject to that immutable law of the universe: there's no free lunch.
