Can I vibe code a mobile app?

The short answer

Yes, you can. Your web app already proves the hard part works, and getting it onto a phone is a known road, not a mystery. For a beginner, two paths are realistic. The web-first one keeps your existing app and either installs it to the Home Screen as a PWA or wraps it in a native shell with Capacitor. The native one rebuilds the interface in React Native with Expo, which is the path an AI agent handles well because cloud builds mean you barely touch Xcode. The part nobody warns you about is the stores themselves. Apple charges $99 a year and Google charges a one-time $25 (as of July 2026), both add a review queue that can reject you, and Apple’s minimum-functionality rule turns thin website wrappers away. The web never asked any of this. So the honest answer is: the coding is the easy half now, and the store paperwork, fees, and review are the half that surprises people.

The four paths, and what each one really asks of you

The confusing part is the names. React Native, Expo, Capacitor, PWA, Swift, EAS. They sound like rivals, but they’re four different answers to one question: how does your code end up on a phone. Below is the honest shape of each, including where an AI agent can carry you and where you’d be working blind.

Path	What you actually ship	In a store?	How far an agent takes you
PWA	Your web app, installable to the Home Screen	No store	Furthest, it’s just your website
Capacitor	Your web app inside a native shell	Both stores	Far, same web code plus native bits
Expo + React Native	A real native app written in JavaScript	Both stores	Far, and you can still run it to check
Native Swift / Kotlin	Two separate native codebases	Both stores	It can write it, you can’t verify it

A PWA (Progressive Web App) is your existing site with a small manifest and a service worker, so a phone can save it to the Home Screen and open it full-screen. No store, no fee, no review. The catch is iOS, where web apps are still second-class. Push notifications only arrived in iOS 16.4 (March 2023), and only after the user manually adds your app to the Home Screen through the Share menu, a step most people never take. If your app doesn’t truly need to be in the App Store, a PWA is the cheapest, fastest route by a wide margin.

Capacitor, from the Ionic team, wraps your built web app inside a native container. Your frontend still runs, now inside a WebView, and a thin native bridge gives it access to the camera, files, and notifications. You get a real listing in both stores from the same web codebase. The risk is Apple’s reviewers, who reject shells that are just a website in a box (more on that below).

Expo with React Native is the agent-friendly native path. React Native draws real native controls instead of web pages, and Expo’s tooling smooths the rough edges. Its cloud build service, EAS (Expo Application Services), compiles your iOS app on Apple machines in Expo’s cloud, so you can build and submit without owning a Mac or opening Xcode. This is the path where an agent goes deep while you keep the one power that matters: you can still run the app and see for yourself whether it works.

Fully native Swift or Kotlin is the path to be most careful with. An agent can write Swift fluently. You, as a beginner, cannot check it. Two codebases, two toolchains, and when something breaks you have the least vocabulary to say what. This is exactly where the 70 percent wall is steepest, because the last stretch of a native app is the part you can least verify alone. Unless you have a specific reason, skip it.

What the app stores cost, and how they judge you, as of July 2026

The web let you deploy for free and answer to no one. The stores are a different world, and the two big ones charge and screen differently.

Apple’s Developer Program costs $99 per year, and it’s a recurring fee, not a one-time payment. Let the membership lapse and your app comes down. That $99 also gates TestFlight, so even sending a beta to a friend on iPhone requires an active membership. Every submission then goes through App Review, a human-plus-automated check with a queue that’s usually quick but never guaranteed.

The rule that catches vibe coders is guideline 4.2, Minimum Functionality. Apple’s own words: “Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or ‘app-like,’ it doesn’t belong on the App Store.” A related clause, 4.2.2, turns away apps that are primarily “marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” A thin Capacitor wrapper with nothing a browser tab lacks is the classic 4.2 rejection. The way through is to give the app a reason to be an app: push notifications, offline behavior, camera or location, native navigation that feels at home on the device.

Google Play charges a one-time $25 registration fee, and that’s the whole store cost. The surprise on Google’s side is newer. If your developer account is a personal account created after November 13, 2023, you can’t publish straight to production. First you must run a closed test with at least 12 testers opted in for 14 continuous days, then apply for production access. That count still stands at 12 as of July 2026. Organization accounts and personal accounts opened before that date skip this gate. It’s not hard, but it’s a two-week wall standing between “it builds” and “strangers can install it,” and it blindsides people who expected to ship the same afternoon.

Getting it into your friends’ hands before the whole world

You don’t launch to the store to test with real people. Both platforms have a beta lane, and using it first is how you catch the broken sign-up before a stranger does.

On iOS, that lane is TestFlight. You upload a build to App Store Connect and invite testers, who install through the TestFlight app rather than the App Store. Up to 100 internal testers (people on your development team) get builds with no review at all. For external testers, up to 10,000 of them via a shareable public link, your first build has to clear a lighter Beta App Review before the link goes live. So the fastest way to hand a build to yourself and a couple of friends is the internal route.

On Android, the matching lane is the internal testing track: up to 100 testers, and a new build reaches them within minutes, exempt from the usual policy and security review. One trap to name plainly. That internal track is for quick checks and does not count toward the 12-tester, 14-day closed-testing requirement above. If you’re on a new personal account, you still owe Google that closed test before production, so start its clock early rather than discovering the wait on launch day. This kind of “test as a real user first” habit is the same one behind shipping safely in general.

Shipping updates after launch, where web and native split hard

On the web, an update is a redeploy. You push, your host rebuilds, and the next person to load the page gets the new version. A PWA inherits exactly this: fix a bug, ship it, done, no gatekeeper.

Native store apps are stricter. A new binary means another trip through App Review or Google’s checks, every time, for the same app. That’s slow when you’re fixing something small and urgent. The escape valve is over-the-air updates. Expo’s EAS Update pushes changed JavaScript and assets straight to installed apps, so a bug fix reaches users without a new store build. This is allowed, within limits. Apple’s guideline 2.5.2 says apps may not “download, install, or execute code which introduces or changes features or functionality of the app.” The accepted reading, and how React Native OTA updates operate, is that bug fixes, copy, styling, and content are fine to push over the air, while changing what the app fundamentally does or adding features that would need review is not. Anything native, a new permission, a new device capability, a new native module, still requires a fresh store submission. Treat OTA as a fast lane for patches, not a way around review.

What Glim would tell you

Glimfly is building Glim, a firefly that sits beside your coding agent and explains, in plain language, what just changed and what it means. “Can I vibe code a mobile app” is really four questions wearing one coat: which path, what it costs, how review works, how updates ship. An agent will happily pick a path and start building without ever telling you that Apple charges yearly, that Google will make you wait two weeks, or that your lovely wrapper is about to fail guideline 4.2. That gap between “the code runs” and “I understand what I signed up for” is exactly where Glim lives. Start with the honest path for your app, keep the power to run it and see for yourself, and when a term above moves faster than your agent explains it, the dictionary has it in plain words. If you’d like Glim narrating your first build and submit, the waitlist is open.