An iOS Developer’s Journey Into React Native

Published in

React and Respond

4 min readMay 2, 2018

Like many iOS developers, I had sour opinions on JavaScript. I remembered JavaScript as that weird, wild-west language where no two environments are the same. My memories of JavaScript were formed at a time when Xcode’s native tooling was far superior to web tooling — we had cool stuff like storyboards, auto-completion, great feedback built into our development environment, and ubiquitous integrated libraries.

Tooling

In the years since then, the web has made improvements and achievements at break-neck speed while Xcode is… largely the same (with the addition of Playgrounds in Swift) or worse (Swift refactor tools) . The JavaScript language and development environments have evolved. All of the features of Xcode that we loved — IDE auto-completion, in-line docs, immediate feedback for syntax errors — are basically built into modern environments. Storybooks — which are basically the equivalent of Xcode Playgrounds — are fantastic (and through a great extension by Orta, built into VSCode).

Testing

JavaScript testing (through Jest🃏) is in another league. It’s near-instant, it’s automatic (it watches Git changes and runs tests for affected files), it has an RSpec-like syntax, and it runs on every save. Native unit testing has always felt like an afterthought — to the point that there are blog posts about a hypothetical modern testing framework released by Apple.

XCTest is great, but it feels like a legacy testing framework. It’s hardly different from JUnit, limited to one setUp method and one tearDown method, and has no ability to automatically run tests on save. Alternatives like Quick/Nimble are great and modern, but basic features (like running an individual test) will remain missing without first-party support built into Xcode.

Feedback Loop

JavaScript’s feedback loop is much faster than native. I’ve never worked on a large native project that didn’t have absurd feedback cycles. In some projects, it can take a full thirty minutes to go from git clone to a copy change. Incremental builds could be anywhere between 20 seconds to 3 minutes — just long enough to lose focus or get distracted by Twitter. The simulator restarting, and having to manually navigate back to your controller is painful.

Enter: Hot Reloading.

An optimal feedback loop makes a huge impact on developer productivity and code-quality. The approach to writing code is so different when the feedback loop is long — I found myself trying to create an entire feature or entire screen at once, hitting compile, and hoping for the best while I grabbed coffee or went for a walk. True TDD is impossible to practice when compile times are measured in minutes. At the shorter feedback loops that JavaScript allows for, I found myself practicing red-green refactoring, real TDD, and having real-time design iteration.

Performance and “Feel” of React Native

Even when I began to hear about the improvements in the non-native development environment, I scoffed. I remember how awful PhoneGap applications felt and how difficult working with Xamarin was (it may have improved over the years?). I remember how the mobile applications produced with those technologies didn’t feel right and how they were slow to scroll or transition.

But, even though React Native definitely has some increased overhead, its performance is fast enough to the point where I’d be hard-pressed to know which apps I use are native or react-native. And when it comes to doing something that requires performant code, you can write that code natively in your React Native application — meaning, that you can live with a better development environment, faster cycles, hot reloading, and better tests in 99% of cases. For the remaining 1% of cases, it’s easy to fallback to the native environment that you’re likely already comfortable with.

Future

The future of React Native isn’t as certain as the future of Swift. There’s little fear of Apple dropping Swift tomorrow, next week, or next year — but who knows if React Native will still be an active project in five years? These fears are fair, but realistically it doesn’t make sense to think about the technology of five years from now. Pull up your phone. Page through your apps. How many of those apps have existed for more than five years, and of those that have, how many of them haven’t gone through a complete re-write or re-architecture recently?

Years ago, when I chose to become an iOS developer it was because I was building for device that felt intimate and personal, but it was primarily because the developer experience was fantastic. The community support was great, and the ubiquity of the tools and frameworks made it so that iOS developers were all using a shared set of tools. Xcode and its tooling had advantages over web development environments.

Today, the better experience lies with React Native — when it comes to testing, development, tooling, and arguably even IDE-performance.

Over the next few months I’ll be documenting my journey into the world of React Native from the lens of an iOS developer, where I’ll uncover and share all of the great, not-so-great, and just-okay things about React Native development.