Subtitle: AI makes maintaining two native apps easier. But for solo developers, that’s the wrong optimization. The real opportunity is combining AI with a shared codebase, instant feedback loops, native escape hatches, and OTA updates.
Shopify’s Back to Native essay triggered a predictable wave of hot takes: React Native is dead.
That conclusion is lazy.
Shopify’s post is serious engineering writing about a serious engineering organization. It is not a universal theorem for every mobile team shape.
The real conclusion is this:
AI didn’t kill React Native. It changed the economics.
And for solo developers, those economics are now more favorable than before.
1) AI reduces the cost of duplicate code. It does not eliminate duplication.
This is the core confusion.
Yes, modern coding models lower the pain of writing the same feature twice in Swift/Kotlin. But lower pain is not zero cost.
You still pay in:
- duplicated bug surfaces,
- duplicated release coordination,
- duplicated test maintenance,
- duplicated architectural drift,
- duplicated context switching.
AI speeds the typing. It does not remove the systems burden of owning two independent stacks.
If you are one person, the bottleneck is not keystrokes. It is total ownership bandwidth.
2) Shopify is solving an organizational problem a solo developer does not have.
Shopify’s flagship app is not a solo-developer SaaS companion app.
It is a large surface area product with 300+ screens plus platform-heavy features (widgets, lock-screen features, wearables, shortcuts/extensions), strict performance requirements, and many teams operating in parallel.
That is exactly where the native tradeoff can win.
Large companies optimize team throughput under organizational complexity. Solo developers optimize leverage under human limits.
Same tools. Different objective function.
3) AI + shared code is often more powerful than AI + duplicated code.
People frame this as:
- Option A: AI helps one React Native codebase.
- Option B: AI helps two native codebases.
But the strategic multiplier is usually in Option A for solo builders:
- one product model,
- one feature implementation path,
- one validation loop,
- one business logic layer,
- one deployment workflow.
AI amplifies whichever system you give it. If your system is unified, amplification stays unified.
4) Code generation is not the scarce resource anymore.
The scarce resource is:
- product judgment,
- prioritization,
- consistency,
- reliable release cadence,
- capacity to own end-to-end outcomes.
AI gives you code quickly in both worlds. The question is not “Can I generate two clients?”
The question is: Can I sustainably operate two clients while building the product itself?
For most solo teams, that answer is no.
5) React Native escape hatches are exactly where AI helps.
Historically, React Native pain concentrated in native edges: custom modules, platform APIs, build config weirdness, bridge friction.
Those are now areas where AI is surprisingly effective:
- scaffolding native module wrappers,
- translating platform docs into integration steps,
- drafting Turbo Module/Fabric-compatible boilerplate,
- debugging Gradle/Xcode configuration differences,
- generating targeted patches around edge-case APIs.
It does not mean zero friction. It means the friction profile changed in favor of small teams.
6) Expo deserves its own section.
If your mental model of React Native is frozen in 2020, you are missing the current stack reality.
Expo is no longer a “toy wrapper.” For many solo and small teams it is the practical operating system around React Native:
- modern build/deploy tooling,
- production-grade update infrastructure,
- mature module ecosystem,
- clear pathways for native customization when needed.
Crucially: you can start high-leverage, then drop to native only where warranted.
That gradient is exactly what solo builders need.
7) OTA updates are bigger than people admit.
The conversation often treats over-the-air updates as a convenience feature.
For small teams, OTA is a compounding speed advantage:
- faster iteration on JS/TS logic,
- reduced store-review latency for many changes,
- easier experimentation,
- faster bug turnaround.
When one person owns mobile, shortening iteration latency is not a nice-to-have. It is existential.
8) Fast Refresh matters even more with agent workflows.
As AI agents become part of your inner loop, rapid feedback gets more valuable, not less.
The shortest loop wins:
- prompt/plan,
- code generation/edit,
- immediate runtime feedback,
- tighten prompt or patch,
- repeat.
React Native + Fast Refresh keeps this loop tight in a way that aligns naturally with AI-assisted development.
9) “One codebase” means more than shared UI.
People reduce this argument to component reuse. That undersells it.
One codebase means tighter cohesion across:
- domain models,
- validation rules,
- state behavior,
- API contracts,
- telemetry semantics,
- failure handling patterns.
When those drift across two native clients, the maintenance debt is subtle and expensive.
10) Shopify’s performance argument is legitimate — but contextual.
The strongest pro-native argument is performance and platform depth under heavy constraints.
That is real.
But contextual performance optimization is not the same as universal framework invalidation.
You should absolutely choose native first when your product is dominated by:
- sophisticated graphics/rendering,
- games,
- intensive camera/video processing,
- Bluetooth/hardware interaction,
- complex background execution,
- deeply platform-specific experiences,
- Apple Watch / Wear OS-heavy products,
- extensive widgets, Live Activities, and platform extensions,
- extreme startup/memory/performance requirements.
Those cases are valid. Important. Common at scale.
They are just not the default shape of a solo-developer SaaS companion app.
11) Where I’d pick native today
If I were building the app classes above, I would seriously consider native-first architecture from day one.
That is not ideological. It is matching architecture to product physics.
But if I am a solo founder shipping a B2B companion app, internal operations app, creator utility, or workflow product?
The leverage curve still points hard toward React Native + Expo.
Closing: economics, not ideology
Shopify optimizes engineering.
A solo developer optimizes leverage.
A large company can rationally say:
“Native gives us 20% better X, and AI makes the additional engineering cost acceptable.”
A solo developer has a different equation:
“How much product can one person own?”
That is the real question.
And suddenly:
React Native + Expo + AI
becomes extraordinarily compelling.
React Native is not dead.
It is becoming a sharper instrument for the exact builders who care most about compounding speed with constrained resources.
The Professor’s Read
The market will keep producing dramatic “X is dead” narratives because narratives are easy and architecture is hard.
The durable signal is simpler: choose the stack that minimizes lifetime coordination cost for your team shape.
In the AI era, solo teams win by maximizing ownership per unit of attention. Right now, React Native plus Expo often does that better than maintaining two independent native apps.
References
- Shopify Engineering — Native is now the future of mobile at Shopify (2026): https://shopify.engineering/back-to-native
- Expo Docs — EAS Update Introduction: https://docs.expo.dev/eas-update/introduction/
- Expo Docs — Add custom native code: https://docs.expo.dev/workflow/customizing/
- Expo Changelog: https://expo.dev/changelog
- React Native Docs — Fast Refresh: https://reactnative.dev/docs/fast-refresh
- React Native Docs — Architecture Overview: https://reactnative.dev/architecture/overview
- React Native Docs — Performance Overview: https://reactnative.dev/docs/performance
- React Native Docs — Turbo Native Modules Introduction: https://reactnative.dev/docs/turbo-native-modules-introduction