Why teams are dropping cross-platform frameworks in 2026, and when your team should follow

Shopify announced on 10 September 2026 that it is moving every mobile app from React Native to Swift and Kotlin, crediting coding agents with removing the cost of building each feature twice; six engineers rebuilt the Shop app in 12 weeks, cutting iOS cold start 23% (3,200 ms to 2,466 ms) and Android cold start 50% (4,433 ms to 2,233 ms). The merchant Shopify app, with more than 300 screens, is announced for later this year, while Point of Sale and Inbox are named with no date. GitHub separately finished removing CSS-in-JS from github.com in June 2026 for runtime cost, not because of agents, and the author's 10 October 2026 recommendation is to keep a working React Native app unless business logic already runs without the UI and the team can review both native codebases.

Why teams are dropping cross-platform frameworks in 2026, and when your team should follow On 10 September 2026, Shopify said it is moving every mobile app from React Native https://stackness.dev/tools/react-native to Swift https://stackness.dev/tools/swift and Kotlin https://stackness.dev/tools/kotlin . It credits coding agents: with them, "building the same feature in Swift and Kotlin no longer carries the cost it used to". Six engineers rebuilt the Shop app in 12 weeks. GitHub finished removing CSS-in-JS from github.com in June 2026 for a different reason: runtime cost. My recommendation as of 10 October 2026 is to keep a working React Native app unless two things are true: your business logic already runs without the UI, and your team can review both native codebases. Move off runtime CSS-in-JS either way. Why are teams dropping cross-platform frameworks in 2026? Teams are dropping cross-platform frameworks in 2026 because coding agents cut the cost of writing each feature twice, and avoiding that cost was the reason to share one codebase. That is Shopify's argument, and as of 10 October 2026 it is the only large exit with a published write-up and numbers that I found. Even Shopify writes that the cost of two platforms "has not disappeared". Shopify's 2020 post https://shopify.engineering/react-native-future-mobile-shopify chose React Native to "Stop building the same features twice". By January 2025 it had moved every app https://shopify.engineering/five-years-of-react-native-at-shopify to it. The 2026 post https://shopify.engineering/back-to-native by Mustafa Ali keeps the goal and changes the means. In its words, "agents have reduced the advantages of sharing implementation, while the advantages of building for each platform remain." Shopify does not blame speed: "React Native apps can be fast. Ours are." The Hacker News thread https://news.ycombinator.com/item?id=49643982 reached 1,275 points and 957 comments. What has shipped is narrower than the headlines: - Shipped: the Shop app. - Announced for "later this year": the merchant Shopify app, with more than 300 screens. - Named with no date: Point of Sale and Inbox. Shopify rebuilt the Shop app in 12 weeks with six engineers Shopify rebuilt its Shop app natively in two stages. One engineer spent a week with coding agents porting as much of the React Native app as possible into SwiftUI https://stackness.dev/tools/swiftui . Then a core group of six engineers took 12 weeks from that proof of concept to the app stores, with Jetpack Compose https://stackness.dev/tools/jetpack-compose on Android and feature teams joining midway. The companion post https://shopify.engineering/shop-app-migration holds every number below. | Shop app | React Native | Native | Change | |---|---|---|---| | Cold start, iOS | 3,200 ms | 2,466 ms | -23% | | Cold start, Android | 4,433 ms | 2,233 ms | -50% | | Session stability | 99.5%+ | 99.95%+ | 10x fewer crashing sessions | | App size, Android | 293 MB | 184 MB | -109 MB | | App size, iOS | 67 MB | 68 MB | +1 MB | | Android release build | | | about 75% faster | The agents ran through a migration workflow built as an extension for the Pi https://stackness.dev/tools/pi coding agent. Alongside it, an internal tool called Tardis captured screenshots and analytics events from both apps so agents could compare them. Shopify warns against the shortcut: asking an LLM to "one-shot the same features in native" from the React Native code "doesn't work". Business logic had to be decoupled from the UI and run headless on a desktop, so agents could test in milliseconds without a simulator. Shopify did not publish the share of code agents wrote, the models it used or what the port cost. GitHub dropped CSS-in-JS for runtime cost, not because of agents GitHub replaced styled-components https://stackness.dev/tools/styled-components , used through the sx prop of Primer https://stackness.dev/tools/primer React, with CSS Modules https://stackness.dev/tools/css-modules and theme variables from Primer CSS. The site has run on 100% CSS Modules since June 2026. GitHub's 25 September post https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/ gives performance as the reason and does not argue that agents make duplication cheap. After Primer's own components moved, GitHub measured 55% less time to render a page on the server and 25% less time for components to initialize. Removing sx from product pages cut server render time by 1% to 22% on the pages GitHub measured. GitHub gives no INP, LCP or bundle numbers. The work took two stages: - Codemods: a rotation of 8 engineers moved 6,419 sx props over six months, mostly with codemods. - Agents: two engineers and "a whole lot of Copilot coding agents" removed the last 895 in three weeks. Agents cleared the long tail of a move GitHub had started in 2023, when component counts on some pages began to slow server rendering. Three options and what each commits the team to A tech lead with a working cross-platform app has three real options on mobile, plus one separate decision on the web. Each option keeps something and gives something up. The table lists who has shipped each one. | Option | You keep | You give up | It commits you to | Shipped by | |---|---|---|---|---| | React Native on the New Architecture, with Expo https://stackness.dev/tools/expo | One codebase, over-the-air updates, one TypeScript hiring pool | Day-one platform APIs, some startup time | Upgrading the framework every release | 78.6% of State of React Native respondents have migrated to the New Architecture | | Native Swift and Kotlin, ported by agents | Platform APIs, faster startup | Parity enforced by code, over-the-air updates, hot reload | Two codebases, a parity check on every release, headless business logic | Shopify's Shop app, September 2026 | | Kotlin Multiplatform https://stackness.dev/tools/kotlin-multiplatform for logic, native UI | Shared business logic, native UI | One UI codebase | Kotlin on iOS and its tooling | Google Docs on iOS, May 2025 | | Web: CSS Modules or zero-runtime CSS instead of runtime CSS-in-JS | Server rendering without style injection | Co-located JavaScript styles, runtime theming | Rewriting every styled component, themes as CSS variables | GitHub, June 2026 | Sources: State of React Native 2025 https://results.stateofreactnative.com/en-US/ 733 of the 932 who answered; the survey is run by a Software Mansion engineer, and Software Mansion sells React Native work , Google on Kotlin Multiplatform https://android-developers.googleblog.com/2025/05/android-kotlin-multiplatform-google-io-kotlinconf-2025.html . Does writing platform code twice cost less now that agents do the porting? Writing platform code twice costs less to type now, but nobody has published what it costs to keep correct. The most detailed public bill for an agent port is GitHub's Copilot runtime port https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/ . About 430,000 lines of TypeScript https://stackness.dev/tools/typescript became 832,378 lines of Rust https://stackness.dev/tools/rust in 14.5 weeks. It cost about $120,000 in tokens plus three weeks of one developer's time. That port was a language migration, not two codebases kept in sync, and its author, Stephen Toub, puts the cost where Shopify does: "Porting code is easy. Making it correct is hard." It shipped with dozens of regressions, all fixed by 14 September. Microsoft sells GitHub Copilot https://stackness.dev/tools/github-copilot , so read the bill as a vendor's own. The other numbers are anecdotes. On Hacker News, one developer reported getting 90% of a 15 to 20 screen React Native app ported overnight with OpenAI Codex https://stackness.dev/tools/codex-cli , and added: "And I don't know Swift or Kotlin." A team in that position cannot review what the agent wrote. The port is a one-off cost, and every feature after it is two features to review. I found no controlled study comparing two agent-maintained codebases with one shared codebase. Parity becomes a process instead of a property of the code Dropping a cross-platform framework turns feature parity into something the team checks on every release, because no shared codebase enforces it anymore. Shopify says so directly: React Native "enforced this through a shared codebase", and parity now runs "through our development and release process", with agents comparing screenshots and analytics events from both apps. The rest of what goes with the layer: - Over-the-air fixes. Expo's EAS Update ships JavaScript fixes without store review. Native fixes wait for review. - Hot reload. Shopify called it "a total game changer" in 2025 and described native compile cycles of several minutes. In 2026 it built a headless CLI so agents could skip the simulator. - One hiring pool. TypeScript let web developers ship mobile features. - Libraries. Shopify is handing off or archiving the React Native libraries it maintained by the end of 2026. On the web, CSS-in-JS gave GitHub co-located styles and TypeScript-checked design tokens. Theming had to move to CSS variables, which took about two months for seven themes. Shopify's numbers compare native with an older React Native Shopify's 23% and 50% faster cold starts compare the native Shop app with a React Native build that had not adopted the New Architecture. The app also lost some screens in the rebuild, which Shopify says it retired on purpose. A team already on the New Architecture should not expect the same gap. Shopify measured its other apps after they moved to the New Architecture in September 2025, and launch got about 10% faster on Android and 3% on iOS. The new stack is also young: - Shipped: one app. - Not yet: the 300-screen app. - Not yet reported: the outcome Shopify says it will judge the move by: "product velocity, app quality, and how much work agents can complete autonomously". Runtime CSS-in-JS is leaving stacks; React Native and Expo are not Runtime CSS-in-JS is the abstraction layer clearly leaving stacks. Between October 2025 and October 2026, styled-components fell from 15.0% to 5.8% of React's weekly npm downloads, and Emotion https://stackness.dev/tools/emotion from 25.5% to 10.9%. React Native slipped only from 8.3% to 7.6%, and Expo rose from 4.1% to 5.6% of React https://stackness.dev/tools/react . Raw downloads rose for every package, React's fourfold, so I compare each with React. Downloads are not users. The styled-components maintainer has advised against it for new projects since March 2025 https://opencollective.com/styled-components/updates/thank-you , though a v7 alpha with React Server Components support is in progress. React's own docs recommend against runtime style injection. Linear https://stackness.dev/tools/linear is moving its app from styled-components to StyleX https://stackness.dev/tools/stylex , and the engineer writing it up https://www.skovhus.dev/blog/moving-linear-from-styled-components-to-stylex reports "plenty of styling regressions along the way". Tailwind CSS https://stackness.dev/tools/tailwind-css rose from 58.3% to 72.2% of React's downloads. Stackness records when a tool enters and leaves a stack, but its own sample cannot date this trend yet. As of 10 October 2026, no real public profile lists React Native, Kotlin or a CSS-in-JS library. The only profile listing React Native, Swift and Flutter https://stackness.dev/tools/flutter is a bot. The one real Swift entry ran from 2015 to 2019. Tailwind CSS is listed by 7 real profiles data sources https://stackness.dev/about/data-sources . As the sample grows, the languages and frameworks developers list https://stackness.dev/categories/languages-frameworks and what is trending https://stackness.dev/trending will show removals as they are recorded. The related move is reaching for native platform features before JavaScript workarounds https://stackness.dev/moves/reach-for-native-platform-features-before-javascript-workarounds . What would change the recommendation The recommendation to keep React Native rests on missing evidence, so it should change when that evidence arrives: - Shopify's results. A report on velocity and quality after six months of native development, or the 300-screen Shopify app shipping, would move me toward native. - A second exit. Another large team publishing a port with its agent costs would do the same. - The platform API gap. If React Native 0.88 and Expo SDK 58 close it the SDK 58 beta adds App Intents from JavaScript , the case for native shrinks to startup time. - The CSS case. On the web, nothing short of styled-components v7 shipping stable server component support would change it. What I would do - Stay on React Native if the app is on the New Architecture, ships over-the-air fixes and is built by a TypeScript team that cannot review Swift or Kotlin, because review is the cost agents do not remove. - Upgrade before comparing if you are still on the old architecture. That is the comparison Shopify's numbers do not make. - Run a time-boxed native proof of concept if business logic already runs headless, someone can review each platform, and widgets, Watch apps or startup time cost you users. Shopify's took one engineer a week. Then measure the parity cost of a few releases before committing. - Share logic, not UI, with Kotlin Multiplatform if you want native UI without two copies of the business rules. - Leave runtime CSS-in-JS now if you run styled-components or Emotion with server rendering. Start with the design system components as GitHub did, behind feature flags with visual regression snapshots, and give agents the long tail. Tools in this post Use any of these tools? Put them on a Stackness profile, say how you use each one and see who pairs them the same way. It takes a couple of minutes. Show my stack https://stackness.dev/register