Ionic vs React Native — Text Blast Case Study
TL;DR We present a direct comparison of analogous open source Ionic and React Native clients for Text Blast, discussing their differences in terms of development experience and resulting app quality. We come to the conclusion that React Native’s superior perf and user experience made it the right choice for Text Blast, but that most developers weighing the same decision will likely opt for Ionic until the platform and community surrounding React Native matures.
Ionic and React Native are two of the hottest options for cross-platform mobile app development and for good reason. While there are many articles out there which describe how to create cross-platform mobile apps or which discuss the pros and cons of cross-platform vs native mobile app development, there are very few case studies of non-trivial, open-source apps implemented in both technologies. Towards that end, the purpose of this article is to take a real-world app and implement it with both technologies while also presenting a direct, side-by-side comparison between the two in terms of analogous source code, development experience, and resulting app quality.
The app we chose for this case study is Text Blast, which lets you bombard your friends with packs of themed GIF text messages. It strikes a nice functional balance between being simple enough to understand while still being a full-fledged app deployed in production (e.g., not another TODO list demo). And as an added bonus, you get to annoy your friends while testing it out… 😜
The React Native version of Text Blast is available publicly on the iOS App Store (link, source), whereas the Ionic version is available via Ionic View (link, source). For reference, an accompanying MEAN webapp is also available (link, source). Read on to see why we chose to publish the React Native version over the Ionic version and note that this result does not necessarily reflect our general advice to other developers choosing between these options. Also note that the webapp provides the shared backend between all 3 clients (react-native, ionic, and web/angular).
The ease and quality of the development experience is a very important factor in determining which technology to use for your next mobile app, regardless of whether you’re building a side app for fun or a serious app with business implications. Here we compare our development experience using Ionic and React Native in terms of documentation, platform, and their community support.
Both the Ionic and React Native versions of Text Blast took approximately the same amount of time to complete.
Ionic’s framework docs are clear, consistent, and oftentimes even beautiful. From API docs to example apps, Ionic’s done a wonderful job at ensuring a consistent understanding of platform components and how to find help in the rare instances where the built-in documentation doesn’t suffice. The one exception is their newer Ionic Platform PaaS offerings for push notifications, analytics, user tracking, and over-the-air deployments. Although optional, these services have seen a lot of churn since ionic.io was first released and it is very easy to run into deprecated examples online.
React Native has reasonable auto-generated API docs for built-in components, a decent official intro tutorial, a lot of community hype, and the backing of Facebook, so we naturally expected the development experience to be relatively straightforward.
Once we started trying to build anything non-trivial, however, the reality of React Native’s platform immaturity hit us very fast. The number of times our relatively simple app required us to investigate the react-native source itself when the API docs were insufficient was disconcerting, and this matter was only made worse with respect to third-party React Native modules from js.coach (formerly react.parts).
One of the most glaring discrepancies that both React and React Native suffer from is their frustratingly inconsistent use of ES5 and ES6 both in internal documentation, example project templates, and in tutorials across the web. As Cory House mentioned, this leads to a lot of confusion for newcomers, whereas we would’ve greatly preferred a consistent, opinionated use of ES6 throughout. The split use of ES5 and ES6 for React is more understandable because it is meant as a small component in the much larger ecosystem of web dev, inheriting all its legacy compatibility implications, but React Native has the opportunity to distance itself from this mess with babel support built-in and move forward as a cleaner, more consistent platform.
One saving grace of React Native’s documentation is that it is easily editable on github, so it will hopefully benefit from increasing community support, but for now we were very disappointed with React Native as a cohesive, well-documented platform. IMHO this is an artifact of Facebook’s investment in the core React Native technology which has direct utility internal to Facebook’s bottom dollar as opposed to treating it with the proper resources of a grander platform play. (more on this below)
Ionic’s documentation is significantly more mature and consistent than React Native’s.
Ionic apps are structured as Angular apps exposed inside of a custom Cordova webview. Ionic’s decision to use Angular meant it was very easy for us as web developers to pick up and start being productive. Since Ionic apps are really embedded webapps, we could use most of our prior HTML, CSS, and JS knowledge without having to learn any new technologies aside from Ionic’s user-friendly CLI.
React Native is much more powerful at the cost of requiring less structure. This can be both a blessing and a curse, in that it allows for much more advanced use cases such as interoperability with existing native codebases (as Facebook does internally), but for beginners starting out with React Native the added flexibility hinders understanding. Web devs familiar with React will feel very comfortable using React Native components, and we personally found JSX to be a pleasure to use in comparison with the more traditional Angular approach of strict separation between markup, style, and logic.
Both Ionic and React Native come bundled with CLI programs that make starting new projects with sensible boilerplate very easy. Both also embed native iOS and Android projects that can be edited directly if needed.
Both technologies allow native interoperability, Ionic through Cordova plugins, and React Native through React Native modules. React Native’s native interoperability approach is inherently more powerful, though in practice, the number and quality of third-party native modules is much lower for React Native than for Ionic. Ionic’s ngCordova, for instance, is a collection of high quality Cordova plugins with Ionic Angular wrappers to make integration a breeze. React Native’s closest comparable resource is js.coach (used to be react.parts), which hosts a subset of NPM modules specific to React and React Native. While developing Text Blast, we found this resource to be an absolute necessity, though we were often frustrated with the lack of quality options available. We would love to see Facebook lend an official hand in the development and curation of non-core React Native modules as Ionic has done with ngCordova.
Ionic and React Native take very different platform approaches, with Ionic being easier at first and React Native allowing more advanced use cases.
Ionic’s developer forum is one of the most polished, active, and useful dev resources I’ve ever seen. It is clear that Ionic has put a lot of thought and effort into helping their developers when issues arise.
React Native benefits partially from React’s popularity, as we ran into several questions which were solved by React-specific StackOverflow posts, but not anymore than Ionic benefitting from Angular’s popularity. In general, the community of fellow developers and resources available for React Native paled in comparison to Ionic, though React Native’s relative growth rate compared with Ionic is harder to judge.
Comparing Ionic and React Native on Google Trends over the past year yielded expected results, with Ionic holding a firm lead having the benefit of existing mindshare, but overall interest in both platforms is rising steadily. We found it interesting that a similar Google Trends search comparing Angular with React yielded a practically identical pattern indicating a tight correlation between the popularity of Angular / React and Ionic / React Native.
Another important point to mention is that both Ionic and React Native have embraced an open source development model and are respectively two of the most starred projects on github. React Native, in particular, has seen astonishing growth in the variety of open source contributions, whereas Ionic’s open source development has revolved more around public issue tracking and development transparency. It is also interesting that Ionic’s open source nature has led to a competing spinoff company, Appery, which forked Ionic to be more React Native-esque, which begs the question of whether or not a middle of the road approach would be better in the long run.
Both Ionic and React Native have embraced open source with very active communities, though Ionic still has a clear advantage in overall resources having been around longer.
One of the most important factors driving technological decisions should be the quality of the resulting user experience. Other factors including the development experience, available resources, cost to build and maintain, etc. are oftentimes necessary constraints, but at the end of the day if you don’t build a solid user experience, it’ll be difficult to attract and retain users. And while a good understanding of UX and design goes a long way towards this end, it is oftentimes the technological tradeoffs that impact usability most visibly, especially within the landscape of cross-platform mobile development. In this section, we compare the quality of the Ionic and React Native versions of Text Blast with respect to performance and platform UX consistency.
Both Cordova and Ionic have made great strides in performance, though they will always be fundamentally slower than React Native’s non-webview-based approach. There are some areas, however, where Ionic outperforms React Native such as with specialized support for infinite scrolling lists. Ionic provides builtin support for performant, clipped infinite lists via the collection-repeat directive (explanation), which operates similarly to a native UITableView. React Native currently doesn’t provide any official support for large or infinite lists (link), and while it is possible to support them within a React Native app, it requires the developer to create a custom native component wrapping a UITableView which more or less mitigates the advantage of working with React Native in the first place.
Text Blast is, however, a fairly simple app, and its only real performance test comes from the large number of animated GIFs that are displayed throughout. We found the Ionic client to lag quite unusably while loading and displaying so many GIFs, whereas the React Native client handled the decoding load gracefully for the most part. Even in the React Native client, however, we found that loading 10+ GIFs at once could temporarily make the scrolling UI unresponsive, which is a problem we could easily work around if we working natively.
Note that the overall size difference of the release distribution IPAs for iOS was negligible, with the React Native app weighing in at 6.3MB and the Ionic version weighing in at 7.6MB.
React Native’s performance was noticeably more usable and native-feeling than Ionic’s.
One important area which wasn’t obvious when first evaluating the two platforms is what we’ll refer to as UX consistency, that is how easy is it to make an app’s common components (tab bars, navigation bars, transitions, etc.) look and feel like their native counterparts.
Ionic has spent a lot of time and effort creating a set of cohesive components that allow web developers to use normal, Angular directives and have the results look exactly like their native counterparts, even though their perf doesn’t always feel as polished. That being said, it was much, much easier with Ionic than React Native to use the builtin components without customizing their styles and have them match the expected native styling, especially when you consider that the same components can be used on iOS and Android with the abstraction automatically and opaquely handling the stylistic and functional differences between the two platforms.
The majority of React Native’s builtin components come devoid of any default styling, which on the one hand means they are more extensible than their Ionic counterparts, but on the other, more practical hand, means that the lack of default styles requires you to manually match the preferred platform style every time you use a component, a process which is both tedious and error prone.
This distinction between Ionic and React Native is another great example of how React Native is really more analogous to Cordova as the base technology and is missing a cohesive, developer-friendly wrapper ala Ionic on top.
Ionic makes it much easier to achieve UX consistency with native platform components than React Native.
We’ve discussed our experience while building Text Blast side-by-side with Ionic and React Native, delving into the development experience and resulting app quality. As we’ve seen, Ionic’s documentation and platform maturity make it a breeze to work with compared with React Native’s relatively poor documentation and unstructured community efforts. That being said, we were surprised by how much we enjoyed working with React Native despite its lack of maturity and look forward to seeing it improve in the future. We hope that Facebook will begin looking at it more as a platform play to woo developers as opposed to the current technology play which bets more on it as an internal resource useful to Facebook’s bottom dollar.
From the perspective of app quality, the React Native app was significantly more fluid and native-feeling than the Ionic version especially with respect to decoding and displaying dozens of GIFs, and for the purposes of Text Blast, we found this to be the single most important deciding factor when choosing which version to release live to the app store.
Most developers, however, will not have the resources or inclination to write two versions of the same app. While we chose the React Native version of Text Blast over the Ionic version mainly for perf reasons, we believe Ionic to be a better fit at the moment for most use cases because of its superior documentation, consistency, and overall platform maturity. It is our hope that the in-depth comparison provided in this article will help other developers weigh these trade-offs with respect to their own use cases and choose the right technology up front instead of running into unexpected issues after the fact.
Cordova : Ionic :: React Native : ???
The biggest takeaway from this exercise has been realizing that React Native is really more comparable as a base technology ala Cordova than comparing it with Ionic as a cohesive platform built upon that technology. From Facebook’s perspective, React Native is a useful technology that can help streamline its business objectives by cutting down development resources, and they continue to invest in optimizing the core technology to further that primary use case. Open sourcing React Native was a clever move on their part to get developer sentiment on their side and improve the technology with free dev resources faster than they could on their own, but as far as we can tell, they have not surfaced any grander plans to grow React Native into the development platform that we believe it would be so well suited for.
This brings us to the market opportunity: could Facebook or a startup build a cohesive set of components, quality documentation, and developer resources on top of React Native in the same way Ionic has done on top of Cordova in order to fulfill React Native’s promise of allowing developers to build native-quality cross-platform mobile apps?
We’re afraid Facebook has shown a distinct lack of desire to enter the developer platform market with its recent shutdown of MBaaS Parse.com and continues to develop React Native mainly with an eye towards internal use as opposed to general developer use as a platform. We’d love to hear from Facebook regarding their thoughts on the missing piece from this analogy.