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 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.
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.
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 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.
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
Front-end advisor and manager Paweł Bród is passionate about designing and implementing the best possible user experience applications. He is also the brain behind kinolek.pl, a popular cinema web page and mobile app that he constantly works on improving.
October 24, 2023 / 3 min read
At the end of September, our employees participated in the 9th edition of HackYeah. As Quantastic Team, they get the chance to create art with quantum computing and win the first...
September 29, 2023 / 11 min read
Commerce has undergone significant evolution. With the rise in digital transformation and the demand for personalisation, the concept of 'composable commerce' has surfaced as a modern...