This used to be the big debate in app development. The simplicity of hybrid versus the performance of native apps. For a long time we were on the side of native apps because whenever we tried a new hybrid platform we were very underwhelmed by the performance, security, inability to use native app features (like geolocation, push notifications etc.) and the risk the app stores wouldn’t approve them. But over the years, especially with the release of React and then Flutter frameworks and the app operating systems recognising the benefits of hybrid development and opening up features to it, the dial has clearly shifted in favour of hybrid apart from some specific use cases (discussed below). The blurring of the lines between websites, web apps and “proper apps” has also increased the appeal of having one code base for all front ends.
Native code (in terms of app development) means the app is built in the same language as the phone's operating system. So for Apple (iOS) this is Swift and Android this is Java/ Kotlin.
OK, but what does that mean?
Because the app and the phone are speaking the same language, they work better together. This is particularly the case when the app is interacting with the phone’s own hardware such as the accelerometer or augmented reality kits. There is no delay for translation (lag), chance for misunderstanding (instability) or mistranslation (security flaws). And when a new version of the operating system is released (e.g. iOS12) there are not normally any compatibility issues.
Sounds good. What's the catch?
Because the iOS (Apple) and Android apps are built in totally different languages, the code needs to be built, tested and maintained twice.
Do we build native apps?
Absolutely. Native is where we started and sometimes we have no alternatives, for example if we have to use an native SDK or part of the phone’s hardware only native apps can use. But because hybrid platforms such as Flutter are so good now, we use them where possible.
What is hybrid or cross-platform development?
The idea is great. Rather than developing two (Apple and Android) or even three (website as well) hybrid code works across multiple platforms. One code base to build, test and maintain. A no-brainer, right?
But why then doesn't everyone use it?
Actually, increasingly everyone does use one of the two main hybrid languages – Flutter and React. In the past we, and other developers, didn’t because hybrid apps are not written in the phone's own language and this led to performance, security and stability issues. Also, sometimes new native device hardware features can't be access by hybrid apps and new operating system releases can require updates to the hybrid code as well. But these issues have nearly all been overcome and the advantage of hybrid development makes it the approach we nearly always take.
Which is the best?
Hybrid platforms vary a lot and their popularity changes over time. Some are better for things like data collection or integration with backend platforms that have already been built. Our favourite is Flutter because it performs natively, is supported by Google, has widespread adoption (so documentations and SDKs are typically available). And also because we love a low code platform called FlutterFlow that allows us to build beautiful apps and web apps from scratch quickly and cost-effectively.
When is hybrid not the right option?
Nowadays we think Flutter nearly always is the right answer but in our conversations with clients we’ll look out for any reasons why it might not be. This might be that the app needs to integrate with an existing SDK that’s only available in native languages (although we can sometimes also build a “translation layer” to allow for the rest of the app to be native) or sometimes the phone manufacturers, especially Apple, only allow native apps to access some advanced hardware features initially. As an example, the new Apple Vision Pro Headset currently allow apps built in native code XCode.
But worry not. It is our job to listen to our clients and advise them of the right approach for their app.
.webp)
.svg){kind=small}