.jpg)
Speed is everything in today's fast-moving business world. For software developers, this means the race is on to get new apps to market faster and better than competitors.
In light of this constant pressure to deliver, it's no surprise that the demand for hybrid development continues to rise. After all, with one codebase that runs on multiple platforms, how can you go wrong? In reality the choice is not always so clear-cut. For example, when performance and user experience are crucial, native development, built specifically for a single platform (iOS or Android), continues to have the edge.
So the question remains: which approach is ultimately best, and what should developers consider to choose wisely?
We addressed this topic and more during our recent webinar with special guests from across the mobile community, including:
- Donny Wals, iOS Engineer, Author and Speaker
- David Rifkin, Developer Relations Engineer at Embrace
- Adam Shott, Director of Engineering for the App Platforms Group at The New York Times.
Our expert panel explored many of the hottest topics surrounding the hybrid vs. native debate, including what to consider in weighing up the pros and cons of each approach.
Here's a recap of the conversation.
Hybrid or native app development: which is better?
[David] As technologists, which is better is not necessarily the question we're trying to answer here. A better question might be: how do you choose between them, and what factors should guide that choice?
Our job as engineers is about problem-solving, so the focus should always be on understanding the problem and then figuring out the best approach to solving it.
[Donny] I think there's an interesting question that aligns with this: Can hybrid apps meet the same performance benchmarks as native apps? But to really answer that, you need to first understand where your performance bottlenecks are. And if hybrid is actually leading to performance issues for your app.
The reality is that hybrid will never perform as well as native. In the same way as Swift UI is never going to have the same performance as directly core graphics code or even going directly to your graphics processing unit (GPU) will have better performance than any abstraction over it, right? Does that mean you have to write everything in GPU code? No, not at all. That's rarely the bottleneck.
So as you can tell, it’s a complex question. The best way to try to figure out the answer is to start with your performance needs and work your way up from there.
[Adam]: There may be no universal right answer here, but there are more helpful ways to frame the question. Working backwards from the technology can lead to the wrong questions.
The first step is to take a deep breath and recognize that these are all just tools in your toolkit. In other words, it is not a clear-cut "versus" situation. Ultimately, as engineers, we want to build the best app possible, and sometimes, that means using different tools for different jobs.
When it comes to developer productivity, what are the differences between hybrid and native development?
[Adam] Native development has often got a reputation for being slow. And so people turn to hybrid in an attempt to move faster. But what does it actually mean to move faster?
From my perspective, 99% of the time you spend in product engineering is not actually writing the code. Writing the code is a really, really small piece. Most of the considerations for velocity revolve around operational factors. So I think you need to first ask yourself, is the technology really what's holding me back, or is the process or something else altogether?
I've seen a lot of teams make the mistake of trying to solve operational problems with their front-end development platform. But the problems don’t go away. Maybe you're not communicating effectively, maybe you don't have a good testing strategy, or maybe you don't have a good way of gathering requirements.
It's important to step back and ask, 'What problem am I solving, and what am I optimizing for, is it the technology I’m using or something else?'
It’s also really important to think about the factors that influence developer productivity, which can change depending on team size and project timeline. What works well for a small team with a short-term goal might not scale effectively for a larger team with a longer-term project.
For example, a single developer building for Android, iOS, and web in six months faces very different challenges compared to a team of 60+ engineers managing an app over several years. In my experience, multi-platform solutions tend to be great for smaller teams and quick timelines. Native technology tends to unlock velocity and more optimal workflows over the long haul when you have a longer time horizon and a larger team.
[Donny] Let me give a concrete example related to developer productivity and using the tools in your toolbox. There's a web developer I follow who's been working on a habit and productivity tracking app, which was initially a web app. Over time, he grew frustrated with the mobile web experience and wanted to build a dedicated app. So, he faced a choice: should he learn SwiftUI or Kotlin or stick with React Native, which he already had experience with?
He opted for React Native and was able to build his app in just two days by leveraging the components he had ready to go. From a productivity standpoint, he couldn't have done it any faster without going hybrid.
Whether it's the right long-term choice is a separate question, but productivity wise, React Native gave him a stable, well-performing app quickly. I think this is a great example of where hybrid was truly the right choice for this situation.
[David] I think Donnie is pointing to something we see all the time with our cross-platform, or as we call them, 'hybrid’ clients. Hybrid is going to be great at helping you hit the ground running quickly, especially if you're creating something that uses the RESTful API for CRUD operations and displays it in an interface to users.
Ultimately, you might measure productivity differently at various stages of the process. For example, if you want to build a Flutter app but your team only knows Android or iOS development, you'll need to factor in the time for reskilling, which can take two to four months. That becomes an operational concern because your app can't move forward unless your team learns the necessary skills.
Another consideration is whether you want to use new native technologies six months to a year down the road. You need to ask yourself if you're okay waiting for a plugin to be developed for Flutter or React Native to access the latest features on iOS or Apple. The key is not whether you made the 'right' choice of platform but whether you were able to complete your project productively.
When choosing between hybrid or native, what factors should developers consider?
[Donny] If you're starting from scratch with an idea and some money but no team, and the app you want to build could work perfectly fine as either native or hybrid, you might want to lean towards hybrid. In this case, it can be easier to find developers with expertise in JavaScript, web development, and hybrid frameworks, which means you can get your app up and running across multiple platforms really quickly.
On the other hand, if you already have a team with Swift and Android developers, why ask them to learn something entirely new if they are already React Native experts? If they have mastered their native platforms, it doesn't make sense to have them re-skill for two months with no immediate output. So sticking with native development is likely the best choice in this case.
But if you're greenfield and starting fresh with little money or engineers, hybrid could be a good fit. Again, it depends on your app and technology needs. Take, for example, Digital Rights Management (DRM). If this is an important consideration for you, hybrid will not be the right choice because the DRM support is not there.
[Adam ] I completely agree. I think DRM comes up a lot in this discussion. Take, for example, Netflix, which faced a similar dilemma; there was a strong drive for multi-platform, but ultimately, DRM was the deciding factor, where native capabilities were crucial. In cases like this, it's ultimately up to the business to dictate the platform choice.
However, one thing that’s always important to consider is what you are building for. Are you building to learn, or are you building to last? A company that is just trying to find a product-market fit really rapidly or has a different set of needs than a company like mine that's been around for 170 years. We kind of know what our market is, and we're trying to create a really highly controlled premium experience for people who are paying a lot of money to use it every day. I think the considerations in these situations are obviously very different.
Your team also makes a big difference. If you have the right engineers, particularly these days, you can move really, really fast natively, too, with the advancements in Compose, Swift UI, and Swift itself.
So those are some key questions to ask yourself. While there are plenty of counterexamples, getting close to the metal is crucial if you're aiming for a high level of control in production. You’ll want maximum visibility to optimize effectively, so you will need to minimise the number of abstractions between you and the metal as much as humanly possible.
[Donny] I think it's also important to remember that if you go hybrid, it's not a cheat code to skip understanding the platforms you're developing for, right? You still have to understand iOS, you still have to understand Android in order to build effectively for them.
Do you think developers need to know both native and hybrid to succeed?
[Adam] There are a lot of people who are happy with all of the different technologies out there, but I think the thing that you can't bypass is native expertise. And so, if you're a new engineer who's looking to figure out what to learn first because you really want to build apps in a professional environment, you'll really need to invest in understanding the native toolchains. Having that specialization in at least one of them is really important.
When you're building a team, even a multi-platform team, having that native expertise is really critical. I've seen a lot of companies make the mistake of thinking they have a lot of web engineers, so they don’t need a lot of native engineers. What you end up seeing at the end of the day is teams that are really not able to effectively own the full stack of their applications. And when you're operating at scale, that really, really matters.
[David] It’s true. So if you have JavaScript engineers or all front-end engineers and you ask them to write a backend, they'd still have to learn about the backend. Likewise, if you want them to write a server, they'd have to learn how servers work, how to deal with requests coming in and out, as well as how data is stored. So no hybrid engineer is truly free from learning about native. As Donny said, it's not a cheat code, it's just a new domain to apply some existing knowledge.
What development approach offers better support, native or hybrid? Or do they both offer similar coverage?
[Donny ] I think it depends on what you're looking for in your testing frameworks. But for example, if you want to do UI tests or similar things, Apple, at least from my perspective as an iOS developer, has its XE UI test framework. And obviously, that works best when you also use Swift UI or UI kit. So, in this case, I would say if you want great support, native is probably going to give you more options.
[Adam] I was just going to say that it sort of depends if the app that you're building is kind of common in whatever platform you will naturally get more support. But if you're pushing the boundaries of any platform and trying to do things that are not as common, the tooling support is going to start to fall off a little bit. We have a lot of web view tech in our apps, and I've been on the phone with folks that build the foundational components within the platforms themselves, and they say, look, we've got nothing for you; you're pushing beyond what we're solving for right now.
One thing to track is where the platforms themselves are making investments. So, where are Apple and Google making investments? Google's situation is a little bit more complicated, of course, as they're making multiple investments in different places. But thinking about this question will help you anticipate the level of support you will get moving forward.
Do you see the rise of multiplatform apps threatening the future of native app developers?
[Adam] I don't think so. As a native engineer, you have a ton of underlying value because you understand the ecosystem and the unique concerns of mobile app development.
In my view, the actual languages, tech or frameworks that you are using are kind of irrelevant. If you're an expert in solving mobile app considerations, which are unique everywhere you go, you have a lot to offer. For example, if you're talking to a full-stack engineering organization, mobile is seen as an outlier because it's so hard to mentally grasp all the different factors that you need to take into account.
And so I would say that as any mobile expert, whatever technology you're using, those are very valuable skills. The key is understanding the ecosystem and what a really good native architecture looks like. I don't see the marketplace's demand for native development skills diminishing. They are still really valued.
Is it a security risk to build a hybrid app with so many open-source components?
[Donny] I think it's a very interesting question because, in part, yes, you're pulling in other people's code, so you don't own that code. As a result, you are stuck doing a security assessment on that code, if you have a policy of doing that. Personally, I would go as far as saying I trust that code more than the code I wrote because those open-source projects have so many eyes on them, and they go through security audits from large enterprise companies. And if these large enterprise companies are comfortable using such a component, then I'm sure as hell would be confident that it is secure. After all, if it's good enough for a bank to use, then who am I to judge?
The beauty of importing open source is that you get so much security assessment for free compared to if everything was closed source and you had to do it yourself. But I would add that you still need to make sure your supply chain is correct, everything is set up well on people’s machines, etc. But this is a different argument than whether the components themselves are secure.
[David] The reality is that no security is ever 100% secure; it is just the most secure it can be, so I would agree with the many eyes argument.
How do you feel about the "build once, fix everywhere" trope when it comes to debugging cross-platform implementations that compile to native languages? Does it box you in, requiring a deeper knowledge of native code with less visibility?
[David] Well, would you rather build or fix, you know, I guess that's a question to engineers out there, right. If you feel like you're constantly fixing things everywhere, maybe you’ve chosen the wrong approach. But if you build once and it works well, you’ve made the right choice. That can apply to hybrid apps, but engineers generally prefer working on a roadmap that moves forward, not just firefighting.
[Donny] I think the idea of "build once, run anywhere" is a huge myth. There will always be branches that work on one platform but not the other. A good example might be the "super apps" in Asia, where you see a uniform interface across platforms. That's where hybrid can make sense — build the UI once with a framework, then drop it into native libraries where needed, like for payments.
[Adam] I think something that I would also point out is that I think when people are making these evaluations, they fall in love with the first 90% of product development. And so I think like the first 90% might feel that's where the dopamine hit comes in. You've got all the UI and everything wired up, it feels like you're done, case closed. But in reality, it takes twice as long to get that last 10% over the finish line. And so I think that, like, as you're making those evaluations, don't over-index too much on prototyping. Think about the long haul unless you're just trying to understand your product more by prototyping.
Another consideration is when a team builds a new feature or app with technology they know well. It performs great, but when a new team takes over, unfamiliar with the architecture, you can lose the ability to operate efficiently. So you really need to think through how are my tech and technical decisions going to endure and be resilient across generations of engineers?
[Donny] I've seen the same thing happen with native as well. It’s not exclusive to hybrid. If you let your stack stay the same for too long without moving along with your platforms, you will likely run into this problem.
[Adam] Absolutely. Anytime you diverge from the industry standard, you risk future engineers having to relearn things, even if they’re highly skilled. It’s a challenge, no matter the approach.
.jpg)
