Bringing Job Spotter to iOS: Indeed’s First React Native App
In 2013, Facebook released ReactJS and changed the way a lot of people (including us) think about web development. In 2015, Facebook released React Native, allowing developers to create powerful native mobile experiences using JavaScript and React. When we planned to bring the Job Spotter app to iOS, we were hopeful that React Native would live up to its promise.
Spoiler alert: it did.
Intro to React and React Native
React is a different way of thinking about web development. Instead of separating code by function, React encourages separating code by components. Each component contains all the layout, styling and business logic it needs — often in the same file.
React’s other important feature, described in this conceptual document, is one-way data flow. Compared to the two-way flow implied by other frameworks, it is much easier to figure out how state changes affect the app in React. One-way data flow also enables powerful libraries like Redux.
React Native lets you write JavaScript for Android or iOS apps with React that deliver native performance. Web developers can write powerful native apps, without needing to spend time learning unfamiliar native mobile development technologies.
Wins
React Native helped us speed up our mobile development cycle. Using out-of-the-box tools, we can run our React Native app locally in the iOS simulator. That allows us to refresh the app to test changes without recompilation, just like we would in the web. Even better, application state is maintained across these “hot reloads.” These development features of React Native translate into a big savings in time and effort, allowing us to focus on developing new features.
Since we could leverage our previous React knowledge, we didn’t have to learn a new language and could get straight into coding. This was especially great for our team, since none of us had used Objective-C or Swift. Another bonus was that, except for some custom event logging, we hardly had to write any native code.
Another interesting aspect of React Native is that it requires using inline-styles, in which CSS “classes” are actually JavaScript objects. This seemed strange at first, but we’ve grown to love it. Since we were dealing with objects, we could create powerful, composable, and extensible CSS classes and avoid a lot of style duplication seen in traditional webapps. We could develop different looks and functions as needed, rather than having to repurpose the same styles for different needs.
React Native makes heavy use of Flexbox, a newer CSS module that aims to make styling more consistent and straightforward. This removes the need to know many of the traditional quirks of CSS. After overcoming the learning curve, the more declarative approach of Flexbox allowed us to style new components more rapidly than in traditional CSS.
Debugging was also easier than we expected. We just connected to the debugger in the Chrome Developer Tools and debugged the same way we would on the web. React Native has several additional tools — the element inspector determines the styling applied to a component, and the network inspector analyzes the XHR requests your application makes. Being able to reuse familiar tools helped us track down and fix issues as they arose.
Challenges
React Native enabled us to develop more rapidly, but React Native itself developed just as fast. In the two months that we worked on the Job Spotter iOS app, React Native had six releases. After updating to each new release, we would have to do a full regression test of our app.
Another major and related challenge: React Native’s newness. A lot of capabilities that would be better as default features still required third-party libraries, such as accessing the camera and file system and handling permissions. The community works hard to pick up the slack of React Native core. However, these third-party libraries sometimes lacked the quality we expected from the core library. In fact, we had to patch more than one such library.
The components available for navigation and screen transitions were also inconsistent. We ran into an issue with the Navigator component in which every transition needed some kind of animation, with no option for an empty transition. This initially made some of our scene transitions look awkward. We tried using the NavigatorIOS component, but its interface was less friendly and straightforward, and lacked many of Navigator’s features.
Similarly the TabBarIOS component works quite well, but its transitions were completely independent of whatever Navigator we used. We wanted a single navigator handling everything. We had to use different code paths for supporting navigation when we would have liked one.
It’s worth it
Despite these challenges, we continue using React Native. It fits well in our toolbox. We can use our web development expertise to build rich mobile experiences without having to become Android or iOS experts. And as React Native matures, we expect many of these current issues to be resolved.
Our next step is porting the React Native version of Job Spotter to Android to replace our existing native Android app.
Published also at Indeed Engineering Blog.