Shopify is moving from React Native back to Swift and Kotlin

Original Article ↗ Hacker News Discussion ↗

Shopify is rewriting its mobile apps from React Native back to fully native Swift and Kotlin, arguing that modern AI coding agents have removed much of the historical cost of maintaining two codebases. Commenters see this as part of a broader shift: if LLMs can handle repetitive cross-platform work, large companies may favor native performance, tighter platform integration, and less framework overhead, even at the expense of losing a single shared stack. Others caution that parity, testing, and long‑term maintenance across platforms remain hard problems, and that for smaller teams the economics of React Native, Flutter, or web-based approaches may still be more compelling.

Perceived rationale for Shopify’s move

  • Many see the shift as primarily about escaping React Native’s “tax”: painful upgrades, dependency churn, and upstream framework instability.
  • Others argue the real driver is internal preference and politics, not just AI or objective cost.
  • Several note Shopify was already being forced into a major RN refactor (“New Architecture”), so reevaluating the stack was timely.

AI/LLMs and the economics of native

  • Widespread agreement that coding agents dramatically reduce the cost of building and porting native apps; multiple commenters report overnight or very fast RN → Swift/Kotlin ports of small–medium apps.
  • Supporters claim “one RN app vs two native apps” is now a false tradeoff: AI can maintain both, especially if specs and tests are shared.
  • Skeptics counter that AI also makes RN cheaper; the parity/maintenance cost over years is still unclear and unproven.

React Native, Flutter, and alternatives

  • RN is described as workable but fragile: frequent breaking changes, awkward upgrades, uneven library quality, and performance/UX penalties, especially on Android.
  • Flutter gets both praise (“still loving it”) and dismissal (“dead-end”), with some saying its Skia-based stack is inherently heavy.
  • Kotlin Multiplatform, Rust+UniFFI, and native .NET are mentioned as better ways to share core logic while keeping native UIs.

App Store review, OTA, and deployment

  • Strong disagreement about current iOS review times: some report <24h, others 2–7+ days and high variance.
  • RN’s over-the-air (OTA) updates are seen as a huge practical advantage for fast bugfixes and compliance-driven changes; critics of the move worry Shopify is giving that up.

Parity, complexity, and organizational cost

  • Multiple commenters say the hardest part isn’t initial rewrite but keeping iOS/Android behavior aligned over years: experiments, analytics, accessibility, edge cases.
  • Shared specifications and tests are viewed as necessary but their long‑term effectiveness is “unclear”; people want hard numbers (hours, defect rates, drift incidents, model spend).

AI, quality, and security concerns

  • Some embrace “agentic” development and barely read Swift/Kotlin output, relying on tests and additional model-based reviewers.
  • Others warn this leads to unmaintainable “vibe-coded” native apps, with hidden bugs, security issues (secrets, OAuth, WebViews), and brittle code humans don’t truly understand.

Bigger trend

  • Many expect large, well-funded orgs to move back to native, while smaller teams and MVPs will stick with RN/Flutter/web.
  • Several predict a broader swing away from Electron and heavy cross-platform stacks as code becomes “cheap” but complexity and runtime bloat stay expensive.