Write once, run on iOS and Android. It’s a goal many developers have set out to accomplish. Early solutions tried to bring web resources to mobile, but never had the experience users expected. Later solutions ditched the web development but were based on proprietary technology. This often led to a lack of a strong community, and much like before, these solutions lost momentum.

Then in 2015, Facebook released a variant of its popular React library on mobile called React Native. React Native seemed to address many of the issues from previous solutions. It not only allowed access to the vast resources of JavaScript development, but also ran UI natively. On top of all this, React Native is open source, allowing for it to grow and maintain a strong community of developers.

So when our mobile team here at Sprout started work on the mobile app for our employee advocacy product Bambu, we chose to build it in React Native. Prior to this project, our only mobile app was Sprout Social iOS and Sprout Social Android, which are built independently of each other using native technologies. By building Bambu Mobile in React Native, our team was not only able to have a shared code base, but was also given a fresh perspective on how mobile apps can be developed.

Bambu by Sprout Social Mobile App

Choosing React Native

When deciding if we were going to build Bambu Mobile in React Native, our mobile team had some tough decisions to make. As a whole, we had little experience with JavaScript, and would have to invest the time in learning a new technology. This investment had to be weighed with the advantage of a shared code base. We also knew very little about React Native at the time and weren’t sure of its long term viability.

To help answer these questions, we started by searching for other teams that had already built apps in React Native. This largely involved looking through blogs online and also included a phone call with a team from Groupon,  who had built a section of their mobile app in React Native. In the course of our research, most teams we heard from were confident in their decision to use React Native. While it had some hurdles given how different iOS and Android can be, the consensus seemed to be that the shared code base was worth it. In fact, when looking online, it appeared that most teams were able to write 80-90% of their code in Javascript, which was all shareable.

As far as long term viability, Facebook appears very committed to supporting React Native. The technology is used in many of Facebook’s own apps including Instagram and the main Facebook app. The open source community supporting React Native is also strong. Often times, when we found a bug or needed a capability,  it was waiting to be released in a new version. This offered a nice contrast to iOS or Android, where it may take a whole year to wait for bug fixes or code improvements.

Working With JavaScript

As a language, JavaScript is simple and easy to learn, yet as a community, the language is much more like the wild west. Unlike iOS and Android, where Apple and Google drive the direction of the community, in JavaScript, the community drives the direction. At first, there’s a lot to take in. Many libraries solve the same problems, and it’s hard to know which ones to use. To address this, we left many of our early architecture choices up to our web development team. By drawing on their experience with JavaScript, we were able to narrow the focus and start building much faster than if we had made the decisions on our own.

As we started to build with these libraries, we realized how far ahead this community is of the respective iOS and Android communities. The best example of this would be Redux, which is a JavaScript library that helps manage all levels of state in the application. In many iOS apps, application state is decentralized and scattered throughout view controllers. This often results in a scenario where you may update how state works in one part of the app, but it’s not always reflected in other areas, potentially resulting in bugs.

After spending some time in the JavaScript community, it appears the speed at which it moves can be attributed to a couple of things. For one, Javascript is one of the most popular languages, which naturally means more tools will be created for it. However, it’s greatest asset is how decentralized of a development community it is. Without a single company to guide it, there’s greater opportunities for new patterns/libraries to be tested and explored. So while there are many solutions to problems out there, chances are when you find the right one it will be worth it.

After learning from this community when building the Bambu mobile app, we hope to bring some of the ideas and patterns we learned back to our our native Sprout Social mobile apps. On Android, our team has started to explore RXJava, which follows the same event-driven pattern React Native is known for. On iOS, we have started to use stack views, which is similar to the grid like system of Flexbox in React Native.

In the beginning, I don’t think many of us considered the chance to write in Javascript as a benefit to React Native. However, the fresh perspective was a great unintended consequence. By learning from the Javascript community, we were able to improve our own programming styles and take those improvements to our other mobile apps.

The Benefits of a Team Effort

One of the strongest decisions our team made was having a combination of iOS, Android and JavaScript technical expertise on the development team. While not all developers were working on the app at the same time, we saved many hours by consulting with each other on issues that crossed domains. For example, after our release there was a problem with a webview on Android. As an iOS developer, this touched the two technologies I was least familiar with, JavaScript and Android. It ended up coming down to a team effort where a JavaScript engineer helped me pinpoint the bug, and a Android engineer helped me find where to fix it. Collaborations like this helped ease the burden of managing three different technologies in a single app.

In the end, each one of these technologies have small details that need to be worked out. If a React Native team is made up of developers from only one of the disciplines, they may find that these small details end up costing a great deal of time.

Going Forward

While React Native is still a developing technology, we are confident in our decision to use it for the Bambu mobile app. After all, we were able to write 90% of our code in a shareable language backed by a strong and contributive community. This not only allows us to reduce maintenance going forward, it also opens up the number of engineers that can support and improve the app. In the future, we also hope to integrate React Native into our main Sprout Social app and maximize our ability to share code across teams.