Most people assume that all cross-platform frameworks alike, and that the decision to choose one over the other should be based on the stack that you’re most comfortable with. If you’re a React shop, choose React Native; if you’re an Angular shop, choose Ionic (setting aside the fact that Ionic now fully supports building mobile apps with React).
The truth of the matter is, this decision isn’t nearly as simple as one would expect.
In this article, I'll show how Ionic takes a very different approach than the other cross-platform frameworks. To keep it simple, we're going to focus primarily on React Native as the prime example of what we call the Hybrid-Native approach (more on that later). But most of what we cover will apply to Xamarin, Flutter, and NativeScript as well.
In the end, you'll see that not all cross-platform frameworks are alike. And the framework you choose will have profound implications for the future of your project—whether you know it or not.
Let’s break it down a bit, shall we?
Where We Are The Same
Ionic’s goal has always been to give web developers the ability to develop for, and participate on, platforms that haven’t always been accessible to them. For example, do you want to build a native app that can be downloaded from the app stores using web technology? Ionic has your back.
This concept of allowing developers to use technology that they already know, to build apps in the technologies they don’t know, is what all cross-platform frameworks are trying to achieve.
- Ionic allows you to use HTML/CSS/JS to build iOS apps, Android apps, PWAs, desktop apps, or apps for any other platform where the web runs.
- React Native utilizes the JS framework React, but renders native UI elements at runtime, allowing you to build iOS and Android apps.
In that way, we all have the same mission: Use technology X to build for platform Y, where X and Y traditionally aren’t the same.
It’s also important to note that all hybrid app development frameworks, including Ionic, allow access to native device functionality like the camera, biometrics, geolocation, and offline storage.
But, that’s where the similarities end.
Hybrid-Native vs. Hybrid-Web
In order to accomplish the goal of building for a specific platform, each of these technologies has different philosophies to which they adhere. In my opinion, we can divide these beliefs into two major categories: Hybrid-Native and Hybrid-Web.
Native UI, Shared Code
React Native, along with Xamarin and NativeScript, allows you to program your user interfaces (UI) in one language that then orchestrates native UI controls at runtime.
This means that the underlying native UI component that you would like to use, as well as any customizations of that component, must be supported by React Native in order to use that component or change it.
For instance, let’s say you wanted to change the border around a button. If React Native doesn’t open up a customization for that border, you’d be unable to modify it without going directly into the native implementation to manually program it. That doesn’t mean you can’t change the border, it just means it will be harder to do so than expected in some situations.
It also means that, if you dream of a single, shared library of reusable UI components that you can use across all of your digital experiences, the Hybrid-Native model (i.e. React Native, Xamarin, NativeScript, et al) would not be the right approach.
Shared Codebase, Plus Native Code
The amount of code reuse in your React Native project will depend on how much you want to customize your app at the native layer. If you stick with fundamental UI primitives like View, Text, Image, and Touchable then your code will run on each platform, meaning you'll get close to 100% code reuse.
On the other hand, if you have a lot of native customizations, your project will involve three separate codebases: Two to manage your UI for Android and iOS, plus a shared codebase where your controller code will live. In a recent post from the mobile team at Airbnb, they explained how this played out in their project:
“Even though code in React Native features was almost entirely shared across platforms, only a small percentage of our app was React Native… As a result, we wound up supporting code on three platforms instead of two.”
Web UI, Shared Components
Why does this matter? Here are a few reasons...
First, if you’re building a design system and want to enforce UX and brand consistency across apps and digital experiences (e.g. this is the exact button that should be used in all of the apps we build)—there’s only one way to do it: By sharing components across all digital platforms, like mobile, desktop, native, and the web. Additionally, if you want to make sure a component you build for one app can be reused across any project, using web components is, currently, the only way to go.
One of the things Ionic developers often brag about is being able to fully customize every bit of their UI. For example, you have complete and total control over the UI by utilizing the web, which offers a ton of out-of-the-box styling properties. Start with a simple `<div>` tag and turn it into whatever you'd like!
And if you’d like to customize your app's design based on each platform, it’s easier to do so when working in a single codebase with easy-to-use CSS styling on a per-platform basis, which Ionic’s technology provides.
Lastly, perhaps the biggest benefit of building on the web is the stability of the platform. With open web standards supported in all modern browsers, you can be confident that whatever you write today is going to work tomorrow. Other front-end tools are growing and changing all the time, without as much care towards backwards compatibility.
One Codebase, Running Anywhere
With a Hybrid-Web approach, your UI is built with HTML/CSS/JS, with native functionality being accessed through portable APIs (or “plugins”) that abstract the underlying platform dependencies.
Instead of your entire UI depending on the native platform, only certain native device features, like the Camera, are platform-dependent.
This allows your app to run anywhere the web runs: iOS, Android, Browsers, Desktop/Electron, PWAs—the list goes on.
This also means that your UI layer can be shared between all platforms. This is a really important point: Even if you customize the look & feel beyond Ionic’s default platform-specific designs, you’ll never need to split your app into multiple codebases.
On top of that, you also get the benefit of debugging multiple platforms at the same time by utilizing web-based debugging tools, like the Chrome Developer tools, saving you time in the long run. This is actually a huge benefit. We often hear that being able to build the bulk of your app right in the browser is one of the most tangible benefits of building with Ionic.
To sum it up, here are the scenarios where I would recommend the Ionic (“Hybrid-Web”) approach to cross-platform development:
- You’re looking to build an application not just for mobile (iOS and Android), but for desktops and browsers as well.
- You don’t want to have to rewrite your UI for each target platform.
- UI customization and design consistency across all of your target platforms are critical.
- You want to open up the possibilities of your UI to custom components or third-party libraries.
What About Performance?
Now let’s talk about the elephant in the room when it comes to evaluating the Hybrid-Web approach. Proponents of Hybrid-Native will often say: “But what about performance?!”
The truth is, for the vast majority of use cases, hybrid frameworks (both Hybrid-Native and Hybrid-Web) will have similar performance. But the proof is in the pudding. If you want to see how an Ionic app performs, I invite you to check out one of our sample apps and take it for a spin. And remember, “bad code”, even in a native app, can make your app sluggish. So always make sure you’re utilizing best practices when building.
Lastly, if performance is your one and only concern, you might as well go fully native and build directly with iOS and Android toolsets. For performance sensitive applications, staying as close to the metal with Native SDKs will likely be worth the tradeoffs in terms of cost and development time.
So What Does This Mean?
If you’re evaluating Ionic against React Native, or any of the other Hybrid-Native framework, be sure to give careful consideration to the commitment you’re making and the approach it takes.
While both are solid frameworks and will help you build a great app, the choice for your team or organization depends on your overall vision and the ideal functionality for your app(s). Additionally, you must also be sure to evaluate your options based on which factors are important to you, such as design consistency, customization, platform independence, portability, and more.
When you think about the top priorities for choosing a technology to tackle your app development activities, you’ll likely find that one clear winner emerges above the rest for your next project. Remember, the choice has much less to do with which tech stack you’re used to and more to do with how the values of your app align with the approach to build it.
Interested in building a truly cross-platform app? Get started today
P.S. Here’s a cheat sheet that will help you compare options between cross-platform frameworks:
|Examples||iOS and Android SDKs||React Native, Xamarin, NativeScript, Flutter||Ionic|
|Languages||Obj-C, Swift, Java||JS + Custom UI Language / Interpreter||HTML + CSS + JS|
|Code Reuse||Totally Separate Code Bases per Platform||Shared Business Logic with Different UI Codebases||One codebase, UI codebase stays the same|
|Target Platforms||iOS & Android Native Mobile Apps||iOS & Android Native Mobile Apps||iOS, Android, Electron, Mobile and Desktop Browsers as a Progressive Web App, and anywhere else the web runs|
|Investment||Largest investment in staff and time||Medium investment in staff and time||Lowest investment in staff and time|
|UI Elements||Native UI independent to each platform||A selection of Native UI elements for iOS and Android
UI elements are specific to the target platform and not shared
Custom UI elements begin to require split UI code bases
|Web UI elements that are shared across any platform, conforming to the native look & feel of wherever they are deployed
Easily use completely custom UI elements
|API Access / Native Features||Separate Native API & Codebases for each App||Abstracted Single-Codebase Native Access through Plugins (with ability to write custom Plugins)||Abstracted Single-Codebase Native Access through Plugins (with ability to write custom Plugins)|
|Performance||“Native Performance” with well written code.||Indistinguishable difference on modern devices with well written code. See above.||Indistinguishable difference on modern devices with well written code. See above.|