Don’t Throw React Native Away Just Yet
The main reason why mobile developers get enticed by the cross-platform development capabilities of frameworks like React Native, is, of course, the ability to share code across platforms. A smaller, but no less important reason is the ability to build, debug, and refactor faster. Last but not least, such solutions often help broaden up the variety of tools, beyond the ones dictated by the platform vendor.
Achieving the same level of native perfection across platforms is difficult. Depending on their expectations and requirements, app makers often face challenges, which require a pivot. Ultimately, many decide to go back to developing separately for each platform. It is tough for me to say where the thin line lies between giving cross-platform development technologies a big YES or a big NO. Instead, I would like to focus on the two latter two aspects, namely that sharing code aside, such technologies often offer certain other advantages to developer productvity, which the recommended stack doesn't. I have focused my mobile efforts almost exclusively on developing apps for the iOS ecosystem, and still, I believe that there is lots of reasoning in checking React Native as a way of making programming a more productive and enjoyable experience.
Tooling
I am primarily a Java developer who has done a fair share of work for the Web. Thus, one can imagine my astonishment last year, when I opened XCode for the first time after 6 years.
Despite the years of Swift-izing the whole ecosystem, the major tool which developers use to develop their applications is still more or less the same stubborn text editor that refuses any form of customization. And while this text editor was more or less sufficient for writing Objective-C back in 2011, in 2018, it feels like an over-boasted shadow of what even a mediocre Java IDE can offer. Boy, even editors such as VS Code and SublimeText, which do not pretend to be IDEs, offer more more opportunities for making work more pleasurable and productive, than the latest version of XCode.
The problem goes beyond XCode’s shortcomings as an IDE, though. It is about Apple’s approach to tooling in general. XCode is considered “the one and only tool you’d ever need, to get the job done”. Problems of all kinds get attributed to not having the latest version of XCode installed, not to what has caused the problem in the first place. And who cares that the Swift compiler toolchain can be installed separately, is much smaller, and can be maintained from the command line? May the Force be with you, if you try to use a Swift compiler version that is different from the one that your XCode shipped with. Or try to tinker around your app, using a tool built by the community. The imposed ubiquity of XCode has ramifications far bigger than just developing for iOS or macOS. Unless you’re willing to go really rogue, it can affect most kinds of developer work on the Mac:
> yarn install
- Tobias Nyholm (@TobiasNyholm) July 14, 2018
node-gyp: Error: `make` failed with exit code: 2
Make is only installable with Xcode.
To install Xcode you are required to run the latest OSX.
So it is 2018, I need to upgrade my operation system to build my front-end assets?! How did we get here?
I’m an Xcode hoarder pic.twitter.com/ZNJSQCNc5n
- Sam Soffes (@soffes) July 18, 2018
I am a firm believer that as developers, we should keep developing and using community tools. Those help make our lives as developers easier. They also help challenge the Status Quo, signalling the platform vendors that change is needed. And while we can’t escape XCode completely, React Native can be one way to avoid having to work with it, until it is really needed, that is when assembling the app, or when bridging to the native APIs.
The Web Ecosystem
I know, React Native is not a Web framework. I said as much in my previous blog post on RN. Yet, no one can deny the inspiration and motivation that RN has gotten from Web development. And let’s be honest, you can say whatever you want about the Web, or JavaScript for that matter, but it seems like a hell of a lot of innovation has been happening in the field during the past decade. Innovation, which has gone beyond the limits of the Web development itself, and into all other spheres of IT. We can certainly embrace this fact, instead of denying it, hiding behind statements that undermine JavaScript as a programming language, or the average age and experience of the Web programming community.
The Speed of Development and Delivering Updates
A direct consequence of the previous two points, the dynamic and rapid development nature of JavaScript in particular, developing React Native applications is blazing fast. Indeed, it takes a certain amount of time together used to the initial setup, as well as how things in the RN Universe match those in the iOS world. Once this period is gone however, the actual development part is extremely streamlined. Changes do not require a rebuild and restarting of the whole app, but mostly a few seconds for rebuilding and reloading the JS bundle. In my experience, this feels almost instantaneous. Debugging is also pretty pleasing, especially if come from the Web development world. It can be as simple as pointing your Web browser to a particular URL and opening up the developer tools. From there, it can get as complex as you want it - there is a variety of debugging and profiling tools, as well as plugins for various editors and IDEs - pretty much any tool for profiling and debugging Web apps, can be made to work with RN too.
Besides the development part, one killer advantage of this dynamism, is the ability to ship updates over the wire, without having to go through the rigorous App Store update and review process every time. For hotfixes, A/B testing and minor updates, this feature alone would make anyone consider bringing JS support to any app, not just the ones built with React Native. The ability to ship changes over the wire, or deliver apps in a modular fashion, although not without its own set of issues, is still a very promising addition to any professional's tech stack.
Bridging
Bridging to native is the part often cited as the least enjoyable step, as well as the one involving the most boilerplate. Indeed, although bridging to native UI components is a bit clunky, a big part of why it has been considered tedious, is because of the cross-platform sharing expectations of app developers. In my case, bridging to iOS or vice versa, besides full of sometimes annoying boilerplate, is generally comprehensible, and works seamlessly for the most part. Of course I come from a background in server-side Java programming, so writing boilerplate code is not something that would scare or annoy me, but I do realise that this might be a bit of a demotivation factor for many.
Bridging can be a particularly interesting learning experience, because the deep one gets, the more one might have to deal with the inner intricacies of the iOS environment and the Cocoa Touch SDK. Most of the technical documentation concerning RN on iOS features Objective-C, which might not be up to everyone's taste, but I kind of like it. I believe that to really understand something, you have to skip the beaten path, and choose a different one that presents learning challenges. Of course, not every project presents a learning opportunity, but if there is room for that, I'd go for it.
Conclusion
All in all, developing for iOS using React Native might sound crazy and inefficient. It probably is for many use cases. But for others, it might be just the right thing. The thing is, until you have worked with it, you won't really know when to use and when not. See, I like to thing of a tech stack as a set of tools - instead of using a hammer or a screwdriver for everything (as I've seen many of my friends do), I'd choose the right tool for the right situation. I hope that I have convinced at least one of you, dear readers, to try something different from the Status Quo, and I hope it might have helped broaden up your horizon as developers.
NOTE: This post originally appeared on my blog