incident.io harnesses the power of native modules and CNG
Users••9 minutes read
Dan Kelly
Marketing

incident.io is a powerful incident management platform that streamlines the process for fixing and learning from the undesired but inevitable incidents that occur. Before you read any further take a look at who uses incident.io: Miro, HashiCorp, Vercel, Linear, Netlify and many other well established, forward thinking software companies.
When it came to building their very first mobile app, the team at incident.io took a good look at available platforms and ended up choosing to build with React Native and Expo. In this blog you’ll learn how incident.io builds with Expo and what kind of impact Expo has had on their business.
How incident.io decided to build with React Native and Expo
In 2019, before breaking ground on incident.io the CTO and co-founder, Pete Hamilton, needed to answer a few important questions: Who do we need to hire? What kind of team do we need to build?
So he went out and pitched his friends and ex-colleagues from places like Monzo, Freetrade, Deliveroo and others. He painted the vision for incident.io and asked for their opinions on how he might approach building the mobile app.
“The resounding response I got from these other technologists was to take a look at React Native if I hadn’t already and a bunch of them also told me to reach out to the Expo team.”
Hiring super talented native engineers is possible, but difficult (and expensive). Pete had already assembled a talented team of product engineers with good design instincts. They had good taste. They knew what fantastic apps should look and feel like. Deciding to go with React Native was an efficient way to turn the existing product engineers into a mobile development team.
“When you combine React Native with Expo it speeds up the time between development and release and it allows the team to build for multiple platforms at once. It was just an irresistibly compelling direction for us to go.”
Continuous Native Generation and the Expo Golden Path
The product engineering team at incident.io is taking advantage of EAS Build, EAS Update as well as Expo Router, Nativewind, and other Expo tools and libraries.
What’s particularly notable about their use case is how they have adopted the Continuous Native Generation approach to developing their app. What this essentially means is that their iOS and Android directories are completely ephemeral things that can be deleted as needed. Instead of configuring native projects directly they do it with config plugins and Expo modules.
“With Expo we can get away with never installing Xcode or Android studio. This is incredibly valuable for our team. They can just scan the QR code in Expo and have a wrapper app ready to go. They just run yarn-start and suddenly everything boots up.”
The team was keen to stay on the Expo Golden Path as much as possible to reduce complexity and lean on the expertise of the Expo team. The “golden path,” in this context, means utilizing packages and solutions built by Expo that all function in harmony. For example, choosing expo-updates over Codepush, Expo SDK packages instead of third party alternatives, and EAS in lieu of CircleCI or Bitrise.
Rory Bain, lead project engineer, had experience building DIY cross-platform applications in the past.
“Having this golden path that Expo has completely thought through has been really nice. Not having to maintain everything and manage provisioning profiles and distribution certificates and just generally make decisions all the time has really sped us up.”
They use CircleCI for CI/CD for the rest of their business, but when it came to setting up CI/CD for their new mobile app, they chose to use EAS build. Even though they could have set up CircleCI to build their mobile app as well, having to set up and manage the build signing certificates and provisioning profiles would have been an absolute time sink. In comparison, the one-command-setup of EAS build was a much more appealing option.
Using EAS for development builds also came in handy due to the importance of push notifications for the incident.io service. Since push notifications don’t work on simulators they had to build for physical devices anyway, and found it useful to use the development builds with EAS Build to get the app installed on devices with a QR code (instead of jumping through a bunch of ios/android hoops). The automated ease of this process also helped create a development culture where more engineers were able to make more contributions, improving the velocity and quality of the product they’re building.
“If it takes a day for someone to go and update some distribution profile and download Xcode then quite often people just won’t make the code changes they had in mind because the barrier to entry is just too frustrating. All that set-up is rubbish. With EAS CLI the developer experience is stitched together so nicely and it has a big impact.”
Building custom native modules
Generally speaking, Expo was a massive accelerant for the development of incident.io. But there was one important and unsolved challenge that took more time to solve with Expo than it would have natively.
For the purposes of their service incident.io needed to be able to send notifications to phones regardless of phone settings like silent switches and Do Not Disturb. On iOS this functionality is already available: set a boolean on the notification payload and it’ll do it for you. But that wasn’t the case for Android.
The team looked around for React Native libraries that solved the problem but couldn’t find anything that worked. This is when they reached down into the native code and wrote a custom native module. To do this they used Expo’s new module tutorial where you run `npx create-expo-module` and it spins up everything you need, eliminating the need to write your own bindings.
“When we wanted to get down close to the metal that was kind of challenging with Expo. But the tradeoff is well worth it because we’re only down there like 2% of the time.”
incident.io found the right combination of “golden path” services and custom native modules to build a powerful application with a fast, efficient developer workflow.
Expo Router use case
The team opted to use Expo Router for the new app’s navigation, which really helped them think through the structure of how the app is organized. And thanks to the file-based routing, they were able to easily deep link users into specific pages when they get push notifications with hardly any additional configuration.
“For example, in our app when you get an error notification you tap on it to open an escalation and acknowledge that you saw the error notification. We basically got that for free by building on Expo Router.”
One unexpected benefit of using Expo Router was the built-in sitemap which came in handy for development, as it enabled developers to quickly jump to the right screen as needed.
The ROI of building with Expo
There are essentially two ways to measure the ROI of Expo: speed and dollars.
Regarding speed
“The thing that I care about most at this stage of the company is speed. How quickly can we go from idea to market? That’s what matters. And with Expo we’ve been able to go from nothing to a full production release in months without hiring any additional engineers. That’s the ROI of Expo.”
Regarding dollars
The dollars are difficult to quantify. Expo is an investment that has allowed incident.io to build and ship without adding headcount. But what’s more compelling is that Expo accelerated the development of incident.io far ahead of schedule.
“One easy way to measure the ROI is just to add up all the revenue we make in the next six months. Because without Expo we’d still be in development six months from now.”
What’s next for incident.io and Expo?
Recently incident.io released their new On-Call service:
Today Incident.io runs a monorepo for all of our code which means that everyone on the team has actually already installed all of the mobile stuff just by running the web app. The goal of this is to make it even easier for more people to begin contributing to the mobile app. All that’s needed is for each engineer to scan a QR code on their phone, run yarn start, and scan another QR code to connect the phone to the Expo server.
“We've not spread this around to the whole team yet. So I can't speak to the fruition of having that set up. But we’re going to start spreading it around soon and I think it will help us move even faster than we already are.”