Building for All: App Rebuild with React Native
By DeHub Team — 2021-07-02
In Q3 2021 we started rebuilding the DeHub app from scratch in React Native.
Deciding to rewrite a working application is not a decision anybody enjoys. The beta was live, it had users, and every week spent on the rebuild was a week not spent on features those users were asking for. We did it anyway, and it is one of the few large calls from that period we have never revisited.
What was wrong with the first app
The beta was built to answer a question — will people use this at all — and it answered it. What it could not do was grow. Shipping to two platforms meant maintaining two codebases, which in practice meant one platform quietly falling behind, and every feature costing roughly double what it should.
For a team our size that is not a technical inconvenience. It is a cap on how fast the product can ever move.
Why React Native
The honest reason is team leverage. React Native let a small group ship to iOS and Android from one codebase without going fully native twice, and without the compromises of a wrapped web view — which for an app built around video and live content would have been fatal.
It also meant the mobile app and the web app could share a mental model, a component vocabulary and, in a lot of cases, actual logic. Four years later DeHub runs a React web app and a React Native mobile app maintained in parallel, and features cross between them at a pace that would not be possible if the answer in 2021 had been two native rewrites.
The parts that were harder than expected
Nobody should read this as a frictionless choice:
- Video is where the abstraction leaks. Playback, background audio and live streaming are exactly the areas where you end up in native modules regardless of the framework's promises.
- Wallet integration was the ongoing tax. Mobile wallet connection has been re-solved more times than any other part of the app, and remains the single most common place new users stall.
- Rewrites always take longer. The list of things the old app did that nobody had written down is only discovered by removing them.
Why it was still right
The rebuild is the reason the app survived everything that came next. When the arcade launched in Q1 2022, when the stream app arrived that summer, when the whole ecosystem was pulled into a single d'app in 2023 — none of those were a case of bolting onto the beta. They landed on a foundation deliberately built to take weight.
The lesson we took from it is not "rewrite early". It is that the moment you can name the specific ceiling your architecture puts on the team, you are already paying for the rewrite whether or not you have started it.
How to survive one
Two things made this rewrite finish rather than stall, and both are worth stating because most rewrites do stall.
The old app kept running. We did not stop shipping to existing users while the replacement was built. That extends the timeline and it removes the pressure that produces a rushed cutover, which is where rewrites usually die.
The scope was the architecture, not the product. Every request to also improve a feature while rebuilding it was declined. A rewrite that is simultaneously a redesign has two ways to fail and no way to tell which one is happening. The interface work waited until 2024, when it shipped properly as a full overhaul alongside a 200% backend improvement.