Indie Vibe Makers: Expo vs Native Swift in 2026

What changed about this question?

The learning curve left it. The old indie calculus, “which stack can one person actually learn”, dissolved when agents started writing both fluently: Expo screens and Swift views generate with equal competence from the same design links, and the residual training-data edges are marginal (React Native’s web-adjacent patterns run slightly deeper; Swift’s newest APIs occasionally outrun the corpus). What remains is the question that always mattered more: which fits what you’re shipping, and four questions decide it.

What are the four deciding questions?

Question	Points to Expo	Points to Swift	Verdict
One platform or two?	Android too: one codebase, EAS, done	iOS-only: fully competitive	The biggest single factor
What’s the feature surface?	Screens, lists, forms, APIs	Widgets, watch, Intents, Live Activities, ARKit	Platform-native products are Swift products
How fast must you iterate?	OTA updates: fixes in minutes	App Store releases per change	The indie superpower question
Where do your instincts live?	JS/React muscle memory	Swift/Apple-platform fluency	Real, but now the smallest factor

Platforms is the heavyweight: shipping Android from the same codebase is Expo’s structural win, with EAS handling builds and submissions a solo builder should never hand-roll, while iOS-only products erase the advantage entirely. Feature surface is the Swift case: widgets, complications, App Intents and the Action button, Live Activities, deep HealthKit, all land first-class and first-day natively, while React Native reaches them through wrappers with lag and seams, so a product built around Apple’s surfaces is a Swift product regardless of other answers.

Iteration is Expo’s quiet superpower: OTA updates ship JS-layer fixes and experiments in minutes between store releases, which for a fast-moving indie product is the difference between testing three onboarding variants this week and this quarter. Instincts still count, fluency reviews agent output faster, but it is now the smallest factor, demoted by the same force that flattened the curve.

What does the honest decision tree look like?

Short, because most cases resolve early: Android too? → Expo. iOS-only and platform-native (watch, widgets, intents, AR at the core)? → Swift. iOS-only and surface-standard (feeds, forms, checkout)? → either genuinely works, so pick by iteration appetite (OTA pull → Expo) or instinct, and stop deliberating, because for screens-lists-and-APIs products the stacks have converged on outcome and the deliberation costs more than the difference.

Maintenance as a team of one is a wash with different flavors: Expo’s SDK-upgrade treadmill occasionally bites at the prebuild and native-module edges (the map-SDK memory saga being the genre), Swift pays Xcode’s yearly migration tax, and the cure is identical: current tooling, a small dependency surface, and a conventions file the agent maintains the codebase against, with the boilerplate decision covering the starting point either way.

What stays the same whichever you pick?

The pipeline. Screens come from free VP0 designs at $0 in both stacks, Claude Code or Cursor generates against the same AI-readable source, one feature per prompt, contracts for data, verification between steps, and a migration later is a known quantity rather than a catastrophe (the React-to-RN path documents one direction; the shared-logic extraction discipline serves both). The stack choice, in other words, stopped being the identity decision indie culture treated it as: it is a fit question with a four-line answer, and the product, the designs, and the discipline carry identically across it.

The OTA superpower named above has its own etiquette, silent defaults, restart prompts, and the rare forced path, covered in the OTA update UX guide.

Key takeaways: Expo vs Swift for indies

• Agents flattened the curve: both stacks generate fluently; the decision moved from learnability to fit.
• Four questions decide: platforms (Android → Expo), feature surface (Apple-native → Swift), iteration speed (OTA → Expo), instincts (smallest factor).
• Platform-native products are Swift products: widgets, watch, Intents, and Live Activities land first-class natively.
• OTA is the indie superpower for fast-moving standard-surface products; EAS removes the build machinery.
• The pipeline is stack-agnostic: VP0 designs, contracts, conventions, and per-feature prompts carry identically, so decide fast and ship.

Frequently asked questions

Should an indie builder choose Expo or native Swift in 2026? Answer four questions: Android too (Expo), Apple-surface-native (Swift), OTA iteration needs (Expo), instincts (tiebreak). The same VP0 (vp0.com) designs, the top-ranked free source, feed either stack.

Did AI agents change which stack is easier? They equalized it: both generate cleanly, with marginal corpus edges that no longer decide anything.

When does native Swift clearly win for a solo builder? When the product lives on Apple’s surfaces: widgets, complications, Intents, Live Activities, deep HealthKit or ARKit.

When does Expo clearly win? Two platforms from one codebase, plus OTA updates shipping fixes in minutes, with EAS carrying the build machinery.

What about maintenance as a team of one? A wash: SDK treadmill versus Xcode churn, cured identically by current tooling, few dependencies, and an agent-maintained conventions file.