Native or Hybrid Apps – Our advice to clients
A common doubt clients have is whether to develop their mobile apps natively or through a hybrid framework, like Ionic, Xamarin or React Native. We focus only on building native Android apps. But we try our best to help with this decision, even if it means losing a project. In this article we explain our thought process.
First some background. Since iOS and Android became popular, many hybrid frameworks appeared. They pick a popular non-native technology and create a framework to build mobile apps with it. The goal is to build an app once and have it running on all platforms with as few specific changes as possible. There is Ionic, PhoneGap and React Native based on web technologies (HTML, CSS and Javascript), Ruby Motion based on Ruby, Xamarin based on Microsoft’s C# and Flutter based on Dart.
Hybrid frameworks are attractive to companies because they can apply existing knowledge into mobile apps. And with a single codebase, there's potential to save time and effort. But they are aware of the risks of depending on third-party abstractions.
Here are the factors for and against building apps with hybrid frameworks. You should weigh them on the specificities of the app you're building.
For Hybrid Frameworks
Complex mobile back-end
Non-UI related code is similar between platforms. So if the back-end logic is the biggest component of an app, a hybrid framework should save time. What kind of apps have complex back-ends? Apps that read and write data offline and have complex business logic that can't be delegated to the server.
Proof of concept that requires multi-platform
When building an MVP, you want to keep development expenses low and you need to iterate to get it right. If a product is not validated, we recommend starting out with a single platform. The goal should be to have a great app that does one single thing very well, not 3 features hacked together.
However, if for some reason the proof-of-concept requires multiple platforms, it's faster and cheaper to iterate with a hybrid framework. Just don’t forget, to re-evaluate your decision after your MVP is validated.
Against Hybrid Frameworks
Complex native-feeling UI
If the front-end is complex and the UI should look and feel native (and most should), a hybrid framework will drag you down. Even if you can write platform specific code, abstractions make problems likelier.
Deep hardware integrations
Again, like for the UI, abstractions are the culprit. You won’t have issues getting a photo from the camera or the current user location. But for deep integrations with hardware features (camera, sensors, GPS, NFC, Wifi, ...), you'll need platform specific code and run into problems more frequently.
Latest OS features
If you want to be the first integrating with the latest Android and iOS features, a hybrid framework slows you down. And you won’t be able to predict the delay until it gets supported.
Current patterns
We notice that B2B products lean towards hybrid frameworks, while B2C products lean towards native. But B2B companies that want to step themselves apart on their UI/UX quality, also lean towards Native frameworks.
Disclaimers
Note 1
Some hybrid frameworks handle the shortcomings mentioned above better than others. But in general, the advice holds.
Note 2
Team experience trumps all. An experienced team with any tech should outperform a less experienced team, even with a more adequate technology. This article is for someone building a team or outsourcing the development of a new product. If you already have a team comfortable with a technology, using that technology should get better results than picking something new.
Note 3
Careful on taking tech advice from big companies. With a big enough team you can and likely will write components from scratch. But small teams implementing MVPs don’t have access to the same resources. Take that in mind when reading advice from companies like Google, Facebook, Twitter, Airbnb...