2016: The Year React Native Eats Mobile Development

Clay Allsopp
3 min readFeb 22, 2016
Maybe I can just stop here

On the eve of React Conf, I wanted to drop some observations on the state of React Native and where it’s going.

In the past year, I’ve observed traditional iOS developers becoming excited about React Native. I think that’s a huge, under-hyped trend.

It’s not just that React Native allows web developers to write mobile apps — React Native has become fundamentally better than the status quo for experienced mobile teams, and in 2016 we’ll see greater adoption in prominent (non-Facebook!) apps.


Not Worse Than UIKit

This is the most important part — if React Native apps couldn’t go toe-to-toe with UIKit apps, it would be much harder to justify. But after working with React Native in production for a year (at work and on my own), I’m convinced the results are not meaningfully different than UIKit, maybe even better.

Awhile ago I was less sure React Native could pull off heavily gesture-driven apps, but with new constructs like InteractionManager, better Animation APIs, and general improved performance, I’d bet that 2016 proves me wrong for that remaining subset of products.

Over-The-Air Upgrades

I hypothesized this last year and now it’s a reality. Tools like CodePush, AppHub, and Exponent let you update React Native apps on-the-fly in a way that is kosher with the Apple policies.

It’s game-changing — native apps iterating at the speed of the web. This is what teams want, not the every-two-weeks release cycle that the iOS App Store has historically imposed.


Unprecedented amounts of code continues to be written in JavaScript, and the language is now evolving at a regular cadence. Teams can share code across the web, mobile, and maybe even the backend.

The learning curves of native iOS and Android development are steep (languages, frameworks, tooling, idiosyncrasies, etc), and many of the skills are non-transferable to other parts of the stack. With JavaScript-powered mobile apps, you may only have to learn one set of tooling and standards that your team chooses.


React as an API for abstracting a view hierarchy is more natural than UIKit (and it’s Android counterpart). React is functional, declarative, composable, and now portable across many platforms. You could write React-esque native view code using tools like ComponentKit, but with React Native you can just use the real thing.

Incremental Migration

React Native isn’t an all-or-nothing choice, which is what makes it particularly appealing for existing products. You can drop in a React Native-powered view and iterate on it in isolation, leveraging OTA updates, JavaScript tooling, and everything else that makes React Native exciting.

This year will be exciting. I’ve been working on iOS apps since the first SDK, and only since React Native has iOS development not felt at some level like a burden.

Mobile has been a snowflake in terms of language, tooling, release process, and hiring — but React Native resets the playing field without a change in quality. In fact, it might even improve quality. More teams and companies are realizing this, and the ecosystem will improve because of it.