How React Native Was Used for the Get WIRED App

A few months ago, I wrote a series of articles on why I’d choose React Native as the basis for just about any new, native, mobile project.  Since then, we’ve completed three projects and are just a few weeks away from launching the forth.  We created an app for Alamo, launched Flip50 and have a project for an international restaurant chain in the works.  Lastly, we wrote the WIRED app, which is the smallest of these projects and the one I’m going to tell you about in this article.  You’ll quickly see, it’s not the size that impresses.

“We have an opportunity to write an app for the upcoming WIRED25 event.  It’ll allow users to read articles, view AR experiences and give them up to date event information.  Oh, and it needs to be done in eight weeks.”  That might be a slight paraphrase of how the conversation around the WIRED25 app (now named Get WIRED) started, but it definitely hits all the key points.  And, after my initial reaction of, “You want what, by when?” I started planning out how we were going to make this happen.

The first thing we had to do was put together a team.  This included one part time iOS developer with React Native experience (myself), one part time Android developer without React Native experience and one front end React developer with no native mobile experience.  We also had a UX designer and a visual designer that worked very closely with the development team.

I had a week head start on the rest of the team, so I was able to put a solid framework into place and setup our continuous integration platform (Microsoft App Center).  This gave me a chance to create clear sections of the app for each of us to work in.  Our front-end developer was tasked with making the app look good.  Our Android developer started in on the app’s map feature, using React Native maps.  We anticipated that there would be some native issues to arise there so we wanted to be sure we got a jump on it.  It took a couple days for him to understand how React Native all fit together, but, by the end of the first week, we had working maps and he was moving on to the UI around that feature.

Progress was moving along quickly and within three weeks we had our first testable releases.  Microsoft’s App Center played a key role here since it seamlessly integrated with GitHub and we could trigger a build at any time with a button click.  Once we were testing the app, the real iterations started with bug fixes and feedback being address rapidly and often in real time.  The fact that we could just update the JavaScript code and have the change be on both platforms at once was a life saver and just another reason to love ReactNative.  Too many times side by side collaboration fails when you have two native code bases and one gets more attention than the other.

Adding AR to the app was done using the HP Reveal SDK.  In a platform native app, this is a drop in SDK and all the marker and overlay management is handled on the server side.  But, because we were using React Native (and there was no React Native version of this SDK), we had to write a bridge.  This could have been a major issue if something went wrong, but a day later we had the bridge working and AR in the app.

The launch date was fast approaching and we only had one chance at this.  Because this app was intended to launch right before the event, we wouldn’t have time to fix and release a new build if there was an issue after launch. This is where App Center came in to play again.  Codepush is a feature that allows us to push a new JavaScript bundle to the app without the need for the app to be updated through the app store.  Since the vast majority of our app was JavaScript, this meant, with Codepush in place, we’d be able to fix any major issue in real time and users would automatically get the update the next time they opened the app.  The last four weeks of development we tested with this feature extensively. This gave us nearly two extra weeks of development since we were able to release to the app store and continue to iterate and fix bugs in the live app.  This feature was so easy to add and so useful, we now consider it for every app we do, even if there is no true need for real time updates.

But, React Native isn’t all upsides.  There are a few things, as native developers, we’ve run into that annoy us.  And they are almost entirely related to the tools.  We use Visual Studio Code and, while it’s great, it’s not specific to React Native.  If you are used to using XCode or Android Studio then you expect your IDE to integrate seamlessly with your platform tools, you don’t get that advantage with the React Native tool chain which requires a bit more setup and maintenance.  The debugger is also finicky at best.  But, in most cases, these are just annoyances and not blockers.

The Get Wired app could not have happened with the budget and timeframe we had if not for React Native.  Advantages such as having a single code base, being able to uses cross platform skill sets, and Codepush, were essential.  And, having a system where we can drop down to the platform project files and add our own bridging when needed is an absolute must have as well.  There are still projects where React Native may not be your best option, like games and VR heavy applications.  For those, Unity may fit the bill better.  But, for our apps, we’re seeing amazing success with it.

Note: The Get WIRED app is available in the app store now.  The WIRED25 event tab is no longer part of the app so the maps and AR component are not in the current version.  Codepush was used to swap out the WIRED25 tab with the current Events tab followed with a full update which went through the normal app store approval process.