Hi there, I'm Eric Horodyski, the newest Solutions Architect here at Ionic. Before joining the team here, the previous five years of my professional career was spent as a Lead Developer building dozens of hybrid mobile applications, some in React Native, the others in Ionic.
The interest in hybrid mobile development continued to grow within my professional circle throughout my years working as a Lead Developer. Some people saw it as an affordable way for their organization to enter the mobile space, others saw it as a way to consolidate existing codebases. Whatever the reason be, my involvement started when this question came about: “Should we pick Ionic or React Native?”
It’s an important question - time and money are going to be invested in this decision. Arguably as important, this decision sets the direction for development teams. What’s unfortunate is that material written for that question is, in my opinion, of poor quality. After researching this topic thoroughly, I find that most articles will pit React Native and Ionic against each other in cagematch fashion: two frameworks enter, one framework leaves.
Sticking with fighting metaphors, these articles provide a tale-of-the-tape; comparing differences like GitHub stars and framerate. I’ve yet to read an article comparing frameworks on client requirements, project complexity, and organizational needs; factors that carry far more weight than hitting 60 frames-per-second.
The honest truth is that both Ionic and React Native enable developers to build beautiful, performant mobile apps, which made it a very difficult choice to have to make as a Lead Developer. I can’t give you a “one-size-fits-all” answer here -- if that’s what you were looking for with this article you can bail and I’ll understand. I can provide insight into lessons learned and experience gained leading projects in both projects that I wish I had known the first time I had to make that decision.
Misconceptions
Honestly speaking, I haven’t read a comparison article that doesn’t position React Native as the better framework; it leverages actual native components so performance is better, and it creates standard native projects so you can more easily mix-and-match JavaScript and native code together.
During my first year or so developing hybrid mobile apps, I strictly used Ionic and Cordova. I was excited to dig into React Native when the time came, but quickly realized that the comparison pieces were a bit misleading.
Performance is Framework Agnostic
Some framework comparison articles come with benchmarks that showcase React Native as the more performant platform. While this may be true in theory, that doesn’t mean it always applies in practice. Throw in some complexity and sprinkle in poorly written code, and you can easily build a poorly performant React Native project that is slower than an Ionic project.
Case-in-point, I worked on two projects (one in each framework) that coincidentally had a similar requirement: guide the user through a multi-step form submission process. The React Native project had a notable 0.2 second lag as it loaded each step. On the other hand, the Ionic project had lightning fast navigation even though it was the more complex implementation.
A bit of debugging showed that the libraries we used for navigation with React Native were the cause - they just weren’t as performant as Angular’s router.
Bridging Native Code is Eerily Similar
Comparison pieces led me to believe that the process to bridge native code into React Native was a superior experience, and that it would be easier to bring on native mobile developers to a React Native project than an Ionic project.
As it turns out, the process is basically the same with both frameworks. There’s a standard interface to apply your native code to, used to expose native functions to your JavaScript project. Configuration changes are made to the project and app startup logic.
Throwing Capacitor into the mix -- which adds native projects as source artifacts -- you can bridge native code into your Ionic app the exact same way you would as React Native, whether you plan to build a plugin for the community or keep your native code local to source control.
Design
As a Lead Developer, one of your core responsibilities is to estimate the time and effort required to design your application. Your estimations boil down to cost, so it’s extremely important to know the core differences between designing and styling Ionic compared to React Native.
Most importantly, React Native components will render their native equivalents with no pre-fabricated styling options to choose from. If your project is intended to match native platform styling as close as possible, there’s a huge benefit in using React Native. Ionic ships with Adaptive Styling, where every Ionic component adapts its look to the platform on which the app is running on. However, some Ionic components, such as the datepicker, don’t quite exactly match their native counterparts.
On the flipside, if your project has a design system to adhere to and/or should look consistent between platforms, in my experience Ionic has taken considerably less time to standardize designs between platforms.
It’s also important to note that React Native integrates a subset of CSS. On the surface, working with a subset of CSS appeared inconsequential, but I quickly found it challenging to accurately scope the effort and feasibility of particular designs. Responsive design paradigms, such as media queries, aren’t readily available in React Native. This led to a particularly stressful experience working with a design team that had only designed for web-based hybrid apps -- it was difficult for them to grasp how much additional effort it would take to accommodate all the device sizes they were targeting.
Recently, accessibility (a design process in which the needs of people with disabilities are specifically considered) has become an important aspect of mobile design. The mobile development community has seen a surge in lawsuits filed for inaccessible apps. It’s unfortunate that there is no mobile equivalent of the web content accessibility guidelines (WCAG) which provides clear and defined rules to meet accessibility compliance requirements.
Thankfully, both React Native and Ionic set you up for accessibility success. Since Ionic is web based, you can adhere to WCAG guidelines. React Native has a robust accessibility API (which is one of my favorite pieces of the framework) but without any standardized set of accessibility compliance requirements for mobile I’ve found myself working with folks from legal departments explaining that some guidelines implemented in an Ionic app weren’t applicable for React Native.
Native Integration
When it comes to integrating native capabilities, both React Native and Ionic both have fairly straightforward processes -- provided you are using Capacitor to build your hybrid app. Both React Native and Capacitor follow the same process:
- Write native code that implements a specific interface.
- Write JavaScript code that calls hooks to your native code.
However, Capacitor is a relatively new native bridge that Ionic can leverage. For the majority of my tenure as a Lead Developer, Apache Cordova was the only native bridge option available.
I’ve always found it difficult to incorporate custom native code into the Cordova apps I’ve led. Native code used by a Cordova application must be installed as a plugin; a standalone project. This would mean that my teams were no longer just focused on building one project for an app, additional projects were created to build Cordova plugins as well. Typically, this meant we would go weeks without testing how custom native code being built would interact with the actual app being built.
Capacitor and React Native utilize platform projects as source artifacts, simplifying the process to bridge native code into your app, and yes, allowing you to test your custom native code within the same project as your app. I consider this an important takeaway, as most comparison articles don’t make mention of Capacitor.
Some mobile applications are built to enhance particular native integrations, such as Snapchat, which has its experience built around (or rather, on top) of the device’s camera. I led a project that had a Snapchat-esque experience which was pretty trivial to build in React Native. Using the device camera as the background of my application was as simple as adding a community plugin that provided a React Native component to my pool of existing components, alongside buttons and input fields. Admittedly, I haven’t had to build this type of experience with Ionic -- neither with Capacitor nor Cordova -- so I can’t comment on how difficult this would be in comparison. However, I am aware of one community approach where a “hole is punched” through the WebView hosting your app, exposing an underlying native control (such as a map) - which sounds like a larger undertaking for your typical hybrid developer.
Most importantly though, both Ionic and React Native die by community support. An unfortunate trend that I’ve encountered throughout my experience is that when it comes to native integration, most hybrid development teams rely on open-source communities to provide plug-and-play solutions. Both communities are active and healthy -- but that doesn’t mean that community solutions aren’t abandoned after projects have become deeply intertwined with them.
Luckily, both React Native and Ionic have solutions to this problem. Expo, a company outside of the core React Native team, provides an API including a healthy offering of native integrations. Ionic supports and maintains Capacitor in addition to the Ionic Framework, in addition to offering enterprise plugins and solutions for both Capacitor and Cordova backed with support, advisory services, and SLAs.
Wrapping Up
I love both Ionic and React Native, and thoroughly enjoyed working with both as a Lead Developer. There’s definitely enough room in the hybrid mobile ecosystem for both. Competition drives innovation -- which ultimately winds up benefiting developers as a whole. Capacitor is a great example, providing Ionic developers with tooling on par with React Native and solving a lot of the pain points felt working with Cordova.
As it turns out, a lot of my decision making on when to use React Native or Ionic came down to primarily non-technical drivers. If I had to boil down five years of working back-and-forth between the two frameworks and provide a “cheat sheet”, it would look something like this:
- Are you building an experience that heavily relies on augmenting the design of native features, a la Snapchat? I’d go React Native.
- Have you been given a complex design that should match across platforms? Ionic.
- Are you looking to test the waters of a particular market or business capability to see if users will bite? I’d suggest Ionic since it’s prefabricated design lends itself to a faster time-to-market, but both frameworks excel for this use-case.
Ultimately though, try both out. Don’t go by the assumption that one framework is better than the other. With a few POC projects under your belt, you’ll quickly be able to determine which framework works best for your project, your developers, and your business.
Oldest comments (1)
Great article! Nice to get feedback from someone who has been on both sides of the fence, as it were. I'm constantly having to make similar decisions, and while I've had solid Ionic experience, I tended to lean on that mainly because of my ignorance of the details under pinning React Native. My decision process was simpler: mobile = Ionic, web = React (or Angular). Now I have some more homework to do.