Two apps for the price of one? Deciding on cross-platform vs native.
The discussion dates back to the dawn of mobile platforms. Which is ultimately the best, and for whom?
The discussion dates back to the dawn of mobile platforms. Which is ultimately the best, and for whom?
The upside of hybrid is obvious: Do all the coding and testing once, get two apps instead of building everything twice. Sounds great, but it’s not that simple.
The problem is that, when the platforms differ enough or there is something missing in the tooling, you need to put in extra work to get the cross-platform toolchain to work well enough with the native platform. If you have to spend too much time on it, the upside is lost.
Also, users are hard to please and truly breath-taking apps require a native experience.
When deciding which way is best for your app, you need to ask yourself four questions: What do the users want, what does the market want, what do the developers want and, finally, what do you want.
So let’s get started.
What do the users want?
Users want the best experience, and that happens in a native app. Some markets are more sensitive than others—if you write a B2B app for logging working hours you can probably get away with compromising on polish.
Personally I believe in happy users, and you get that by not compromising on quality. It can be done with cross-platform tools but takes more time and effort, canceling out the time saved by a shared code base.
Certain cross-platform tools make the app look native but feel out of place. This eerie feeling makes users uncomfortable and has no place in a quality application. On the other hand, if the resources simply don’t exist, I bet the users would rather have an app than not.
What does the market want?
It might be in your best interests to deliver something quickly to test the market and see if the product/idea finds traction with real customers. The UI glitches common in cross-platform solutions could still be acceptable at this stage.
If the app isn’t a success, you have saved some time for your next project. And if it is, you are free to spend the necessary resources to polish the app to perfection.
In some cases though, your app will need that extra edge to beat the competition and thrive. Native might be a requirement in that case.
Instagram and Clubhouse famously went iOS-only for their releases. That is one way of saving precious time without needing to compromise on experience. However, this could be too harsh of a tradeoff for most.
What do the developers want?
Web developers can grow into mobile developers by building an app with React Native and gradually learning their way around the mobile platforms. Promising Xamarin or MAUI gives access to all C# developers, but these systems are resource hogs, which can be a show stopper for certain apps.
Fighting bugs in third-party code is also a cost you should take into account, even when it takes less time overall than having two code bases. You can avoid most of the headaches by leaving the UI native and going cross-platform in other areas.
Sharing code in C/C++ is usually most efficient in terms of CPU/RAM usage, but then you will need developers who like to code in these languages and are good at it. Which can be difficult or expensive.
Learning a new language is easy after the first one, but some people like the safety of what they already know, and won’t happily embrace C++. Which is also known for being hard and error prone, which is also a hurdle.
There is a way to share non-UI code that can hit the sweet spot for all these parameters: keep shared code in a common language most of your team likes and is good at, e.g. Rust, Kotlin or Swift. These are liked by developers and are easier to work with than C++. If done correctly, linking to a library written in a different language is not a particularly big undertaking.
Still, native tools are usually better and cause less friction and annoyance. This makes for happy developers, and they build better apps.
What do you want?
What’s best for you naturally depends on what your service is about. Every app is different, and you can only find the perfect solution by looking at your specific needs and what makes your service unique.
If the app changes frequently and you need to be able to modify entire sections quickly, it might be best to use a web-hybrid solution that uses your web for UI. This also bypasses app review and user updates, letting all users see the new content as soon as it’s released. For time-critical apps, this can be very handy.
The most important thing here is that you need to stop and think about the actual problem you are trying to solve. Development is not so much about typing code into a computer to get things done, but rather the problem-solving you do before laying a finger on the keyboard. When you have found the solution, it does not take much more time to do it twice, or even three times.
Let us have a look at your needs and recommend the best solution for you—for today and the future!
Want further reading? This is not the first time we wrote about native vs. cross-platform solutions. Check out these articles:
- Native, hybrid or cross-platform? Choosing the right app technology goes a long way towards commercial success.
- React Native is the best option, sometimes
… and if you’re about to choose a programming language for your project, here’s a story for you.
This article has been created with input from multiple Qvik experts, including Jonas Frid and Mirva Uotila — a big thank you for everyone who pitched in!
Illustration: Aija Malmioja
