Native or hybrid? Six factors to consider when building your app.
How should you build your app, native or hybrid? Today we’ll break down that decision into six major factors and hopefully leave you with a clearer sense of the right approach for you.
Hybrid frameworks have been around since smartphones were invented. I’ve written lots of native apps for iOS and Android, and hybrid apps on all the major frameworks. I’ve been helping people make this particularly critical technology decision for over a decade.
For simplicity I’ll assume you’re committed to having an app in the App Store, rather than just making a website. Given that let’s discuss the two ways to build:
Native
First, building natively, that is to say in the native languages of the operating systems. These days that’s Swift for iOS and Kotlin for Android. You build two apps, one for each platform.
Hybrid
Second, building using a hybrid framework, like React Native or Flutter. These are designed to be single codebases that produce apps for both iOS and Android, so you can write everything once, with one team, and deploy to both platforms.
We’re going to break this all down, but if there is one thing you remember it should be this: building natively is how iOS and Android apps are intended to be built. If you are going to do it differently, you must seek out existing apps that are built with the same technologies you’re considering, and make sure they meet your standards. If you can’t find anything don’t count on being the first company to do it.
OK there’s lots to consider here, let’s just hash it all out.
Factor 1: Redundant work
The challenge with building native apps is that if you want to maximize your user base you need two apps, one for iOS and one for Android. This adds logistical overhead trying to keep your apps in sync, and leads to redundant work building the same features on two platforms.
That’s the key problem hybrid frameworks try to solve. And they do solve this well in certain conditions. If your app is simple you can probably get most or all of the way on that single codebase. But anything the hybrid framework can’t handle will have to be written natively. So as your project matures, if your needs grow beyond the capabilities of the framework, your risk is that the framework’s value turns negative, because now you’ve gone from one team to three - one for hybrid code, one for custom iOS components, and one for custom Android components. And now the code bases are all interwoven instead of being largely independent of each other, and there’s a bunch of overhead just understanding how they all interact. So hybrid frameworks move from efficient to inefficient as your app becomes more complex.
Do you need two apps right away?
A common way to build a more complex app on a budget is to start with a single platform, usually iOS because the average amount spent amongst that user base is higher. If you find success on that platform, it becomes easier to raise the money to build on Android too. That may or may not be right for your business but it’s worth considering.
Factor 2: Slickness and polish
There are technical reasons for this that I won’t go into, but as a general rule hybrid frameworks are slower and less polished than native apps. These differences can be subtle with simple apps, obvious with complex apps, and at a certain point you just have to do it native.
If the heart of your app is giving your users a fairly simple tool, and the polish and slickness of the app isn’t a primary concern, then hybrid is ok here.
Factor 3: Staying current
Native apps are built in technologies that Apple and Google expect most teams to build in. When Apple releases the new iOS, when Google releases their latest version of Android, the development tools that ship with each release are built primarily to serve that base of native app developers first. Once those tools are released, the developers of hybrid frameworks need to update their systems to support the new features, and some features might just not be feasible. So with a hybrid framework you’re occasionally going to be a little behind the times, and there’s a chance you’ll hit a wall in what can be done. With native that’s not the case.
Factor 4: Labor cost
Native app engineers are typically more expensive than engineers that work with hybrid frameworks like React Native or Flutter. Add the increased labor from not having a centralized codebase, and the costs can be significantly higher to get to both platforms with native.
Factor 5: Web compatibility
Both the major hybrid frameworks, React Native and Flutter, can deploy to web. This is just flat out not possible with native apps. So if a web app is an important part of your offering, and your functionality is sufficiently simple, the hybrid frameworks start getting really cost effective.
Factor 6: Logistics
When you have a centralized codebase, it’s easier to keep everything in sync. When you have two teams, the teams can end up moving at different velocities and features can arrive on different platforms at different times. There are ways to manage this, if you’re working with more senior level engineers they can often build a new feature on their dominant platform and then port it to the other themselves. This can be pretty efficient and makes it easy to keep features in sync, but it’s harder for less experienced engineers to contribute in that environment.
Summing it up
If you aren’t particularly budget conscious, there’s little reason to build with a hybrid framework. If budget is a concern, your app is simple, and you can handle it not being the slickest, most polished app in its category, hybrid frameworks are a good way to save money and get the job done.
