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).
Screenshots of the Text Blast iOS App. Left: Ionic client. Middle and Right: React Native client.
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.
React Native’s development experience for beginners.
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.