Shopify announced that its mobile applications are going back to Swift and Kotlin, after years as the most cited large-scale React Native success story. The announcement is on Shopify's engineering blog and it blew up on Hacker News: over a thousand points and nearly eight hundred comments in a single day. Simon Willison also picked it up on his site, which says plenty about how much noise it made.
Why it matters
The news isn't "React Native failed." The news is that the company that bet the hardest on React Native in public, the one that wrote the posts we all used to cite in meetings to justify the decision, changed its mind. And that breaks the appeal to authority a lot of teams had been leaning on without thinking too hard about it.
My read: cross-platform doesn't compete against native in the abstract. It competes against native in the context of a specific organization. Shopify has the money to hire separate iOS and Android teams. It has the user volume where every millisecond of startup time translates into money. It has apps that need to integrate with point-of-sale hardware. For that organization, the savings from sharing code stopped outweighing the cost of fighting the abstraction layer.
Your seven-person startup is not in that context. And that's the mistake I'm going to watch repeat itself over the next few weeks: someone is going to bring this post into a meeting as proof that everything should be rewritten in Swift, without having the team, the volume, or the problem Shopify had.
What changes in practice
First thing: it changes the conversation when you propose cross-platform. Before, naming Shopify was enough. Now they're going to ask you for an argument of your own, and deep down that's healthy. It forces you to be explicit about what you're buying and what you're paying for.
When someone asks me about mobile stacks, the real axis isn't "which one is better?" but this:
| Dimension | Cross-platform | Native |
|---|---|---|
| Up-front team cost | One team | Two teams, or one that alternates |
| Access to new OS APIs | You wait for the bridge | Day one |
| Performance ceiling | Set by the abstraction | Set by the platform |
| Debt you accumulate | In the bridge and in the patches | In duplicated logic |
| Hiring profile | Web devs you can retrain | Per-platform specialists |
Neither column wins. What changes is which of those costs your organization can absorb today. A small team absorbs the cost of two specialists badly and the cost of waiting for a bridge just fine. Shopify is in exactly the opposite position.
Second thing, and this one I find more interesting: the announcement is about mobile, not about React. The day before, React 19.3 shipped, with View Transitions, Fragment Refs, browser() and Trusted Types. Those are web features, for the DOM, solving web problems. React in the browser and React Native on the phone share a mental model and not much else. If you work in web frontend, this news doesn't touch you one bit, and it's not worth using it to second-guess your stack.
When NOT to use it
I'm going to be honest about both directions, because this is where the disaster gets built.
When not to follow Shopify to native:
- If your app already works in React Native and your users aren't complaining about performance. A migration is months of work that doesn't add a single feature to the product. Rewriting to copy someone else's decision is the worst possible reason.
- If you don't have people who seriously know Swift and Kotlin. Native written by someone who learned it last week performs worse than cross-platform written by someone who has mastered it.
- If your app is forms, lists and HTTP calls. There the abstraction ceiling is far above where you are. You're never going to hit it.
- If iteration speed is your competitive advantage. Two codebases means two releases, two store reviews, two QA cycles.
When not to choose cross-platform:
- If your product lives off a specific platform capability: camera with real-time processing, low-level Bluetooth, dedicated hardware, deep system widgets. You're going to end up writing native modules anyway, and then you have the worst of both worlds: the complexity of native plus the complexity of the bridge.
- If you need to adopt OS APIs the day they ship. The community takes time to port them, and that wait isn't under your control.
- If the team is going to grow into two squads per platform in the short term. At that point shared code goes from being a savings to being a point of contention between teams.
A warning about the data: Shopify's post has the technical details and the specific reasons. I didn't see performance numbers there that I could cite without making them up, so I'm not going to throw percentages at you. If the argument really matters to you, read the whole thing and check whether their reasons apply to your context. That's the entire exercise.
What I'd do today
Nothing. Literally nothing, if my mobile app is running fine.
The one thing I would do is an honest review of a single question: how much of last quarter did my team spend fighting the abstraction layer instead of writing features? If the answer is "almost none," there's no debate. If it's "half the sprint went into patching a native module," then Shopify's decision isn't your reason to migrate, but it is a good moment to do the math you'd been putting off.
Architecture decisions at big companies are data about those companies, not instructions for everyone else. Shopify isn't telling you what to do. It's telling you what happened to Shopify.