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.
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.
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.
Your can now access your insurance card directly through the Alan app.
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:
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.
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!
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.
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.
The team behind the app 😊
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. 🙂