A Dynamic, Crazy, Native Mobile Future—Powered by JavaScript

Two new developments can take mobile down a weird, but exciting, road:

  1. React Native, which lets you write native mobile apps in JavaScript, powered by JavaScriptCore on iOS
  2. Apple recently allowed apps apps using JavaScriptCore to update themselves autonomously, without the App Store review process

History Lesson

The single biggest pain when developing iOS apps is you can’t fix or change things at any time. If you find a bug, if you want to run an experiment, if you want to ship a new feature — you submit an update and wait a week. It limits most engineering teams to monthly releases, in frustrating contrast to the continuous delivery we adopted on the web.

Of course, you could make a hybrid mobile app powered by an HTML web view, and then you could ship new features on-demand — but the quality of your app will suffer. Users feel the difference, and Facebook, LinkedIn, and others learned this lesson at scale.

With the proper tooling, that “single biggest pain” could go away in a world with React Native, and not have a tangible effect on users.

In this brave new world, what new things could we build?

Native Embeds

That tweet uses a technique called “Native Embeds”. Post-React, apps like Twitter can embed React Native-powered content. When The Boston Globe authored this tweet, they attached some React Native code, and the Twitter app takes care of displaying it.

You can imagine other social apps, creative tools, and ad platforms (of course) using Native Embeds to create smoother and more engaging experiences.

Seamless Native Browser

It’s the logical evolution of Native Embeds: make the “embed” take up the entire screen, and fetch it from a URL. On a technical level, the browser would make a quick HEAD request, and Twitter would return some standardized HTTP header (“X-Native-URL”). The URL value for that header would be requested, and it would return a React Native interface. If that header didn’t exist, then the browser would fall back to vanilla HTML.

I think it’s most compelling when considering how we share apps. You hear about a new app from a friend, look it up, and can immediately get a feel for it just by clicking the search result. Maybe some features like the Camera can’t be enabled until you download the app, but this could get way more people in the door.

Native Search

Coupled with existing deep-linking infrastructure, this would make the web search more useful. Facebook could better understand what type of content you like on your Newsfeed. And maybe this could even fix the broken App Store search, and finally make it aware of more fields than pre-defined keywords.

App Generators

Previously, if you wanted to make a product that created apps, you either had to lean on HTML and web views, or come up with some kind of native code template system. The latter was tough to scale because the cost (time and money) of writing native code is high.

At Propeller, we worked on an native app generator for online shops. Instead of leveraging JavaScriptCore like React Native, we came up with our own markup language and iOS implementation to send native interfaces from our servers. It was clever, but basically a more scalable (and limited) evolution of the template system. If React Native had been around, it would have been the obvious choice.

Who Knows?

Even though all this new hotness is possible, it doesn’t mean people will want any of the products it yields. It’s an exciting time to be a developer, but maybe users are just totally indifferent with whatever comes of it.

Engineering @Opendoor

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