React Native at scale

Hargett treats stability as a core part of performance: a crash means zero useful frames. He recommends tracking user-facing measures such as startup time, animation smoothness, fresh data, and battery life on every commit, so gains in one area do not hide regressions in another.

For a consumer electronics project, the product organization set a 200-millisecond app launch target and wanted web technologies without a browser-based UI. Hargett’s team recreated existing Ember apps in React Native, trained small groups with practitioners from Callstack and This Dot Labs, and included testing and common causes of unnecessary re-renders.

Hargett evaluates open-source projects by looking at contributor diversity, the bus factor, CI, and test coverage. His team compared navigation options through prototype apps, then chose React Navigation after generic bug fixes were accepted upstream. He warns that hard forks can isolate teams from ecosystem knowledge and make ongoing support harder.

The team tested controller response and investigated profiling early, including challenges connecting WebKit Inspector to JavaScriptCore. React Native Web offered a way to automate functional and performance checks in headless Chrome before specialized hardware was available. For platform technologies such as React Native Windows, Hargett advises checking real deployment scale, crash rates, and field support, rather than relying on repository popularity.

Hargett recommends recording stakeholder concerns and testing them against quantitative targets at two- or four-week intervals. Teams can set staged goals, such as improving a prototype from 800 milliseconds toward the target, while keeping a Plan B. When resources allow, parallel approaches can reveal useful ideas even if one technology is not selected.