June 28, 2019
In my previous blog post, I briefly explained the bumpy road of cross-platform mobile development. Now it’s time to take a closer look at the pros and cons of current cross-platform technologies, evaluate them and try to establish where the mobile app road will turn next. It’s a tight race with sharp bends – ready? Let’s go!
Near-native technologies give you something that no native language (Java/Kotlin or Objective-C/Swift) can – up to 70% of the code can be shared between platforms. Jackpot! In effect, with frameworks like Xamarin, React Native and Flutter, you get two mobile apps for the price of one. This is probably the most important advantage of the near-native approach. The remaining 30% is platform-specific code, which is a pity – but even though we can’t share everything, it is a huge time and money saver.
If you plan to create a mobile app for all main mobile platforms, a near-native solution can cut cost almost by half.
In contrast to hybrid applications, where the entire UI runs on WebView – the main cause of performance bottleneck and rendering issues – near-native uses native components that gives the look and feel of a native app. This literally means that they are practically identical in appearance and speed. As a user, it is unlikely that you will notice the difference between near-native and native.
Performance is not the only thing that matters – production time is just as important.
If you work on an Android or iOS native app, you know how much time is wasted waiting. Every time you change the colour, font size or a spacing you need to wait 10 – 30 seconds to see the result. This is even more time consuming if you are working on a screen which is far from the launch screen. You’ve got to click on the same path again and again to get back to the future you work on. Not exactly efficient, right?
Most near-native technologies solve this by implementing a mechanism called hot reloading, which keeps the app running and saves the screen you’re on while only updating the actual changes in the code. This nifty solution makes a huge difference as it shortens the time between saving the file and the seeing result to 1 or 2 seconds.
In the case of native apps, you have to be prepared for double maintenance cost. It’s a very simple equation. If you have two codebases, one written in Java by one team and another written in Objective-C by a second team, you can be sure to face twice the number of bugs compared to having one codebase for two platforms.
Fewer bugs + fewer developers needed + less time used = more money in your pocket.
Still, there are some cases where native development is a better choice. I would even say that there are cases where cross-platform mobile development is not recommended. Even though near-native solutions have great performance capabilities, there are apps that demand cutting-edge performance, for example 3D games and apps that use technologies like augmented reality (AR). This is a field where cross-platform technologies can’t compete – for these kinds of apps, near-native performance is not enough. Native simply has optimal performance and gives the user a smoother experience.
Another benefit with native development is that you get access to new features faster – when an SDK (Software Development Kit) is released, you can just add it to the codebase and it’s ready to go. With cross-platform mobile development, you have to write a so-called connector (bridge) to the native part of the app, or wait for the community to do so.
So am I saying that native development would always be the best option, if money and time were no concern? Actually no – it’s not just about how fast the technology is, but how fluently the end-product works. Would you buy a sport car like Ferrari just to cruise around the city? Sure, you can do that. It will have great speed capabilities, but you wouldn’t have the chance to use that speed and wouldn’t really need to. A Toyota will do the job just as well. There are plenty of great apps that have no need for top speed. Every app project has to be evaluated on its own terms.
And in any case, the experience and skills of the developers will always be more important than performance gaps between technologies. I have seen many great and not so great apps done in both technologies. At the end of the day, it comes down to having good people in your team. With competent developers, killing two platforms with one codebase can produce excellent results.
That’s all good, but which framework should you use for the best result? The short answer is that it doesn’t really matter, at least for now (June 2019). Xamarin, React Native and Flutter are all fantastic technologies which can be used to produce stunning mobile apps.
Of course they are different in terms of amount of sharable code, performance, tooling, maturity, number of libraries and community size. If you want to dig deeper, you will find plenty of articles on the subject. In my opinion there is no strong leader in this race yet, but the situation is dynamic and could change in the near future.
I’ve already mentioned this above, but I think it is worth to say it again: Which technology you choose is a detail. It is the experience and skills of the app developers that makes a difference. With good people, you get good results.
The future of near-native technologies looks bright. Big players heavily compete with themselves in this field. They invest enormous amounts of time and money to convince businesses and developers to use their products. That’s very good for the mobile world – healthy competition always ends with the best possible results for the users.
Where will the mobile race end? It’s hard to say, but one thing I know for sure. A common language makes everything easier for everyone: Businesses, developers and users alike.
Read more in part 1 of this article here: The bumpy road to cross-platform 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.
Contact Paweł: firstname.lastname@example.org