The bumpy road to cross-platform mobile app development

The early days of mobile app development

In the early days of mobile app development, the code for each mobile operating system had to be built separately. The reason is simply that different platforms speak different programming languages (Java or Kotlin for Android, Swift or Objective-C for iOS). The native code written for a mobile app on an iPhone was useless for an Android device, and vice versa. If the app was going to work on different platforms, it was necessary to hire both iOS and Android developers. This was both time-consuming and costly, and software developers went out hunting for a better solution.

The game-changer HTML5

The web world developed rapidly and in 2014, the game-changer HTML5 was introduced. With added support for new types of multimedia, geolocation, offline support and much more, it opened the door to web apps that were independent of browsers and platforms.

These functions were quickly picked up by developers who saw the benefit of running web-based apps in a browser rather than as a mobile application. After all, it made it possible to create apps that worked on any device with a browser and on iOS and Android alike!

Excellent – although it turned out that it was a bit early to cork up the champagne. Web applications are not intended for mobile use, after all. Without many mobile features, apps built with HTML5 were of limited use. And if that wasn’t enough, these web apps were not available in the two main sources for apps: AppStore and Google Play. This made them both hard to distribute and hard to find.

Photo by Gilles Lambert on Unsplash

Hybrid applications: The holy grail of mobile development?

The software community responded with a neat idea: “What if we wrap the browser in a native container and expose all mobile features via API?” A new concept for mobile development had seen the light of day. These “hybrid applications” can be described as the marriage of web technology (HTML5, JavaScript, and CSS3) and native execution.

With one code base to rule all platforms, was this the holy grail of mobile development? Not quite. App developers soon realised that it wasn’t a land flowing with milk and honey after all. Hybrid apps had a drawback: In terms of performance, they were miles behind native apps.

Even though JavaScript was fast enough to provide a good user experience, the UI layer had to be done with HTML and CSS – and this proved to be a bottleneck. Why? Because HTML and CSS were never designed for web applications that are rich in animations. When Mr Tim Berners-Lee created the world wide web in 1989, he had no idea that it would be implemented on such an enormous scale.

Performance wasn’t the only drawback. Hybrid applications inherited the well-known issue of differences between browsers. When new features appear on the market, the major browsers follow a specification to implement those features. Due to human error or differences in interpretation, it is not always done consistently. This is a nightmare for app developers, who have to create pixel-perfect solutions for every browser. This in turn leads to longer production and maintenance time, which of course affects the app development cost.

The rise of near-native technology

The main question for the software community was how to use a common codebase without sacrificing performance. If the slow UI layer was the issue, how about swapping that part with something more powerful and stable? Ladies and gentlemen, you had my curiosity but now you have my attention!

The idea was simple. Create the lower layers of the app in a common programming language, but use a native UI layer which is both fast and free from differences between devices.

This setup allows app developers to write up to 70% of the codebase for iOS and Android with one language. With a performance level that is comparable to native apps, it has earned the name “near-native technology”. The solution attracted the attention of many large technology companies, which started working on their implementations. Microsoft came up with the C#-based tool Xamarin. A couple of years ago Facebook introduced the JavaScript-based framework React Native, which caused a bit of a wave in the market. In 2017, Google joined the race and released the highly appreciated Flutter, which uses Dart.

So have we reached the goal? With cross-platform development and near-native technology, can we ditch native app development once and for all? If so, which solution is our preferred option, and which direction will the mobile app road turn next? These are questions we will look into in our next blog article – stay tuned!

Read more in part 2 of this article here: Are cross-platform solutions heading for the throne of mobile app development?

Co-author and editor: Anja Wedberg