Meta invented React Native-so why did Threads go fully native?
A pragmatic look at Meta’s tech choices, what it means for their other apps, and whether “native always wins.”
When Facebook (now Meta) open‑sourced React Native in 2015, it popularized a compelling idea: build mobile apps with React and JavaScript, yet render platform‑native UI. React Native quickly moved from experiment to production inside Meta (e.g., Ads Manager) and across the industry. (React)
Fast‑forward to July 2023, when Meta launched Threads at breakneck speed-and surprised many engineers by not using React Native for the mobile clients. Meta’s own engineering write‑up is unambiguous: “The Threads mobile apps themselves were built primarily with Swift on iOS, and Jetpack Compose on Android.” (Engineering at Meta)
If Meta “invented” React Native, why did its newest, fastest‑growing social app ship with fully native code? Are they abandoning their own framework? And does this mean native always wins?
Let’s unpack the story with the actual data, quotes, and context.
The short version: Threads is native, but Meta hasn’t “abandoned” React Native
First, the facts:
Threads chose native (Swift, Objective‑C where needed; Kotlin/Jetpack Compose on Android). This came directly from the Threads team: “The apps are largely native, using a mix of Swift on iOS (and a little Objective‑C), and Jetpack Compose on Android.” (Pragmatic Engineer)
Meta still invests heavily in React/React Native. In 2024, Meta highlighted that “over five thousand people at Meta [are] building products and experiences with React every month.” The same post showcases major React Native projects on Meta Quest and beyond. (Engineering at Meta)
React Native’s New Architecture (0.76+) removes the old asynchronous “bridge,” enables synchronous native calls, and is already used in production at Meta (including surfaces inside the Facebook app and new Quest apps). (React Native)
In other words: choosing native for Threads does not equate to abandoning React Native. It reflects a tool‑belt mindset: pick the right tool for the specific job and constraints.
A (very) brief history: Meta and cross‑platform pragmatism
Meta’s mobile history is full of pragmatic course corrections. In 2012, Mark Zuckerberg famously called betting too much on HTML5 a “biggest mistake,” as Facebook shifted back to native to hit performance and UX bars the mobile web couldn’t meet at the time. (TechCrunch)
On iOS, Meta built its own declarative native UI frameworks-ComponentKit on iOS (and Litho on Android)-to get React‑style composability with platform performance. That change alone delivered a 50% performance improvementfor News Feed, according to Meta’s account of evolving the Facebook iOS architecture. (Engineering at Meta)
Meta also performs massive native rewrites when the cost–benefit is clear. Project LightSpeed rebuilt Messenger for iOS, making it “twice as fast to start and one‑fourth the size,” while reducing core code by 84% (1.7M → 360k LOC). The guiding principle: use the OS where possible. (Engineering at Meta)
On Android, Meta moved from Java to Kotlin at scale-first to more than 10 million lines of Kotlin across the family of apps, then continuing that conversion with automation and, in 2025, even joining the Kotlin Foundation as a gold member. (Engineering at Meta)
This is not the picture of a company that “preaches one framework for everything.” It’s an engineering org that builds-and adopts-whatever helps teams ship high‑quality experiences at scale.
So why did Threads go native?
If you read Meta’s engineering posts and interviews with the Threads team, a pattern emerges:
Greenfield + time‑to‑market pressure. The team had roughly five months to take Threads from first line of code to shipping. Native Swift/Compose, plus reusing a lot of Instagram/Meta infra, let them move fast without fighting cross‑platform abstractions they didn’t need. (As the team put it, “code wins arguments.”) (Engineering at Meta)
Reusing battle‑tested internal building blocks. Threads sits on Instagram’s backend stack (Python/Django, plus GraphQL into Meta’s larger infra) and used internal UI and infra libraries where it made sense. Native helped them plug directly into those systems with fewer integration layers. (Pragmatic Engineer)
Modern native UI frameworks were a force multiplier. On Android, Jetpack Compose; on iOS, Swift (and a bit of Objective‑C). The team credits those choices with the speed of development and quality. (Pragmatic Engineer)
Performance and reliability targets from day one. At Threads’ scale (100M users in five days), avoiding extra runtime layers for initialization and rendering was a pragmatic choice. Native helped minimize cold‑start complexity. (Engineering at Meta)
Does this mean React Native couldn’t have worked? Not at all. It means native was the lowest‑risk path for this specific, high‑stakes, greenfield sprint-and it fit the team’s experience and Meta’s infrastructure especially well.
Are they going to switch everything else to native?
Unlikely. Two reasons:
Meta is investing in both directions. On the native side, they’re all‑in on Kotlin (including large‑scale automated conversions and Kotlin Foundation membership) and on iOS they’ve long been deep in Swift, Obj‑C(++), custom plugins, and build tooling. (Engineering at Meta)
React Native remains strategic. Meta keeps shipping React/React Native across platforms-from Meta Questapps to the Meta Horizon mobile app-and reports performance on par with its biggest mobile social apps. They also note thousands of Meta engineers building with React monthly. (Engineering at Meta)
Outside Meta, companies like Shopify have gone all‑in on React Native, reporting strong performance and stability: “Our apps are blazing fast (<500ms screen loads) and stable (>99.9% crash‑free sessions).” Even there, Shopify stresses: “100% React Native should be an anti‑goal.” (Shopify)
Prediction: Meta will continue the hybrid, per‑surface approach. New greenfield apps with hard performance/latency asks-and teams steeped in native tooling-may skew native. Large, multi‑platform surfaces with shared UI/logic and strong cross‑team reuse incentives will continue to lean on React Native (especially with the New Architecture maturing). Their own public write‑ups show both happening in parallel. (Engineering at Meta)
Does native always win over frameworks?
No. Native often wins for certain classes of problems, but “always” is too strong. Here are the patterns that consistently show up in real systems:
When native tends to win
Cold start and binary size are existential. Messenger’s rewrite is a textbook example: cutting to “twice as fast to start and one‑fourth the size” depended on using the OS frameworks directly and cutting layers. (Engineering at Meta)
You need deep, new OS features-right now. When Apple/Google ship brand‑new APIs or constraints (e.g., widget limits, background modes), native SDKs are first‑class, and framework layers may lag. Meta’s iOS team literally advises “use the OS” where possible to reduce complexity and keep up with platform evolution. (Engineering at Meta)
Ultra‑tight loops and heavy animations. High‑fidelity, zero‑jank experiences (camera pipelines, complex media transitions) are easier to eke out in native, with direct control over threads, memory, and GPU. Meta’s choice of Compose/Swift in Threads reflects this bias for speed and fidelity. (Pragmatic Engineer)
Extreme scale, longevity, and build/tooling control. Facebook iOS’s architecture shows a decade of native‑first modularity, codegen, and build systems (Buck), designed to support hundreds of engineers without regressions. That kind of industrialization is native at the core. (Engineering at Meta)
Language/runtime strategy. Meta’s move to Kotlin broadly (and Swift on iOS) reduces null‑safety issues, improves dev experience, and unlocks modern language features across millions of lines. This is a platform bet-not a short‑term experiment. (Engineering at Meta)
When React Native (and similar frameworks) tend to win
Speed to market + smaller teams. A single product team can reach iOS and Android with shared UI and logic. Instagram’s own 2017 case study reported 85–99% code sharing on several shipped features (e.g., Post Promote, Comment Moderation), with neutral crash/OOM metrics compared to native. (Instagram Engineering)
Cross‑platform portfolio leverage. Meta reuses React/React Native across web, mobile, desktop, and mixed reality, and has built tooling (StyleX, React Strict DOM, Hermes, RN DevTools) to make it sustainable at scale-again showing that it can meet high internal performance bars. (Engineering at Meta)
Developer velocity and talent portability. Organizations with big React/web DNA can deploy to mobile without staffing two parallel platform teams. Shopify cites productivity gains, easy staffing across web and mobile, and <500ms P75 screen loads-evidence you can hit quality bars with RN when you invest correctly. (Shopify)
Brownfield adoption. RN shines when you embed it into an existing native app for specific surfaces, gradually sharing code where it makes sense-precisely how Instagram and Facebook have used it over the years. (Instagram Engineering)
What about the “React Native is slow” trope?
Much of the older conventional wisdom predates React Native’s New Architecture: Fabric renderer, TurboModules, and JSI remove the classic “bridge” bottlenecks and permit synchronous native access when needed. Meta explicitly states the New Architecture is used at scale internally. In short: modern RN can achieve responsiveness and concurrency characteristics that weren’t feasible in 2017. (React Native)
And the “framework sprawl” problem?
It’s real. Even Shopify stresses you should keep native expertise on the team and resist aiming for “100% RN.” That mix-native + RN-is what tends to work best in practice. (Shopify)
Did Meta “not practice what they preach”?
It depends on what you think they preach. Meta’s public posture has long been pragmatic: use React where it’s the best fit; invest in native infra where that pays off; and re‑write when data proves it’s worthwhile. Their own mantra from the Threads story-“Code wins arguments”-captures it well. (Engineering at Meta)
For Threads, native was the fastest, lowest‑integration‑risk path to a polished 1.0 that could survive 100M signups in five days. (Engineering at Meta)
For Quest and Horizon, React Native powers flagship experiences, including rich animations and 60fps UI in desktop tooling (RN for Desktop + C++ renderers). (Engineering at Meta)
For Facebook/Instagram, both native and RN continue to coexist: deep native architectures (ComponentKit/Litho, Kotlin/Swift) alongside production RN surfaces and shared React infra. (Engineering at Meta)
That’s not hypocrisy; that’s portfolio engineering.
A practical decision framework (the checklist teams actually use)
If you’re deciding between native and a cross‑platform framework like React Native, weigh these:
Time to market & team composition. Do you have strong web/React talent you can mobilize? Or a seasoned native team fluent in Swift/Kotlin/Compose/SwiftUI?
Performance envelope. Are cold‑start budgets and animation budgets tight enough that every millisecond counts? Native is often simpler here. If not, RN (New Architecture) may be plenty.
Platform‑specific features. Heavy use of OS‑specific APIs (widgets, intents, low‑level camera/ML, background services) pushes you toward native-or RN with custom native modules.
Code sharing surface. How much UI/business logic can be shared across platforms or surfaces (web, desktop, MR)? The more sharing, the more RN pays off.
Long‑term maintainability. Consider upgrade cadence (iOS/Android annual releases), dependency risk, and internal tooling. “Use the OS” for core concerns is still a winning heuristic. (Engineering at Meta)
Organizational fit. Do you have infra (build systems, perf tooling, crash analytics) that favors one path? Meta’s ability to make both native and RN sing is rooted in enormous internal tooling.
Data, not dogma. Prototype both ways; measure cold start, interaction latency, and build/test cycles. As Meta puts it, “Code wins arguments.” (Engineering at Meta)
Bottom line
Meta didn’t “stop practicing what it preached.” It never preached one framework for everything. Threads is native because that was the fastest, surest path for that product and team. (Engineering at Meta)
React Native is alive and well at Meta (and across industry), bolstered by a New Architecture that addresses older performance pain points. (Engineering at Meta)
Native does not always win-but it often wins when cold start, binary size, brand‑new platform features, and ultra‑tight animations matter most. Conversely, cross‑platform wins when you need to move fast with shared code and smaller teams, and you invest in the right infra. (Engineering at Meta)
Or, to borrow the simplest summary possible from Shopify and Meta alike:
“100% React Native should be an anti‑goal.” Use RN and native together. (Shopify)
“Over five thousand [Meta engineers] build with React every month.” Use the right tool for the job. (Engineering at Meta)
And remember: in the end, code wins arguments. (Engineering at Meta)