How we built the v0 iOS app
In this technical retrospective (2025), @MaxLeiter shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Post-ZIRP & AI (2023–2026)
COMMUNITY SCORE ★ 34 points
TOTAL DISCUSSIONS 48 comments
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
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.
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.
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?
Man. I looked at their landing page. Skimmed the "how we did it" article. And I still have no idea what this app does – seems like chat of some sort?
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