A Dynamic, Crazy, Native Mobile Future—Powered by JavaScript
Two new developments can take mobile down a weird, but exciting, road:
- React Native, which lets you write native mobile apps in JavaScript, powered by JavaScriptCore on iOS
- Apple recently allowed apps apps using JavaScriptCore to update themselves autonomously, without the App Store review process
History Lesson
What was the old world like?
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
You’re browsing the Twitter feed, and one tweet looks special, something you’ve never seen before. It’s a tweet from The Boston Globe, and it has an animating slideshow of recent events from The Big Picture. The slideshow looks slick, with gradual cross-fades and subtle Ken Burns-style zooms. When did tweets go from 140 characters to gorgeous animations?
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
You open Safari, and instead of seeing the mobile-optimized web page for “http://twitter.com”, you use the exact same interface as the native Twitter app. Buttery smooth scrolling, native navigation effects between pages, and the Pull To Refresh we know and love. This is what a “seamless” native web browser would feel like.
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
Mobile apps are a black hole for search. If you want to find a Yik Yak post, you use Yik Yak’s search. But if we adopt some type of seamless native browser protocol, then it makes it much possible for search engines to index the content we find inside of native apps.
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
Finally, this world enables a new class of “app generation” products. This does not mean that people actually want app generation products any more than they did before, but it does mean these products will be easier to develop and yield higher quality apps.
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?
This list is not exhaustive, and there are definitely more, yet-to-be-discovered techniques that React/JavaScript mobile development will bring.
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.
