An iOS Developer’s Journey Into React Native

Hesham Salman
May 2, 2018 · 4 min read

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.


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).


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.


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.

Further Reading

Follow me on Twitter for more content hesham salman (@_hsalman) | Twitter

React and Respond

A journey into React, and React Native

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store