Building our First Mobile App with React Native
A few months ago, we launched our first mobile product using React Native. LandInsight GO is a cross-platform companion app to the main LandInsight web app, allowing users to explore and save potential development sites while out of the office, as well as access their existing LandInsight saved sites.
In this post I’ll be talking about some of the key technologies used to build the app, decisions made around them, and some of the pain points encountered along the way.
Expo vs Native
Expo is a framework, toolset, and collection libraries aimed at making React Native development a smoother experience than in its basic form. The main draw is that you can very quickly build an app without needing to install any Native SDK tooling (ie Xcode, Android Studio). This is great for fast prototyping and validation of an idea for an app. They even support building and publishing to iOS and Android app stores. This comes with a drawback, however, in that you cannot install extra native dependencies (without extra complication).
We knew quite early on that we would need to use Mapbox’s native map library, so unfortunately Expo was a no-go, and we went fully native.
By using Flow, we get instant feedback when calling a function with incorrect argument types, and refactors are a lot easier (and safer!). However, the typechecking process in Flow can become very slow, with the background process using vast amounts of memory. This isn’t a problem commonly encountered by TypeScript, and generally the tooling seems to work better (Visual Studio Code in particular), so in hindsight we would have been better served by using TypeScript instead.
Because we opted for a native build instead of Expo, we are responsible for the entire build / test / deployment process. To do this by hand, this would involve building locally using the React Native command line tools, and uploading the generated native binary files to the App Store and Google Play Store. But we can do better! Nobody likes doing these time consuming, manual tasks. Our entire web application stack is continuously deployed so why settle for less? I had read about the magic of Codepush, which allows developers to push updates to their React Native apps over the air, bypassing the infamous App Store review process. Codepush integrates seamlessly with Visual Studio App Center, which is Microsoft’s CI platform. By using App Center, every commit to master kicks off a new build for both Android and iOS, which is pushed to the respective app store platforms if the build succeeds. App Center is almost trivial to install, and vastly simplifies the process of setting up CI/CD for React Native projects.
The builds themselves aren’t exactly fast. If you’re used to the typical Node.js or Webpack build times, prepare to be disappointed. React Native isn’t particularly lightweight, and once you’ve thrown a few native modules into the mix, expect to see build times exceeding 15 minutes. This isn’t a criticism of App Center, but it does mean that having a local testing process is far more necessary than simply relying on the CI platform to tell you if the build is broken. For testing, we went with Facebook’s open source framework Jest. Unit tests are run as part of the build process to prevent a broken app from making it into our customers’ hands!
iOS vs Android
React Native is a cross platform framework. One codebase can be used to output native apps for many different platforms. This was one of the main reasons why we chose React Native over pure native code, however it wasn’t without its own set of problems.
It’s fair to say that while iOS and Android apps built with React Native are similar, they are not identical. The same code running on iOS will have a different look and feel to that of Android. Native modules might also behave differently, as they have to be written separately for each platform. These small differences add up, and resulted in quite a jarring development experience.
The main piece of advise I would give to anyone looking to build a cross platform React Native app would be to test on both platforms early and often. It’s no use building your app 100% for iOS, and hoping that it will work for Android (because it won’t). At the very least, set up CI for both platforms. Make sure you can build for both iOS and Android, because it will save you headaches (and a lot of coffee) further down the line.
In future posts, I’ll discuss some of the other questions I asked myself when building the app. If you’re interested in getting stuck in with cutting-edge technology like React Native, then join us! We’re hiring!.
We are the engineers behind LandInsight and LandEnhance. We’re helping property professionals build more houses, one line of code at a time. We're a remote-first company with our tech team in Europe, and yes, we're hiring!