I tried to look at the landing page and it crashed Mobile Safari... relaunched it, scrolled a bit down, scrolling smeared rows of pixels up my viewport rather than text. It eventually redrew and reset the viewport, I scrolled some more, then it crashed Safari again.
In the spirit of not just grumping emptily, I did just get TFA to load on desktop. I'm grateful, Fernando, for the detailed dev-to-dev style here—and I admire your commitment to a high level of polish!
I wonder, though: you point out in the article—
> Achieving native feel in this area was tedious and challenging with React Native. When v0 iOS was in public beta, Apple released iOS 26. Every time a new iOS beta version came out, our chat seemingly broke entirely. Each iOS release turned into a game of cat-and-mouse of reproducing tiny discrepancies and jitters.
This feels like a treadmill of tiny rough edges that won't be going away anytime soon, especially with your (rightfully) world-class standards. And on Apple's timetable, too: it seems like each iOS evolution will likely introduce new elements of roughness, and they'll be iterating the OS through its release cycle without regard to how it interacts with your needs or workarounds. (A mental image of the winter sport of curling comes to mind)
If you were to do it all over again, would you think about building on native technologies instead? Or do the React Native benefits outweigh the native iOS UI polish, even though "we decided to share types and helper functions, but not UI or state management"?
> If you were to do it all over again, would you think about building on native technologies instead?
Although it took a lot of effort, it was a new set of UI patterns for React Native, and it hadn't really been done well yet.
Where most RN teams go wrong is they never dip to native code. On the contrary, we wrote a lot of native code, both for our own packages and for updating RN core itself.
The benefits with React Native's composition model are hard to beat. For example, thanks to React's composition with hooks and components, we will likely be able to open source most of the problems we solved into an easy-to-consume library. Or at least that's the hope!
In the spirit of not just grumping emptily, I did just get TFA to load on desktop. I'm grateful, Fernando, for the detailed dev-to-dev style here—and I admire your commitment to a high level of polish!
I wonder, though: you point out in the article—
> Achieving native feel in this area was tedious and challenging with React Native. When v0 iOS was in public beta, Apple released iOS 26. Every time a new iOS beta version came out, our chat seemingly broke entirely. Each iOS release turned into a game of cat-and-mouse of reproducing tiny discrepancies and jitters.
This feels like a treadmill of tiny rough edges that won't be going away anytime soon, especially with your (rightfully) world-class standards. And on Apple's timetable, too: it seems like each iOS evolution will likely introduce new elements of roughness, and they'll be iterating the OS through its release cycle without regard to how it interacts with your needs or workarounds. (A mental image of the winter sport of curling comes to mind)
If you were to do it all over again, would you think about building on native technologies instead? Or do the React Native benefits outweigh the native iOS UI polish, even though "we decided to share types and helper functions, but not UI or state management"?