This looks like a solidly built app, but having used React Native to ship production apps I really don't think its the way forward – nor spending development effort on making apps "look native" with Liquid Glass and the like. It's so much more brittle than building a web app, even with the impressive steps taken with e.g. the New Architecture.
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.
Updating React Native every few months with breaking changes, no official upgrade path but "diff the two versions and copy everything over", having to update something every few months because Google introduces some new bullshit (API level updates that break everything! 16 KB page size! no orientation lock for tablets! yay!), using dependencies that get deprecated because React Native comes with no batteries included (Expo seems better but it's 1) another vendor lock-in 2) difficult to use with third party SDKs and 3) was not in the state it's now when the development of our app was started)... man I hate React Native and mobile development with a passion. Sadly I'm stuck with it for now...
I use Flutter with seems to fix many of these issues, primarily because it's not in the npm ecosystem so I don't have random breakages everywhere, because like you I also was tired of React Native.
I'm curious how much y'all used AI in the development process of the app. Definitely a lot of thought put into the architecture as shown in the post here, what was the split of human written vs. AI-written code? Especially curious given v0 is intended for building with AI.
Really great writeup, super thoughtful! Been a v0 user and fan for awhile now, excited to give this a shot!
This sounds profound but really isn’t, how about if we have to ask what it is _in a forum already specialised to those who could be interested_ then it demonstrates a serious communication issue?
I clicked through to the app's website, linked immediately in the writeup [1]. It slowed my browser (Firefox) to a crawl for 10 seconds but ultimately had no information whatsoever. Clicked the FAQ at the bottom, where the first question is "What is this?", which seems silly to have to address in a FAQ. But to answer you: It's a coding copilot app. No idea why you'd use your phone for this.
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"?
I tried the app and dragging down on the content doesn’t dismiss the keyboard interactively like Messages, Safari or even ChatGPT does. That is usually the telltale sign that an app is not fully native, I haven’t see any cross platform framework succeeding with this particular behavior. Not the end of the world but still expected in Design Award runner ups.
After signing up with Apple sign-in, the app fails to load favorites, chats, fails to upload images and fails to submit issues. Something to look into.
Thanks for sharing, sorry about that. We had an issue on the backend with Apple sign in that we just fixed today. Mind signing out and back in to see if it's fixed?
> Our goal was to build an app worthy of an Apple Design Award [...] After weeks of experimentation, we landed on React Native with Expo to achieve this.
This reads more like a portfolio case study than a blog post for a company. Who is the audience of this post? Isn't one of the main value props of Vercel that you don't need to know technical details like this to launch a product?
This is an incredible write up and touches on a bunch of headaches I'm sure we've all hit with RN, so thanks.
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?
I'm not sure if React Native is much different from React itself, but a few things that made me give a side eye, when looking at this write up:
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
24 comments
[ 2.7 ms ] story [ 58.7 ms ] threadWhen 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.
Really great writeup, super thoughtful! Been a v0 user and fan for awhile now, excited to give this a shot!
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
Basically like Figma Make or Lovable, a vibe coding app, except now also on mobile, which is cool.
1: https://v0.app/ios
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"?
Are you on iOS 26.2 by chance? I'm currently investigating a regression on interactive keyboard dismissal specific to iOS 26.2.
Has a non-native app ever won an ADA?
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?
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