Shopify Left React Native for Swift and Kotlin. Duplicate Code Is Now a Trade-Off.

On September 10, Shopify said it is moving its mobile apps off React Native and back to Swift and Kotlin.^[1] The Shop app is already rebuilt. The Shopify app, with more than 300 screens plus widgets and an Apple Watch app, is underway.

Shopify was one of the largest and loudest React Native adopters, so the announcement got read as a verdict on the framework. It is not one, and the actual reason is more interesting: a cost that everybody had priced years ago moved, and Shopify went back and re-opened the decision that rested on it.

Why did Shopify move from React Native back to Swift and Kotlin?

Because agents changed what building the same feature twice costs. Shopify adopted React Native in 2020 to "stop building the same features twice," let developers work across the stack, and spend less time chasing feature parity. It says the first of those three reasons no longer decides the question.

The post is unusually direct about the mechanics of its own reversal. "LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles."

It is also emphatic that this is not a framework complaint. The 2020 bet "has been extremely successful," React Native "remains an excellent framework," and Shopify says it wrote in January 2025 that the framework's future was bright.

That is the whole story in two sentences, and it is worth noticing what kind of claim it is. Not a claim about frameworks. A claim about a price.

What did Shopify not say?

It did not say duplication became free. Two sentences in the post do real work against the reading it is getting: "Native still means building and maintaining software on two platforms, that cost has not disappeared." And on pointing an agent at the old codebase to regenerate it, "it doesn't work."

The second one deserves the full quotation, because it is the opposite of the lesson most people took from this announcement. Shopify says that even if you have the agent gather context up front and freeze it into specs and task files, "you end up with a huge amount of unmaintainable code that can't be shipped."

So they built something. A system called Helix that migrates one screen at a time, proposing small ordered checkpoints, where each checkpoint "must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts."

Read that list again as a cost. Tests, a visual diff, two model reviewers, and a person, per slice.

So did the abstraction actually go away?

No. It moved up a layer. Shopify still avoids duplicated work, but the thing being shared is no longer the implementation: it is the specification, the tests, and the review checkpoints, which the post credits with "dramatically reduced the cost of maintaining parity between platforms."

That is a real and general result, and it is more useful than "cross-platform is over." An abstraction is a bet about relative costs: what the shared layer costs to maintain, against what doing the work more than once would cost. Shopify made that bet in 2020, the second number fell, and the bet stopped paying.

What replaced it is a different shared layer with a different cost profile. The spec and the gate are cheaper to maintain than a cross-platform runtime, and they do not fight the platform. They are also work that did not exist on the 2020 balance sheet.

That is human judgment as architecture rather than vigilance, built as a structure that will not pass unproven work.

Where do the AI gains actually stop?

At shipping. The best measurement available tracks more than 500,000 GitHub developers against their AI usage telemetry in a matched event study, and follows the effect down the production chain rather than stopping at the part that looks impressive.^[2] The effect shrinks at every step.

One number in that sentence needs its label attached. The 240% is the autonomous-agent arm measured on commits, and 80% and 30% are that same arm followed to projects and then to releases. One tool generation across three outcomes, not three tool generations compared.

(Separately, the paper reports 30%, 180% and 240% on commits for autocomplete, interactive agents and autonomous agents. That is the comparison most often mistaken for the ladder.)

The authors put a parameter on why it happens: an estimated elasticity of substitution of 0.23 between AI and human effort, which is their way of saying AI and human effort are complements that bottleneck on each other rather than substitutes that trade off. They call it the weak-link hypothesis.

Then the finding that should matter most to anyone planning around this. Across four major software marketplaces, the authors find a sharp increase in the number of new apps and no increase in total usage.

The paper was revised in September, so our August treatment of it carries the earlier figures.

What would actually settle Shopify's bet?

The second year, not the launch. Shopify's 12-week Shop rebuild is a build number, and duplication is not a build cost. It is an ownership cost, and it arrives monthly: two review queues, two dependency treadmills, two crash-triage surfaces, two release trains.

The practitioners in the thread went straight there. With 1,026 points and 699 comments inside a day,^[3] the top of the discussion was not about Swift:

The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync.

models can help you build native apps very quickly, no question. But how do you keep them from drifting apart from one another as you add/change features or design? Right now, there isn't much tooling for this.

The dissent is equally real, and it comes from people doing the work: several commenters reported porting apps with agents plus model review plus a manual pass and reaching Shopify's conclusion themselves. The honest summary is that the small-app case and the 300-screen case are different problems, and only one of them has been tested in public.

So the checkable question is whether Shopify's iOS and Android feature sets drift apart, whether the two codebases need one team or two, and whether parity work comes back as a line item. Parity chasing was one of the three problems React Native solved for them in 2020.

What should you do with your own shared layers?

Re-price them, one at a time, and count ownership rather than authorship. Most teams carry at least one layer whose entire justification was avoiding duplicate work: a shared component library, a monorepo package consumed by two services, an internal wrapper around one vendor's API.

Each of those was priced against a labor cost that has moved. The question is narrow:

• If writing the second copy were cheap, would we still build this layer? If the answer is yes, the layer is doing something besides avoiding duplication, and you now know what.
• What would we own instead? Shopify's answer was specs, tests and a review gate. That is a smaller bill than a cross-platform runtime, and it is not zero.
• Who notices when the copies drift? If the answer is nobody, the duplication is not cheap, it is deferred.

None of that argues for ripping out abstractions, and it does not argue that AI-built systems are fine. Our own reading is that they get harder to change as they grow, which is an argument for pricing ownership carefully, not for ignoring it.

For twenty years, "don't repeat yourself" was close to free advice, because repeating yourself was expensive. It is becoming a trade-off with two live sides, and Shopify is the first company at this scale to publish which side it picked and what it had to build to make the pick work.