Web to mobile development: what changes in 2026

If you build for the web, the shortest path to mobile in 2026 is React Native with Expo. Your React, TypeScript and Tailwind habits carry over. What is new is the platform around the code: native builds instead of a refresh, permissions, a phone to test on, and an app store that reviews every release before anyone can install it.

JavaScript in a browser runs anywhere a browser does. Mobile does not work that way. Each platform has its own language, its own toolchain and its own rules about what an app may do, and the real decision is how much of that you take on directly.

Native or cross-platform

Native development means Swift for iOS and Kotlin for Android, each with its own codebase and its own tools (Xcode and Android Studio).

Advantages	Trade-offs
Direct access to every platform feature on the day it ships.	A separate codebase per platform, which roughly doubles the work.
The platform's own UI and tooling, with no layer in between.	Two languages and two toolchains to learn before you ship anything.

Cross-platform frameworks let you ship to both stores from one codebase while still rendering native UI and calling native APIs. For a web developer, two are worth knowing.

React Native

React Native is Meta's framework for building native apps with React. Instead of HTML elements you use native components such as <View>, <Text> and <TextInput>, which render as their iOS and Android counterparts. Components, hooks, props and state work the way they do on the web.

React Native's core components next to their web equivalents. Most of what you know maps across. Source

Two things changed since we first wrote this post. The New Architecture is no longer optional: React Native 0.82 was the first version to run entirely on it, and Expo SDK 55 and later cannot turn it off. And React Native's docs now recommend starting with a framework, naming Expo. As of October 2026 the latest Expo SDK is 57, on React Native 0.86 and React 19.2 (Expo SDK reference).

Flutter

Flutter is Google's cross-platform framework. Apps are written in Dart and can target iOS, Android, web and desktop. It draws its own UI rather than using the platform's components, which gives you pixel-level consistency across devices.

It is a good framework. For a web developer, the cost is that nothing transfers: a new language, a new UI model and no React. If you already write React, React Native is the shorter step, and that is the path the rest of this post follows.

Choosing between them

The decision comes down to what your team already knows, which platform features you need, and how much time you have. If you know React and want one codebase for both stores, the answer is React Native with Expo. We cover the Expo versus bare question in Expo or bare React Native.

What carries over from the web

More than you might expect, if you pick the right stack.

• React. The same components, hooks and state. React Query works unchanged.
• Routing. Expo Router gives you file-based routes, so app/settings.tsx is the settings screen, much like the Next.js App Router.
• Styling. Tailwind-style classes work through libraries such as Uniwind (Tailwind CSS v4 for React Native) or NativeWind. There is no cascade and no CSS grid, but flexbox works and is the default layout.
• TypeScript, Zod, your backend. Your API, your Supabase or Firebase project and your validation code carry straight across.

Coming from React, the transition to React Native was super smooth thanks to Native Express.

What is genuinely new

Builds. On the web you refresh. On mobile, JavaScript changes still reload instantly, but anything native (a new library with native code, a permission, an app icon) needs a new binary. A development build is your own version of Expo Go with your native libraries compiled in, and you rebuild it when native things change.

No Mac required, mostly. EAS Build compiles iOS apps on Expo's cloud Macs, so you can ship to the App Store from Windows or Linux. You still want a real iPhone or Android phone to test on.

Permissions and platform rules. Camera, photos, notifications and location each need a permission prompt with a reason string. Apple also has rules web apps never meet: if you offer Google sign-in, you must also offer an equivalent private option such as Sign in with Apple (guideline 4.8), and if users can create an account, they must be able to delete it in the app (guideline 5.1.1(v)).

Releases take review. There is no deploying on a Friday afternoon. Every binary goes through store review. EAS Update can push JavaScript-only fixes to installed apps without a new binary, within the store rules, which takes some of the sting out.

Onboarding

Sign-in with Google, Apple and email

Home, ready for your features

Building a mobile app with a coding agent

Many web developers now make the jump with Cursor, Claude Code or Codex writing most of the code. That works on mobile too, with a few differences worth knowing before you start.

The agent cannot see your phone. On the web, an agent can often open the page itself. On mobile, you are the one holding the device, so the loop is: the agent changes code, you look at the screen and describe what is wrong, or paste a screenshot. Short, specific feedback works better than "it looks off".

Give it the platform context. Agents are trained on years of outdated React Native advice. create-expo-app now writes an AGENTS.md that points agents at the docs for your SDK version, Expo publishes agent skills for Expo and EAS work, and there is an Expo MCP server that gives the agent live documentation and build history. Use all three.

Let it check its own work. Strict TypeScript, a test suite and one command that runs every check turn "it compiles" into "it works". Without them, every bug reaches your phone before anyone notices.

Know when it needs a new build. If the agent adds a library with native code or changes app.json, a hot reload will not pick it up. Ask it to tell you when a rebuild is needed.

This is the problem NativeExpress was built around: a React Native and Expo codebase with skills for setup, design and conventions that describe the code you cloned, and yarn ci so the agent can test what it wrote. You still make the decisions, sign in to services and test on your phone. No mobile experience is needed.

Coming from a background in backend development, I found this boilerplate to be an excellent bridge to frontend mobile development.

Testing before you ship

Both stores let you put builds in front of real people before release.

TestFlight is Apple's beta channel. You can add up to 100 internal testers from your team and up to 10,000 external testers; the first build for external testers has to pass a TestFlight review before they can install it.

Google Play has three tracks. Internal testing reaches up to 100 testers and is the fastest way to get a build onto a phone. Closed testing goes to a list you control. Open testing is public on Google Play.

Google Play's testing tracks: internal, closed and open. Source

Submitting to the App Store and Google Play

You need an Apple Developer Program membership (99 USD a year) and a Google Play developer account (a one-time US$25 fee). Both accounts, and every review, are yours.

EAS Submit uploads your build to App Store Connect and the Play Console from the command line, from any operating system:

eas build --platform all --profile production
eas submit --platform ios
eas submit --platform android

Expo's EAS Submit docs: the recommended path, and it runs on Windows and Linux too. Source

For Android it needs a Google service account key; for iOS, an App Store Connect API key or your Apple ID sign-in. After that, a release is two commands.

Current requirements to check before you submit, as of October 2026:

• Apple: since April 28, 2026, uploads must be built with Xcode 26 or later using the iOS 26 SDK. If you build with EAS, check that your build image uses Xcode 26.
• Google Play: since August 31, 2026, new apps and updates must target Android 16 (API level 36), with extensions available to November 1, 2026.
• The listing: screenshots, a description, a privacy policy URL, the age rating questions and the privacy details, filled in before you submit.

Apple says 90% of submissions are reviewed in under 24 hours on average. Apple also says that over 40% of unresolved issues fall under guideline 2.1, App Completeness: crashes, placeholder content and missing review details, such as a demo login for an app that requires signing in. Test the release build, and fill in the review notes. We walk through the whole process in how to publish an app on the App Store, and the earlier steps in how to make an iPhone app.

Web apps and progressive web apps

If you do not need the stores at all, a web app or a progressive web app (PWA) is still a fair choice. PWAs can work offline, launch from the home screen and send push notifications. They can only reach what the browser exposes, they are harder for people to find than a store listing, and in-app subscriptions through the stores are not available to them. If you want people to find you in the App Store or pay through it, you need a native app.

FAQ

Is React Native easy to learn for web developers?

If you know React, most of it is familiar: components, hooks, state and TypeScript all work the same. The new parts are native components instead of HTML, flexbox-only layout, and the build and release process. Expo Router and Tailwind-style styling make the gap smaller still.

Can I turn my website into a mobile app?

You can wrap a website in a native shell, but Apple expects an app to go beyond a repackaged website (guideline 4.2), and thin wrappers get rejected. The better route is to reuse your backend, API and React knowledge and build the screens in React Native, which keeps most of your logic and gives you a real native app.

Do I need a Mac to build an iOS app?

Not with Expo. EAS Build compiles iOS apps on hosted Macs and EAS Submit uploads them to App Store Connect from Windows or Linux. You will want an iPhone to test on, and you need an Apple Developer account to publish.

Can I build a mobile app with Cursor or Claude Code?

Yes. Start from an Expo project with an AGENTS.md, add Expo's agent skills, and make sure the agent can run type checks and tests. Your job becomes deciding what to build, testing on your phone and giving the agent specific feedback.