The UI Was Beautiful. The Frame Rate Wasn’t. Here’s Why We Didn’t Fix It.

We made reasonable decisions. They still created problems. We built a React Native app optimized for developer experience, iOS-heavy users, fast iteration, and polished UI. Those choices helped us move quickly and deliver a strong product. They also introduced user-visible performance issues we never addressed. We saw scroll jank, dropped frames, and clear degradation on Android and lower-end devices. We knew the problems existed, but we never prioritized fixing them. Not because we ignored them, but because we never made them measurable, visible, or actionable. We had no reliable way to diagnose performance issues. Much of our testing happened on iOS and emulators, where signals were inconsistent or easy to dismiss. We did not define performance budgets or target device tiers. And without clear metrics or business impact, performance never meaningfully competed with feature work. Over time, common React Native patterns, including abstraction-heavy component structures, styling systems, and increasingly complex rendering, created a performance ceiling that became expensive to unwind. In this talk, I will walk through the decisions we made, why they were reasonable at the time, and how those decisions compounded into performance debt over time. I will also share how my perspective on React Native performance has evolved after investigating similar issues more deeply, and what I now look for when evaluating performance in production apps. This talk is designed for engineers building real React Native apps who want to better understand how performance issues emerge in practice, why they often go unaddressed, and how to prevent them earlier. You will leave with a practical framework for treating performance as a product constraint, including how to define performance budgets, validate against real device tiers, and avoid architectural patterns that are easy to adopt but difficult to reverse.