We’ve discussed cross-platform mobile app development quite a bit in this space in the last couple of years. It seems like every time we turn around, there’s another cleverly (if non-descriptively) named framework that claims to overcome the limitations of the others and promises ever-higher rates of code reuse across platforms.
Cross-platform tools have evolved and improved over the last few years, and are without question better than ever. Cross-platform development works well…except when it doesn’t. It’s that second part that gives developers (and project managers, and end users) fits.
Today we discuss some of the ongoing challenges preventing the emergence of true cross-platform development. But first, let’s review the motivations behind cross-platform development. Some are obvious; some not so much.
Why Cross-Platform Development
In the “obvious” takeaway is: More efficient development. Write it once; deploy it anywhere. Pay one developer to do the work of two. No need to make a choice of which platform’s customers to serve first. No need to try, with separate developers or development teams, to keep the features, functionality, and look and feel of two separate codebases in sync.
That leads to another motivation on the business side: Brand recognition. Being first-to-market on both platforms is a whole lot better than being first in one and second (or later) in the other. Plus, there’s no need to send the somewhat awkward message that your app is available now for iOS and “coming soon” for Android.
A third, less obvious motivation involves enterprise apps. Many companies are allowing, even encouraging, their employees to use their own devices for work; a phenomenon called “bring your own device” (BYOD). The trouble for app developers is, instead of relying on a company to supply a single standard-issue device model to all of its mobile employees, thereby requiring development on only one platform, it’s now a requirement that the app work the exact same way on all platforms, all devices. With the growing enterprise app market, this problem is going to get worse, not better, making cross-platform development increasingly attractive.
When Cross-Platform Development Works…
Given the state of today’s cross-platform development tools, when does cross-platform development work?
It depends on how you measure it. If the goal is 100% code reuse across platforms, then cross-platform development never works. There will always be some degree of platform-specific code to write and maintain.
Even setting the bar lower may not help much. Despite the promises of the providers of cross-platform development frameworks, the percentage of code that can be reused depends more on the design and functionality of the app and less on the framework that’s used. Apps for which most of the code renders the user interface (UI) or accesses the device’s hardware and software resources and features will have much less code reuse than apps that are heavy on back-end computation.
Thus, one of the cases where cross-platform development works well is apps that don’t have many UI screens. They don’t depend much on accessing device hardware features such as the inertial sensor, camera, Bluetooth transceiver, or software features such as contacts and the file system.
Another case that lends itself well to cross-platform development is games. Although games obviously require heavy graphical rendering, most games for mobile devices don’t have many different screens, and are generally free from the constraints of UI guidelines imposed by the app stores. A Mahjongg or Sudoku game can look and feel pretty much the same, regardless of platform and requires little platform-specific coding.
…and When It Doesn’t
That leaves a huge number of cases where cross-platform development doesn’t work so well; if at all. Instead of trying to list them here, let’s explore some of the reasons why cross-platform tools and frameworks have such a hard time living up to their promise.
UI standards: Apple, in particular, has strict guidelines around the look and feel of iOS apps. Apps that fail to adhere to these guidelines are likely to be rejected by Apple’s App Store. The Google Play Store is not quite as stringent, but Android users are accustomed to a certain look and feel from their apps, and straying from these de facto standards can result in low ratings. The two sets of guidelines are sufficiently different—for example, the way menus behave, the way notifications are presented, and more—that it’s nearly impossible for one codebase to satisfy both of them.
UI rendering: Even if the UI standards were exactly the same on both platforms, the way each OS renders them is different and requires different coding approaches. That’s why apps with lots of different screens increase the platform-specific footprint in the codebase.
Hardware features: Similar to UI rendering, access to hardware features is realized differently on each platform. On top of that, the same type of feature—the near-field communication (NFC) radio, say—may work differently on each platform, or may be accessible on one platform but not the other. It was only recently that Apple allowed third-party app access to the iPhone’s NFC radio, and then only in a limited way; Android has allowed unfettered access to device NFC radios for a long time.
But a major reason why cross-platform development may never be as easy as it should be is, Android and iOS are both continually evolving, sometimes in disparate ways. The providers of cross-platform development tools and frameworks are constantly playing catch-up with both of them—every new feature in one might (or might not) eventually have a counterpart in the other, and the frameworks have to be updated accordingly. Sometimes equivalent features can be modeled in a cross-platform framework, and sometimes they can’t.
Strategizing Cross-Platform Mobile Development
Choosing a direction—native development on each platform vs. cross-platform development—often will come down to (you guessed it) those three pillars of project management: time, cost, and scope, with some input from the marketing side. Every project is different, so you can’t expect what worked (or didn’t work) in the past will hold for the future.
You will need to compare each approach on the basis of the scope of the project (what’s expected to be delivered in that all-important minimum viable product), expected delivery date, and budget. The level of effort required for each approach can be accurately estimated only from past experience, which is why an agile development framework is so important; the data from past sprints on similar projects should provide a good basis for a solid estimate.
Don’t forget, though, that it’s not just the initial release you need to be concerned about. The ability to maintain and enhance the product is just as important. So have a look at the product roadmap—the features and functionality expected to be added in future releases—and factor it into your decision. If the future feature set can be handled well with a cross-platform approach, it might be wiser to start out that way, even if the initial release has a low percentage of code reuse.
The future remains mobile, and neither Android nor iOS shows any signs of slipping. Ultimately, the best strategy is knowing how to choose your approach, and that requires understanding your known- and unknown-unknowns. Good luck!
