Why React Native?.

Building Circus on mobile meant making a platform decision early: native per platform, or cross-platform once. I chose React Native, and here’s the honest reasoning.

The case for cross-platform

A solo mobile developer cannot maintain two codebases. Native iOS and native Android is the right answer when you have the headcount — and the wrong answer when you don’t. React Native lets me write once, ship to both, and stay in TypeScript I already know.

The gains are real:

• One codebase, two stores. Feature parity ships at the same time, not six weeks apart. Every product decision gets implemented once.
• Shared business logic. API clients, data models, authentication flows, state management — written once, tested once, behave identically on both platforms.
• Web team contribution. Engineers who work on circus.app can read and contribute to the mobile codebase without a platform context switch. TypeScript and React patterns transfer directly.
• JavaScript ecosystem. The package ecosystem for React Native is large and well-maintained. Most things I need already exist.

The New Architecture

React Native’s New Architecture — Fabric for the renderer, JSI for the JavaScript interface — meaningfully changed the performance story. The old bridge was asynchronous by default, which created a class of frame-rate problems that were difficult to work around. JSI gives JavaScript direct, synchronous access to native APIs.

I’m targeting 60fps on mid-range Android and hitting it consistently in current builds. The animation-heavy parts of the app — feed transitions, community header collapse, the post composer — all run on the UI thread via Reanimated, which bypasses the JS thread entirely for animations. Performance-critical interactions feel native because, at the rendering layer, they are.

Who’s using it

React Native is the framework behind some of the most-used apps in the world. Shopify’s Shop app — their core consumer product — runs on it. Expensify, Discord, Microsoft Teams, and Meta’s apps all use React Native in production. These aren’t teams that lacked options — they evaluated the tradeoffs and chose React Native.

React Native holds a strong position across most markets. Flutter has grown fast and leads in China — Alibaba and ByteDance built heavily on it early — but React Native’s JavaScript roots keep it dominant everywhere else.

React Native over time

npm weekly downloads have grown steadily year-on-year. React Native isn’t declining — it’s still the default cross-platform choice for JavaScript teams.

Developer adoption

Among trained mobile engineers, React Native and Flutter lead — with React Native holding a slight edge in markets where JavaScript familiarity matters.

Where we are

Both platforms are in active development. Builds are running on iOS and Android. The app is not yet in the stores — that comes at launch, when the platform is ready to deliver on what I’m promising. I’m not rushing it.

TikTok Lynx

Lynx is ByteDance’s internal mobile framework, open-sourced in early 2024. It was built specifically for TikTok’s performance requirements — content-heavy feeds, high frame rates, low latency interactions. It’s the most serious emerging competitor to React Native, and it’s worth understanding.

Companies using it: TikTok, ByteDance internal apps.

Pros: Extremely fast rendering — outperforms React Native on TikTok’s own benchmarks for content-heavy interfaces. React-like component syntax means web developers can read it without learning a new paradigm.

Cons: Brand new (2024). Tiny ecosystem. Effectively one corporate backer. The long-term commitment question is real — ByteDance built this for TikTok, not for the community.

Lynx is worth watching closely. For Circus — a community and social platform — the performance gains are genuinely interesting. But “open-sourced by one company in 2024” is not a foundation I’d bet a product on yet. Check back in two years.

The alternatives

React Native was the right call for me, but it’s worth being honest about the landscape. Here’s what the other serious options look like.

Flutter

Google’s cross-platform framework, built on the Dart language with its own renderer (Skia, now Impeller). Flutter renders every pixel itself — it doesn’t use native UI components, which means pixel-perfect consistency across platforms but a slightly different feel from the OS’s own apps.

Companies using it: Google Pay, Google Classroom, Alibaba (Xianyu), Nubank, BMW, eBay.

Pros: Consistent rendering everywhere, strong performance, well-maintained, growing ecosystem.

Cons: Dart is a separate language from everything else I write. No code sharing with the web frontend. App binaries are larger. UI doesn’t follow platform conventions by default.

Flutter leads globally in raw numbers — particularly in China, where Alibaba and ByteDance built heavily on it early. If my stack was Dart-first, Flutter would be a serious contender.

SwiftUI

Apple’s native UI framework for iOS and macOS. If you’re building iOS-only and want the closest possible integration with the platform, nothing beats it.

Companies using it: Apple’s own apps, Things 3, Fantastical, Duolingo’s iOS team.

Pros: Best-in-class iOS fidelity. Deep integration with Apple APIs. First-party tooling, no third-party dependency risk.

Cons: iOS and macOS only. No Android, no web. For Circus — a two-store app — this means two completely separate codebases.

SwiftUI is the right answer for a different kind of app. Not for this one.

Kotlin Multiplatform / Compose Multiplatform

JetBrains’ approach to cross-platform: share business logic (data models, API clients, state) across iOS and Android while keeping fully native UI on each platform. Compose Multiplatform takes it further by sharing the UI layer too, though that’s still maturing on iOS.

Companies using it: JetBrains apps, Cash App (shared logic layer), VMware, Touchlab-built apps.

Pros: Full business logic sharing, fully native UI per platform, strong type safety, no JavaScript.

Cons: Compose Multiplatform UI is still in beta on iOS as of 2024. Requires Kotlin familiarity — no overlap with my TypeScript codebase. More operational complexity than a single-language stack.

KMP is compelling for teams with strong Android/Kotlin roots. For a TypeScript-first stack, the context switch is expensive.

---