The Right Horse for the Right Course

For such an important decision, you would expect plenty of debate, and sure enough that’s often the case; not least because there are multiple stakeholders in the conversation who may not always be aligned. For example, the team designing the product might favour one approach (perhaps based on usability criteria) while the business bankrolling the project might favour another (based on commercial considerations).

Here at Smudge, unless we’re designing an app that will have a purposefully limited shelf life, we believe one of the most important factors in the technology decision-making process should be sustainability.

If sustainability is compromised or sacrificed (for instance at the expense of keeping down initial costs), then the long-term repercussions can far outweigh the short-term benefits. Venerable industry association the IEEE has estimated that ongoing maintenance accounts for around 60% of the total cost of a typical software project.

So we’re compelled to wade into a thorny debate, of which much has already been written but which we still believe to be worthy of discussion. Namely, the choice between native development and cross-platform development.

This debate has been raging in some form for years. At one point, the poster child of cross-platform frameworks was PhoneGap, which while well-intentioned has largely been abandoned by developers due to its inability to keep pace with the rapid evolution of iOS and Android.

Recent technology developments have rekindled the discussion, with many in the industry celebrating the arrival of a new breed of tools and frameworks that claim to enable cross-platform development for iOS and Android in a timely and therefore cost-effective way. Finally, the dream of “write once, run anywhere” is within reach.

Or is it? Some big question marks remain. So, what are the trade-offs, pros and cons of native vs cross-platform development?

Again, it comes down to picking the right horse for the right course. It depends on the problem you’re solving, which platforms you’re solving for, what resources you have at your disposal and importantly, how long you expect the app to be in use.

Going Native

At Smudge, we like to build lasting relationships with customers and create experiences that strike a balance between delivering value quickly and being sustainable in the long-term. For that reason we generally favour native development.

Basing a solution around native technologies gives designers and developers the opportunity to create an experience that takes advantage of the best practice performance and usability standards of a particular platform, as well as leveraging platform-specific features that users are familiar with. Native development helps eradicate risk over the long-term, since it delivers experiences that can evolve alongside the intentions of the platform owner.

One argument against native development is the perceived inefficiency and cost of creating and maintaining separate native codebases for different platforms. However, if you’re creating a solution that has a modicum of complexity and is likely to have a shelf life of more than a few years, then native development is not only going to deliver the best experience to the most number of people but is also likely to be the most cost-effective approach over the long-term.

If for whatever reason you opt not to follow a native approach then you have two options: a) consider a different experience entirely; for example, a web app or a website can deliver many of the same features of a native app whilst also having the benefit of visual consistency across platforms and devices, or b) wade into the murky waters of cross-platform development.

Enter At Your Own Risk

We generally prefer native development for the reasons stated above; however, if you’re creating a relatively low-complexity solution that will have a limited shelf life, then cross-platform development tools can be a good fit.

Where cross-platform development falls down is when it is used in service of the wrong kinds of experiences; for instance, when an app that was designed to be a simple or short-term solution needs to be enlarged with new functionality or outlives its intended shelf life.

Ultimately, it’s a case of minimising risk. When using a cross-platform framework there are many moving parts. You are not only locked into the host platforms (iOS, Android), you are also dependent on an additional framework, built and maintained by a third-party (Microsoft in the case of Xamarin, or Facebook in the case of React Native) who have little or no control over the evolution of the host platforms.

Let’s not forget, Apple and Google have thousands of engineers working to improve iOS and Android every day. And when they make changes to features that might be important to your app – or you want to take advantage of a new/improved feature – you’re reliant on the framework owner being responsive to those changes. Just ask Airbnb who, with over a hundred in-house developers, still struggled to deliver on the cross-platform dream due to some “painful” React Native upgrade issues.

What’s more, given the differences between the host platforms, most cross-platform frameworks require additional third-party libraries in order to access basic functions (such as maps or background networking), so you’re also reliant on those third-parties keeping their libraries up to date.

In native development, you’re riding a thoroughbred horse in a steeplechase, and the regular software improvements in iOS and Android are the fences. You don't necessarily get to choose exactly where the horse goes but you know it’s been well-trained and you can usually see the fences coming a little way off. This enables you to react accordingly, jump the fences and keep going most of the time, even when the race is long.

With cross-platform development, you’re in a chariot that’s being pulled by three different horses. When all the horses pull in the same direction, things can move really fast. The problem is, the three horses are running at different speeds. And the longer the race goes on, the more likely it is they'll start pulling in different directions, which can grind your chariot to a standstill or worse, tear it apart entirely.

While cross-platform development can be a quick and easy ride when the race is short and in a straight line, if you misjudge the finish line or the going is more bumpy than you expect, you’d better wear your protective gear.

Or better still, study the course carefully beforehand and pick a horse that’s more suited to the race at hand.

If you liked this article, you might enjoy our book. "Balance" brings together our best thinking in an easy-to-read format. It’s available as a hardback from the Smudge Store, a free download from Apple Books or an ePub file.