The framework reversal is not the reusable part.
Shopify says React Native delivered the benefits it wanted after going all-in in 2020: one implementation, broader contributor access, and less feature-parity chasing. It now argues that improved coding agents reduced those advantages enough for its own apps to favor Swift and Kotlin, while explicitly acknowledging that native still means maintaining two platforms.[1]
That is a company-specific architecture decision, not permission to feed your cross-platform stack into the crusher. Shopify had large apps, native specialists, mature product behavior to copy, and the budget to build migration machinery. The general lesson is not rewrite native. It is reprice old abstractions when a core assumption changes.
Do not copy the destination. Copy the instrument panel that made the destination testable.
The actual upgrade is a second control surface.
Shopify describes simulator control as a bottleneck: agents could change code quickly but spend minutes testing through accessibility trees or screenshots. Its response was to decouple business logic from the UI, run that logic headlessly on desktop, and expose state, navigation, and actions through a CLI; simulator-connected commands remain available when end-to-end interaction is necessary.[1]
This is not “skip the interface.” It is interface pluralism. Humans get pixels, gesture, motion, and accessibility. Agents get structured state and deterministic verbs. Both surfaces must meet at the same behavior contract. A hidden CLI that drifts from the product is not a test port; it is a second app with no customers.
Fast feedback still needs a visual customs booth.
In Shopify's detailed Shop migration report, a six-engineer core built foundations and main journeys, then feature teams joined to validate their areas and edge cases. The team says it preserved behavior and analytics continuity, compared startup, stability, size, build time, and rendering, and used native expertise alongside linting, tests, static analysis, performance checks, and review.[2]
The interesting tooling detail is Tardis: structured access to live events, logs, state, and commands, plus named checkpoints that captured screenshots and event windows from the old and new apps. Plans were accepted against a content hash, so changing a reviewed plan invalidated the old approval.[2] That is a grown-up feedback stack: machine-readable steering for speed, visual and event parity for product truth, and explicit invalidation when the contract moves.
Recurring agents make the slow loop a reliability bug.
VS Code 1.137 added preview Automations for hourly, daily, weekly, or on-demand agent tasks, along with queued messages between busy chats and workspace attachment that can use an isolated worktree. The release labels several surfaces Preview or Experimental and notes gradual rollout.[3]
Once work can start on a clock, “somebody will click around later” is no longer a feedback strategy. An unattended loop needs a cheap first gear that catches obvious behavior failure, a structured second gear that explains state, and a bounded route into expensive UI parity and human review. The exact mix depends on risk. The requirement is that every fast lane eventually rejoins observable product behavior.
Build the port before you buy a faster engine.
Start with one user journey. Name its input, state transitions, side effects, analytics events, and visible checkpoints. Make those facts queryable without scraping the screen. Add deterministic fixtures. Then prove the structured path and the real UI agree at a few meaningful boundaries.
The Hacker News thread on Shopify's announcement is useful as practitioner reaction, not authority: people are debating rewrite risk, maintainability, native expertise, and whether the economics generalize.[4] Keep that skepticism. A vendor migration can be evidence that a technique worked in one garage without becoming a universal service manual.