When nearly everything today is a walled garden, I find it really hard to understand why we'd want to fortify those walls with any more platform-specific code. Though it's imperfect and still in development, I see much more of a future in the open web platform and wasm.
Edit: Ah. If you go to the iOS Store, they reveal that it is an AI app. How mysterious. Why not just say that on your landing page
I wish them all the best but perhaps this just isn’t for me.
Basically like Figma Make or Lovable, a vibe coding app, except now also on mobile, which is cool.
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"?
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!
1. The instant 5 levels of providers (and additional one later) seems excessive.
2. The usage of useAnimatedReaction which seems almost like a "useEffect" kind of hook, which was sprinkled in almost every code block.
3. The imperative size calculations, does React Native not support any responsive like constructs? I recall solving the same problem by separating "history" and "tail" and having a "grower" component, without having to use any JS (purely html & css), albeit it being web and not native.
4. Personally, when I see something like the scroll code, where you have to call scroll, wait a frame, call scroll again, set a timeout, scroll again- I would have raised my eyebrows about the architecture / code flow way before that.
5. the amount of "floating" hook calls like useKeyboardAwareMessageList() useScrollMessageListFromComposerSizeUpdates() useUpdateLastMessageIndex()
that don't return anything, always makes me raise an eyebrow, usually in React Web codebases, where the users just spam useEffects and effect chains.
Not sure if it's just my ignorance in React Native, but if I had seen the equivalent in a React Web app, I would've been baffled
Has a non-native app ever won an ADA?
Watch Duty won with a Cordova app in the "Social Impact" category, so it's not impossible.
Are you on iOS 26.2 by chance? I'm currently investigating a regression on interactive keyboard dismissal specific to iOS 26.2.
textView.keyboardDismissMode = .interactive
I'm interested in how you're dealing with the live activity and share sheet. I always drop down to native code, but am wondering if you built those with RN as well?
You can just use Share.share() from react-native directly for the share sheet.
> A lot of react native apps do not feel native. Even more are just low quality. Many v0 users were asking us how exactly we did X or Y to make it feel so good, which is what this post is for.
https://news.ycombinator.com/item?id=46049137
---
And I mean, what's wrong with giving more detail on how to make good UX, for other developers to learn from too? I appreciated the level of detail in this post rather than many which skim over it.
Really great writeup, super thoughtful! Been a v0 user and fan for awhile now, excited to give this a shot!
We also used v0 for prototyping ideas and designs for the native app.
Something that attracts me to RN is that it's easy to drop down to native. We use SwiftUI for a number of components under the hood. But for a full app, React Native felt better.