React Native: It’s not all sugar and spice
At Add Jam we’ve been using React Native more and more, to the extent we haven’t actually had a fully native project at all this year. Any why not? It makes total sense – share code between Android and iOS, less Xcode/Android Studio, live reloading in development etc etc. But in React Native land it’s not all sugar and spice and all things nice.
Break neck speed
Let’s take LoL 2048 for iOS. We used that as a small experiment to try out React Native with iAP and using ad networks. We launched it at the end of January this year and used version 0.17 of React Native. Here we are in June, just over 4 months later, and React Native just hit 0.27. In that time there’s been some phenomenal improvements and React Native is always improving — a real benefit of such a rapid release cycle.
Let’s compare that with iOS. This week we we had the awesome announcements from WWDC and iOS 10 is jam packed with new features and abilities but it won’t be launched for another 3 months at least. As far as public releases go we’ve went from 9.2.x in January to 9.3.x currently available in June. One major platform change in that time and even then 9.3 was in developer and public beta for 3 months. Compared to React Native, iOS has such a stable and predictable release cycle. As developers it’s easy to plan around and keep up to date with the latest changes and for our clients it’s easier to keep their code base on the latest version, well maintained and most importantly secure.
It’s tricky, the rapid pace is constantly bringing improvements but with that there’s instability. I feel a solution could be in what the Ember community is doing. The latest release of Ember is LTS (Long Term Support). This means the release will receive critical bug fixes for the next 6 release cycles (until roughly November 2016) and security patches for the next 10 release cycles (until roughly April 2017). This means Ember still has the fast fortnightly release cycles but introduces a bit of stability that’s currently lacking with React Native.
It’s the Wild West
With each framework or platform we develop with we need to adapt to the conventions. From back end work using frameworks like Rails and Phoenix to native mobile projects each has it’s own way to hang together a project. With React Native there’s no ‘right way’ to structure projects. There’s no standard pattern.
Having a standard layout and well established conventions help getting started with a new framework and gives a head start with new projects. But the real value is in sharing code, maintaining projects and on boarding new members to a project team.
We’ve spent a long time viewing projects on GitHub and picking and choosing what we feel is the best way a project should be structured. A subject for a future post.
Jumping all over the place
When you develop a fully native app you do it pretty much in one place. On iOS you’re in Xcode, for Android you’re in Android Studio. With React Native you have a terminal (with a couple of panes), a text editor, perhaps Redux Remote DevTools plus your IDE for the platform you’re targeting.
It’s by no means an insurmountable challenge but I’d wager a lot of iOS developers will usually spend 90% of their time in Xcode alone. Some will use it for everything from managing provision profiles to version control. With React Native it’s a different experience. It’s one some folk that are used to the one stop shop IDE for development will struggle with.
You miss out on the mature mobile ecosystem
Native development is getting quite mature. iOS and Android have been on the go close to 10 years and there some really great tools that have developed in that time. For example at Add Jam we’re big fans of Crashlytics and the rest of the Fabric offering from Twitter, it helps us with beta distribution and getting brilliant crash reports . It’s a great, free service that is a breeze to drop into a native project. With React Native its not so simple to integrate it and it doesn’t provide as much value for things like crash reporting.
Asides from Fabric there are plenty more examples of great tools that currently exist for native development (Buddybuild is another great example). A lot of these tools work like magic and are a joy to use on fully native projects but many of them either don’t currently have the same level of support for React Native projects or there are no comparable alternative. But like most of the points in this post it’s something that will improve in time.
As a framework React Native is still quite immature. That’s both a blessing and a curse. It means React Native has these niggles and problems compared to the established ways of working but that also means there’s a tonne of opportunity. We’re excited to see where React Native goes in the coming months and years.
We’re working on a React Native eBook — want a copy? sign up for updates on our website.
Add Jam are creating useful software products in the heart of Glasgow. If you’re ever nearby, feel free to pop into our office for a cup of coffee or a game of pool. If you’re looking for a team to build your product, get in touch.
