# Next.js to Mobile: Three Real Paths

*Originally published at* [*techpotions.com*](https://techpotions.com/lab/nextjs-to-mobile-real-paths)*.*

"Can we ship our Next.js app to the App Store?" has three honest answers, and they differ less by framework than by where you are willing to let the complexity live: in a web view layer, in a parallel React Native codebase, or behind a headless API. One thing is constant across all three, Apple's reviewers reject products that feel like a wrapped website with no native behavior, so "just wrap it" is rarely the end of the story.

Here are the three real paths, what each gives you, and where each one breaks.

## How to convert a Next.js app to mobile: the three paths

At a glance, before the detail.

| Path | Time to TestFlight | Native feel | Code duplication | Breaks when |
| --- | --- | --- | --- | --- |
| Capacitor wrap | 1 to 3 days | Weak, WebView defaults | None | Auth cookies, deep links, background jobs |
| React Native with Expo | 4 to 8 weeks for core flows | Strong | High, but shared types | Your team's React Native learning curve |
| Shared API and thin native shell | 6 to 12 weeks | Maximum | Minimal, an API client per platform | Coordination between web and mobile release cycles |

## Capacitor wrap: fast, fragile, and review-risky

Capacitor wraps your existing Next.js app in a native shell. It is the fastest way onto TestFlight, 1 to 3 days, and the native feel is the weakest of the three.

### What works out of the box

Your SSR, ISR, and middleware keep working, because the app is still the web app, just running inside a native container. For a read-heavy product this gets you surprisingly far on day one.

### What breaks and needs native bridges

The web-only assumptions are where it bites. Auth cookies, deep links, push notifications, and background jobs all need native bridges rather than their browser equivalents. Deep links want `@capacitor/deeplinks` plus an `apple-app-site-association` file and an `assetlinks.json`. Web `window.Notification` does not get you mobile push, you move to `@capacitor/push-notifications`. Background work moves to `@capacitor/background-runner`. Cookie-based sessions with `httpOnly`, the kind NextAuth or iron-session set, are the first thing to misbehave inside the WebView.

### The App Store trap

An APK can be side-loaded in hours, but the first App Store review is where the wrap shows. Expect to add native chrome before it passes: at least one native tab bar, a non-browser splash screen, and a real offline fallback. A common pattern is to ship in two weeks, get rejected twice, then spend three weeks adding the native feel reviewers want. That rework is the hidden cost of the Capacitor path. Use it when you want a quick store presence and you accept that some of this comes back around later.

## React Native with Expo: a parallel codebase that shares DNA

The middle path rewrites your high-traffic authenticated screens as real native screens in React Native, and keeps the rest on the web.

### Which screens move first

The screens users live in, the authenticated, high-traffic core, move first. That is where native feel actually matters and where a WebView feels cheapest to the user.

### What stays on the web as a linked-out WebView

Settings, billing, legal pages, admin tools, and marketing stay on the web and open as linked-out WebViews. There is no reason to rebuild a legal page natively. You share types, API clients, validation, and business rules through a monorepo, so the reuse is real even though it is zero UI code. The hard part is keeping auth state consistent between the native screens and the WebViews.

### The Expo fact pattern

Expo handles signing and submission, which removes a lot of the Xcode and Gradle pain, and it suits 3 to 5 person teams well. The catch is that custom native modules still need a build pipeline you own, usually through `expo-dev-client`. Budget 4 to 8 weeks for the core flows, and expect the first screen to take about a week while the tenth takes about a day.

## Shared API and thin native shell: the headless Next.js endgame

The furthest path turns Next.js into a headless API, Route Handlers or a standalone server, consumed by a Next.js web client and a thin native shell side by side.

### What the native shell actually contains

The shell is deliberately thin: 3 to 5 core native tabs, a biometric lock, token-based auth kept in secure storage, and authenticated WebViews for everything that does not need to be native. This is the shape for products that have genuinely outgrown a WebView, fintech and health being the usual examples. You do not build it all at once, you evolve it as revenue justifies it.

## Pricing the paths against App Store risk

The honest comparison is cost and risk, not elegance.

| Path | Approx. build time | Annual maintenance burn | App Store rejection risk |
| --- | --- | --- | --- |
| Capacitor wrap | 30 to 80 hours | $8k to $15k in plugin maintenance | High on first submission |
| React Native hybrid | 200 to 400 hours | $25k to $50k for dual-stack upkeep | Low, if a tab bar and native screens exist |
| Shared API and thin shell | 400 to 800 hours | $40k to $80k for multi-platform sync | Very low |

Build hours assume a two-developer, seed-stage team and a moderate-complexity app. If mobile is the core product hypothesis rather than a companion to the web app, starting with the thin shell can beat a Capacitor wrap you will throw away.

## FAQ

### Can I just publish my Next.js app as a PWA and skip the App Store?

On Android, often yes, "Add to Home Screen" is prominent and a PWA goes a long way. On iOS it is weaker: no push notifications, no Face ID, no background sync, and those are usually the exact reasons users asked for an app in the first place.

### Will Capacitor preserve Next.js SSR and middleware?

Yes. Capacitor runs your web app inside a native container, so SSR, ISR, and middleware keep working. What does not carry over cleanly is the browser-only behaviour, cookie sessions, deep links, push, and background jobs, which is where the native bridges come in.

### How much of my Next.js codebase can I reuse in React Native?

None of the UI, and that surprises people. But the parts that are expensive to get right, typed API clients, validation, utilities, and business rules, can be shared through a monorepo. You are rebuilding the screens, not the logic underneath them.

We build all three, and more often help teams pick before they commit the runway to the wrong one. See our [mobile work](https://techpotions.com/services/mobile), our [migration work](https://techpotions.com/services/migrations), and how we take a [prototype to production](https://techpotions.com/solutions/prototype-to-production), or tell us what you're building and we'll reply within 24h.