How to build your React Native team.
3. Managing your project
Leverage your existing Javascript and Web developers.
Once you have your project and team set up, you can start leveraging your existing web codebase and web development team. If you have auth and API client code already written for web, split it out into its own project so you can use it with your app. Developers from your web team will be excited to build features for mobile,
Set up TypesScript.
I’ve been a fan of typing in ECMAScript since the days of ActionScript 3 (dem good ol’ days), but I resisted TypeScript for a long time because it seemed a little painful and unstable. That has changed. The community has settled on TypeScript as the typing standard:
Build a design system.
If you want to go at ludicrous speed, create a design system for your app. A design system is a collection of reusable components following clear guidelines. It’s a collaboration between developers and designers to create a shared UX language, and helps in creating a uniform user experience.
A design system is important for development speed because it keeps designers and developers on the same page (?). Sometimes designers build screen first rather than to component first. When designers focus on whole screens, there can be variations introduced in spacing, font sizing, colors, etc. When developers have to build entire screens from scratch, they can get overwhelmed (or be lazy) about the details. Without a design system, over time it becomes hard to update old screens and your app will lose its uniformity.
Teams that work this way tend to blame developers for not being detail-oriented enough. If you’re getting swamped in the details, work to reduce the complexity of your designs. It’s much easier to specify screens as collections of components with well defined guidelines. Having a design system as reference simplifies communication between your teams, keeps everyone honest, and speeds up feature development.
If you already have an existing app, starting a design system recreating your designs might seem too much effort. Trust me, stop what you’re doing and create one now. You have no idea how much time you’ve been wasting. You can easily take your design system from Sketch to code with Storybook. Samantha Bretous (@samanthabretous) has a great talk on building a component kit.
What about universal components? React on the web and React Native are very similar but they have key differences, (i.e. `<div />` vs `<View>`, CSS vs StyleSheet, different platform capabilities). Universal components are React components built to work in both platforms. If you’re building a product for both platforms you might be tempted to go that route. In my experience, since it’s not painful to make a React component twice, I haven’t felt the need to. Kurtis Kemple (@kurtiskemple) implemented them during his time at MLS and you can read about his experience here.
Set up your build process.
You’ll want your RN lead to create a beta and a production version of the app. The beta version points to your non-production backend, and has the very latest changes for your team to try out. You can use Fastlane to automatically deploy to the app stores. Gant Laborde (@GantLaborde) wrote a guide on how to set it up. You can take this even further by using Github webhooks to automatically deploy the beta app whenever the master branch changes, and releasing the production app whenever a new release is tagged.
There are two ways to manage production bugs: you can hotfix after a release, and you can avoid creating them in the first place. I prefer the latter, but shit is known to hit the fan. In the case you released a bug to your users and need to fix it right away, CodePush is your friend. React Native works by running Javascript from a bundle that gets packaged in the app. CodePush lets you push out a new bundle directly without having to release a new version to the App/Play stores. This is limited in that it can only fix Javascript bugs. If you have a native bug, you’ll need a full release.
If you want to avoid shipping bugs in the first place, invest in Detox for end-to-end testing. The most common types of bugs I’ve had to deal with are regressions. Features in development get the most QA attention before a release, and sometimes changes for new features can break old ones. It’s particularly bad when regressions go unnoticed for months. You can have some peace of mind and save your QA team a lot of time by implementing Detox in your build process. Here’s a quick explanation and demo of E2E testing with Detox. There’s a much more extensive article by Rotem Mizrachi-Meidan (@rotemmiz) here.
A note about CodePush: If you automated your releases with FastLane, you could use a semver versioning scheme to sometimes release via CodePush. A `minor` version bump could indicate a a full release (aka you have changes in native code), and a `patch` version bump could indicate a CodePush release. For example, if you’re on version `2.3.1` of your app, tagging version `2.3.2` gets the CodePush treatment, while tagging version `2.4.0` gets the App/Play store treatment.
Maintain the hell out of your app.
As I mentioned earlier, RN is still evolving very quickly. It’s like a wild horse. You can ride it and go fast, but if you’re not paying attention it can buck you and leave you behind. So every month, when the new version of React Native comes out, your team needs to make a strategic decision about when you’re going to do the upgrade. Does the upgrade have things you need? Does it affect your 3rd party dependencies? How bad are the breaking changes and how do you balance that with your project schedule? There’s definitely more platform maintenance than on native apps, but the speed advantage more than makes up for it.
I hope you found this article useful in deciding where to go with React Native. If you need more advice, you can write to me at [email protected].