Taking a Lovable Web App to the App Store

The situation is common enough to be a genre. You built something in an AI builder, it works, people use it in a browser, and now someone has asked for it on the App Store. The web is done. How hard can the rest be?

The honest answer is that the packaging is easy and the approval is not. Capacitor will have your React app running in an iOS simulator faster than you expect. The work that follows is mostly Apple's process, plus one guideline that decides whether the whole plan was viable in the first place.

What Capacitor actually gives you

Capacitor puts your existing web build inside a native iOS project. The app that installs on a phone is a real native binary; what it mostly does is display your site in a full-screen web view, with a bridge that lets your JavaScript call native capabilities such as the camera, push notifications, the filesystem or biometrics.

That bridge is the point. It is the difference between a shortcut to a website and an app that can hold a push token, read a photo from the library, or work when the signal drops. Everything you already wrote stays. Your React code, your styling, your API calls and your auth flow come along unchanged.

What it does not change is the nature of the product. If your app is a set of forms that talk to a server, wrapping it does not make it feel native, and it does not make it behave well offline. Users notice, and so does App Review.

Guideline 4.2 is the gate, not the build

Apple's Minimum Functionality rule says an app should do more than repackage a website. Reviewers apply it to exactly this pattern, and a rejection here is not a formatting problem you fix in an afternoon: it is a statement that the thing you submitted did not need to be an app.

So the first question in any evaluation is not technical. It is: what does this app do on a phone that the website in Safari does not? Useful answers are concrete. It sends push notifications people act on. It uses the camera as part of a real workflow. It keeps working on a train with no signal and syncs later. It signs people in with Face ID.

If the honest answer is nothing yet, the work is not packaging. It is deciding which native capability earns the app its place, then building that. Teams that skip this step tend to discover it after their first rejection, having already paid for the rest.

The part that surprises web teams

Android is comparatively forgiving. iOS has a fixed set of prerequisites, and for a team that has only shipped web, each one is unfamiliar.

• A paid Apple Developer Program membership, renewed yearly, under the right legal entity. Getting this wrong is a slow problem to unwind.
• A Mac running Xcode. There is no supported way around this for building and uploading iOS binaries.
• Signing: certificates, identifiers, provisioning profiles. Conceptually simple, reliably the thing that breaks a first build.
• App Store Connect: the listing, screenshots at the required sizes, and the privacy questionnaire describing every piece of data you collect.

The privacy answers deserve attention, because they must match what the app actually does. An AI builder may have wired in analytics or a third-party service you have not thought about since. Declaring one thing and doing another is a worse outcome than a rejection.

What TestFlight is, and what it is not

TestFlight is how you get builds onto other people's phones before release. There are two tiers, and the difference matters for planning.

Internal testers are capped at 100 people, and they must hold App Store Connect accounts with access to your app. External testers are capped at 10,000, and this is where the schedule can slip: inviting them may send the build to Beta App Review. Typically only the first build in a group goes through a full review, with later builds moving faster, but the first one is a wait you should plan for rather than discover.

Builds remain testable for 90 days and then become unavailable. For a beta that runs across a quarter, that is a recurring task, not a one-off.

When to wrap, and when to rebuild

Capacitor is the right call when the product genuinely is a web application and the phone adds a few specific capabilities on top. Internal tools, dashboards, booking flows and content products often fit this description honestly.

It is the wrong call when the phone is where the product actually lives: heavy lists, gestures, maps, background location, anything where the interface is the product. A web view can be made to look native and will still feel borrowed, and that feeling is what reviews complain about.

The decision is not permanent either way. Shipping a wrapped version to learn whether anyone wants the app is a defensible use of a few weeks, as long as you decide in advance what result would send you to a rebuild. What is not defensible is choosing Capacitor because a rebuild sounded expensive, then discovering the product needed one after you have spent the budget on review cycles. If you are weighing that call, our AI prototype rescue and mobile app development pages describe how we approach each path, and the Lovable production checklist covers what to settle before any of this starts.