react/react-native

The problem

Cross-platform mobile development usually forces a choice: ship a web view and accept that gestures, text scaling and accessibility feel slightly off, or write and maintain two native codebases. React Native addresses this by letting you write UI in React while the primitives render to real platform views, so the parts users touch behave like native controls rather than a browser embedded in an app shell.

What's different

The distinguishing claim is "learn once, write anywhere" rather than "write once, run anywhere": the React component model, hooks and Suspense carry across platforms, but the rendering stays native. Compared with Flutter, which draws its own UI with a custom engine, React Native leans on platform widgets and therefore inherits OS behaviour and third-party native SDKs more directly. Compared with a WebView-based approach such as Cordova or Ionic, it avoids the browser layer entirely. The other real differentiator is the escape hatch: Native Modules let JavaScript call platform code synchronously and type-safely, so you are not stuck when a library does not exist.

Who it's for

Product teams already fluent in React who need a real mobile presence and cannot staff separate iOS and Android squads. It also suits existing native apps that want to adopt incrementally — the README explicitly documents integration with existing apps. Teams whose UI is heavily custom-rendered, or who need bleeding-edge platform APIs on day one of an OS release, may be happier in Swift/Kotlin or a self-rendering toolkit like Flutter. Web-only shops with no mobile roadmap gain nothing here.

Cost of adoption

The framework itself is MIT licensed and free, but the real cost is toolchain: Xcode and Android SDKs, native build pipelines, and platform-specific debugging. The README is candid that most teams should start through a Framework — it points to Expo and npx create-expo-app@latest — and that going framework-free means solving navigation, native dependencies and platform tooling yourself. Upgrades are a known ongoing tax; the docs maintain a dedicated upgrading guide. The README itself is thin on architecture detail and defers to the website, so budget reading time. As a 2015 project with roughly 127k stars, it is mature and heavily depended upon, but that also means breaking changes ripple through a large ecosystem.

Verdict

This is about as established as open source gets: created in 2015, ~126,776 stars and ~25,362 forks, with continuous stewardship via the React Foundation. The HotRepo signals are unremarkable rather than alarming — no daily trending appearance, no Hacker News threads, just a modest +421 stars on the monthly C++ board in October 2026, which for a project this size reads as steady background usage rather than fresh excitement. Interest is not fading, but it is no longer a novelty either; the practical question is ecosystem fit, not project health. If your team writes React and needs native mobile output, this is the default choice and the risk is low. If you need a small, single-purpose library, you are in the wrong repository — this is the core framework, not an app starter.