How We Choose Hybrid Mobile Technologies

This article is designed to guide you to make a decision — it's not a comparison of different hybrid technologies that exist, nor is it advocating hybrid over native or native over hybrid. By the end of this article, you'll have some idea of how to make the right choice for your business.

What does "hybrid" mean?

When talking about hybrid, you may have also heard cross-platform. A "platform" can be described as a place you run code (iOS, Android, WatchOS, iPadOS, etc.). Hybrid mobile frameworks are designed so that you write in one common language and run it on more than one platform. Some popular examples as of 2021 are:

• Xamarin
• MAUI (Related to Xamarin, coming soon from Microsoft)
• React Native
• Flutter

There are TONS of other ones (this is by no means a comprehensive list), but it should at least give you an idea of what we're talking about.

What does "native" mean?

Native means writing in the languages and frameworks that come with the platform. For example on Android this means using the Android Software Development Kits and a JVM language, likely Kotlin, with older apps using Java. On iOS this means using the iOS Software Development Kits and Swift with older apps using Objective-C. These languages, frameworks and SDKs are supported directly by Google for Android and Apple for iOS meaning they're the most up-to-date and relevant options for developing an app on their respective platforms.

Native or hybrid?

Let's start this with a series of "early exits" or quick decisions that can point you to native vs. hybrid:

• If your app is only going to be released on 1 app store consider just using native. Future-proofing is not recommended given the fast pace of hybrid technologies.
• If your app needs to be incredibly up-to-date you should choose native (for example, if you want to work on features before they're released so that you're one of the first companies doing an exciting new thing).
• If your app needs to feel exactly like an iOS app for iOS and an Android app for Android, you should really choose native.
• If your app needs to communicate with platform-specific peripherals, consider using native. For example, as of the time of writing, app clips and watchOS are not supported on most cross-platform frameworks. If you rely heavily on these peripherals, it is an indicator you should choose native development.

Hybrid frameworks as a general rule don't have some magical UI component that makes an app look exactly like an iOS app on iOS and exactly like an Android app on Android. A good example of this is Flutter — there are Material Design widgets and there are "Cupertino" widgets. They're separate entities and generally, you want to avoid writing a whole branch of code that uses Cupertino widgets for iOS and Material widgets for Android, or you'll just end up using one really big codebase to write two different apps. Let's look at other considerations to help us make this choice.

What code should be shared between platforms?

The industry hasn't quite come to a solid conclusion on this question. Do we share UI code? Is that what is important? Well, the downside of sharing UI code is that it doesn't "look" or "feel" exactly like a native app does. Maybe that's okay, a lot of hybrid apps end up with their own design system that isn't strictly material nor is it strictly following Apple's common design language. That design system is a non-trivial amount of work though, so if you don't have one, you'll need to spend time creating one.

Instead, we could share the business logic, and reduce code duplication costs in that way. Well, maybe. To a large extent, that's what APIs are about, in large systems we tend to prefer mobile applications do very little and instead delegate to something else to handle the business logic, that way the business logic can be the same in multiple clients. If you're looking to share other details though, like your networking layer and/or your data models there may be other solutions. Kotlin Multiplatform is an interesting option if your goal is to share this logic, although it does come with some interoperability trade-offs.

To sum up. If you share the UI layer you will sacrifice a totally "native" feel, and be aware that sharing UI is a complex thing to do. Alternatively, there's some potential to share your logic layers, but ask yourself how much implementation drift between platforms you have already seen. We find that on most teams this isn't what gets "out of sync" between platforms.

It is NOT about speed of development

Hybrid technology is really cool and it has some promise; it's still cutting edge tech and companies are excited about it. Don't be sold by the pitch that it's somehow about the speed of development. The math says you'll actually run a development team a little bit slower because of random one-off issues. Android did something unexpected, Apple rejected us for something we thought should be valid, etc... Now those one-offs happen to native teams too, but if you assume a somewhat even distribution of Android-specific problems and Apple-specific problems a hybrid team has to deal with all of it and will run a little slower.

What it does do is save you on the cost of development in the short term. You can spin up a smaller hybrid team and get the same output with a 10% overhead or you can spin up 2 teams, one for iOS and one for Android that doesn't have that same overhead. 2 teams cost more money, and depending on what you're building and what your business needs are that may be a limiting factor.

Staffing plays a huge role

Make no mistake, whatever your choice is there's a short-term and a long-term cost. The short-term cost we alluded to, fewer developers have to work on a hybrid app. That being said the decision is surprisingly not so much technology-related as it is staffing-related. What happens after the app is built? Who maintains it? Well if your company already has lots of React developers then there's something to be said for using React Native (NOTE: React and React Native are not the same thing). If your company has tons of C# developers then there's something to be said for Xamarin, or MAUI.

Some hybrid technologies, like Flutter, are really exciting to developers because of their speed and hot reloading capabilities. However Flutter uses Dart as its language, do you have a lot of Dart developers ready to maintain it? Are you willing to train some? We've found that Flutter has a lower barrier-to-entry than some of these others if you've got a random pool of developers with varied skillsets.

Can I take my native team and turn them hybrid?

You can, but you probably shouldn't. Airbnb wrote a great article describing what happened when they did exactly that. It's from 2018 but absolutely worth a read. On top of that, you'll find that native developers really enjoy working in their respective stacks. Pushing them to something that requires them to learn a completely new language could end up costing you dearly.

We've also found that different technologies favor different developer backgrounds. For example, we saw that react developers were able to get up-to-speed faster on react native than Apple developers trying to do the same.

Which flavor of hybrid?

This is a constantly moving target. Some hybrid frameworks allow you to interop with native code. This seems like an ideal situation because if there's something hybrid isn't doing right you can still write native code. Some do not offer that, and so you'll be stuck with whatever the hybrid framework supports.

Speaking of support what about long-term support? What company/community is backing the hybrid tech you're interested in? Will they update it quickly when new features come out you want? Will they support your teams if they get stuck? Will they respond to bug reports? Will they change their direction so rapidly that long-term support is out of the question? Will Apple reject them from the store?

All of these are important factors to consider and should guide your decision about what technology to choose.

Performance

If you care about high performance you'll probably want to exclude Javascript-based technologies. Flutter and Native both shine here. Xamarin benchmarks do show a user-noticeable performance hit. Note that it's rare to really need high performance but if you were building something like video rendering software you probably want to go Native for that.

What about the web?

So some hybrid technologies, like Flutter are also trying to have the same code run on many more platforms than just iOS and Android. There's also always the possibility of using Progressive Web Apps. This still boils down to the same kinds of decision criteria with an extra twist.

Every once in a while your app really doesn't do much other than show slow-moving web content. If that's the case Apple really doesn't want a native app for that. Their guidelines pretty clearly state that a mobile app should not just be a web wrapper. Progressive Web Apps are a really interesting idea if you find yourself in that category. The drawbacks are mostly about which app store you can be shown in. At the time of writing Apple does not allow PWAs in the Apple App Store, however, your users can download your PWA straight from your website. On the surface, you might feel like that's unacceptable but ask yourself how much organic traffic you really get from the Apple AppStore. PWA's might be the right choice for you.

To sum it up

The decision to go with a hybrid or native technology is complicated. Staffing plays a huge role, so do long-term support plans and the specific user experience you want. There's a place in the industry for all these technologies. Take your time in coming to a decision, it tends to be pretty costly to change your mind afterward, depending on the technology chosen it can require a full rewrite. 

Use the below flowchart to help guide you to technologies that might be a good choice for you.

For more guidance on your specific needs reach out to WWT today. We have experience working in a large variety of technologies and can work with you to find the right fit for your business.