Why we chose React Native
The story behind the launch of our first iOS and Android application 📱
When we started work on our first iOS and Android applications this summer, we wanted to think carefully about which technology to use. Having built our web app on React, we turned to React Native to see if it made sense for our team.
The technical solution we were looking for would ideally be:
- Fast: We wanted to enable our team to ship quality mobile products on multiple platforms as fast as possible.
- Future Proof: We wanted a solution that would work for not only our initial scope, but one we could use to build a complex app over the next few years.
- Team compatible: We wanted all of our team members to quickly be able to contribute, even if they didn’t have experience working with iOS and Android in the past.
- Excellent for User Experience: We wanted the app to deliver the same high quality level of user experience as the best native apps in terms of performance and system integration (access to camera, push notifications, etc).
Along with React Native we considered two other options: classic native applications written in Swift and Java, and a hybrid application relying heavily on WebViews.
While investing in building classic native apps has proven to be highly flexible and scalable, they are costly to develop and have a steep learning curve for engineers who don’t have mobile experience.
A hybrid approach would allow us to reuse existing UI, however we quickly found that it also resulted in a clunky experience, slow load times, and poor handling of offline features. Neither of these options felt like the right way forward.
React Native, on the other hand, responds well to these criteria and has some additional awesome benefits:
- Re-use: By writing React code for our mobile UI logic we get to reuse previously defined patterns as well as pure JS code that is shared between our web app and our mobile applications.
- 2 for 1: We designed our app so that we could share a vast majority of React code between our iOS and Android apps, and the few places where we needed to specialize were easily handled by React Native’s great tooling for platform specific code.
- Development tooling: When you are developing with React Native you rarely need to recompile your app, and you benefit from hot module reloading, along UI inspection and React.
And so off we went! 🚀 We were stunned at how fast we could move with React Native. Once we had set up the initial project, development was almost completely similar to writing code for our webapp, and anyone could contribute with just a few minutes of ramp up time. Within a month or so, we had two beautiful apps available in the App Store and on Google play.
A few things we learned along the way 🤓
Share your code!
One of the biggest advantages of React Native is the ability to share JS code between multiple clients.
You can’t share everything, it is difficult to share display logic as React JSX renders to HTML whereas React Native JSX renders to a Native UI Views built in to the iOS and Android SDK. Similarly, while we would ideally share core aspects of our design language between web and mobile, for example color definitions and margin definitions, sharing styles was initially difficult for us since we write SASS on the web side.
With this in mind we decided to start out by sharing only pure JS parts of our app logic. This includes:
- API client logic: We have an JavaScript API client that we use to handle requests to our backend. Sharing this code between web and mobile was a big win for us, as it allows all of our API requests to be handled in the exact same way across platforms. This may require migrating towards using fetch for network requests.
- State management: You don’t have to use Redux to handle your front end state (although we think you should!), but either way you should try and share how your state is defined and manipulated between platforms. We do this buy sharing Reducers and Action Creators for all resources shared by web and mobile.
- Pure JS Utilities: Any utility methods that you might use throughout your app that are pure JS can be shared. For example we share custom date/time display logic as well as utilities for tracking analytics.
We took the time to properly set up a shared NPM module that is installed by both our web and mobile projects and this cleared the path for us to move much more quickly through the rest of the project. This can be a complicated process and so we will take the time to write this up in a separate blog post at a future date.
Use CocoaPods for iOS dependencies
Linking React Native dependencies to your iOS project can be a pain.
As soon as we needed to integrate a native iOS library in our project we were using CocoaPods for iOS dependencies while manually linking React Native Dependencies. This made no sense, and caused us some headaches while chasing down header paths to get them all pointing in the right direction.
Take the time to integrate CocoaPods correctly and use it to manage both native iOS libraries as well as React Native libraries. If you want to use a React Native library and it doesn’t have a podspec file, it is easy to add one to an existing project!
Simplify deploy process with Fastlane
Fastlane is not a React Native specific tool, and anyway, by the time you are bundling and deploying your app, you are going to handle this in the same way you would a classic native app. We use Fastlane to manage iOS certificates and provisioning profiles for our entire team as well as deploy to TestFlight and Google Play beta with a single command.
Learn what is going on under the hood
Even if you don’t need to utilize the ability to bridge native code in our application, it is very helpful to understand how React Native bridges native code to javascript and how to debug potential performance issues by knowing what your app is passing across the MessageQueue. But more on this later…
So, should you also use React Native ?
React Native turned out to be an excellent choice for our building our first mobile apps here at Alan.
We were super impressed with the maturity of the project and the the size of the community that is behind it.
We are excited to invest further in React Native and to hopefully give back to the community at the same time. We would highly encourage other teams to explore this technology and consider using it in your next mobile project.
Mobile at Alan is very young and we have a lot of big ideas on how to improve how people interact with their healthcare by leveraging mobile technologies.
If you are are an excellent engineer who is curious or passionate about Health and is excited about React Native or the future of Mobile development, drop us a line we would love to chat. 🙂
