Building v0 iOS and Fixing React Native Along the Way

Rojo describes Vercel’s approach as releasing once the core experience works, then improving it through frequent updates. The team explored several layouts, including a floating composer, before settling on a simpler three-pane interface. Feature flags let them compare designs on physical iPhones and merge changes while they were still evolving.

The team chose Expo and used EAS preview builds to iterate quickly, including while testing against iOS 26 betas. Because the web app was built first, much of its client code did not suit native, and getting React Native working in the existing monorepo took significant configuration work. The mobile app instead shares selected helpers and types, while relying on a typed API to access backend logic.

To make the app feel native, the team added custom native modules for features such as input behavior and glass effects. They rewrote PagerView in SwiftUI and investigated a modal flicker caused by asynchronous Yoga updates; the fix was upstreamed to React Native, with Shimon noting that React Native 0.82 included it. The team also patched or forked dependencies when needed, then worked to share fixes beyond the app.

Rojo says there are no immediate plans for Android, though the team wants to build it after the iOS experience feels polished. Keyboard handling, gestures, and UI details differ across platforms, and the app relies on iOS ScrollView behavior that React Native does not expose for Android. The team distinguishes shared features, such as sending a message, from platform-specific interactions that need to feel right in users’ hands.

The team dropped its floating composer after testing revealed that people could not easily find their chats. Oscar describes rewriting the implementation in an 8,000-line change, then splitting it into about 15 smaller pull requests. Rojo’s broader approach is to move complicated fixes into reusable libraries and upstream them where possible, while keeping app code simple.