How to Publish Your AI-Built App to the App Store & Google Play

AI app builders generate web apps — Next.js, React, deployed to the web. They run beautifully in mobile browsers as PWAs (progressive web apps), installable to the home screen, working offline, sending push notifications. For many products, the PWA is enough. But sometimes you need to be in the App Store and Google Play — for distribution, discoverability, credibility, or because your users expect to find you there.

Getting an AI-built web app into the app stores requires bridging from web to native. The most common path is wrapping the PWA with Capacitor — a tool that packages your web app into a native shell that the stores accept. This guide covers the realistic path to publishing an AI-built app to both stores: the wrapping approach, store requirements, the review process and how to navigate it, the gotchas, and the honest upfront question: do you even need the stores, or is a PWA enough?

First Question: Do You Even Need the Stores?

PWA May Be Enough If

• Your users find you via web (search, ads, links)
• Install-to-home-screen satisfies the 'app' need
• You don't need deep device features (advanced camera, Bluetooth, HealthKit)
• You want to avoid Apple's 30% (now 15-30%) in-app purchase cut
• You want to ship updates instantly (no review delays)
• B2B or productivity tool where store discovery isn't the channel

You Need the Stores If

• Store discovery is a real acquisition channel for your category
• Users expect to find you in the store (consumer apps especially)
• You need deep native features PWAs can't access well
• Credibility — some users trust store-published apps more
• Push notifications on iOS (PWA push on iOS is limited)
• Your competitors are in the stores and users compare

Honest framing: many AI-built B2B and productivity apps do fine as PWAs and skip the stores entirely. Consumer apps and apps relying on store discovery usually need the stores. Decide before investing the effort.

The Three Paths to the Stores

Path 1: Capacitor Wrapping (Most Common)

• Capacitor wraps your web app in a native shell
• Your existing Next.js/React code runs inside
• Native plugins for device features (camera, push, etc.)
• Builds to iOS and Android packages the stores accept
• Least additional work for an existing web app
• Performance good for most apps (not ideal for graphics-heavy)

Path 2: Rebuild Natively or React Native

• Rebuild the app (or key parts) in React Native or native
• Better performance and native feel
• Significantly more work
• Worth it for graphics-heavy or performance-critical apps
• Usually overkill for typical SaaS

Path 3: PWA-to-Store Services

• Services like PWABuilder generate store packages from a PWA
• Fastest path but least control
• Google Play accepts PWAs more readily (Trusted Web Activity)
• Apple is stricter about pure web wrappers
• Works for simple apps; limited for complex ones

Capacitor Wrapping: The Realistic Process

Setup and Native Features

• Add Capacitor to your existing web app project
• Configure app ID, name, icons, splash screens
• Build your web app; Capacitor copies it into native projects
• Open iOS project in Xcode; Android project in Android Studio
• Push notifications, camera, filesystem, geolocation — official plugins available
• In-app purchases (RevenueCat is the standard for this)

Build Requirements

• iOS: requires a Mac with Xcode (no way around this for iOS builds)
• Android: Android Studio (works on any OS)
• Apple Developer account ($99/year)
• Google Play Developer account ($25 one-time)
• App signing certificates for both

Apple App Store Requirements

• Apple Developer account ($99/year)
• App must provide value beyond a simple website wrapper (Apple rejects thin wrappers)
• Privacy policy required; App Privacy details (data collection disclosure)
• In-app purchases must use Apple's IAP for digital goods (15-30% cut)
• App Review (typically 1-3 days; can be longer)
• Screenshots for all required device sizes; app icon meeting specifications
• Age rating questionnaire
• Sign in with Apple required if you offer other social logins

Google Play Requirements

• Google Play Developer account ($25 one-time)
• Privacy policy required; Data safety section (data collection disclosure)
• Target API level requirements (kept current)
• Google Play Billing for digital goods (15-30% cut)
• Content rating questionnaire
• Store listing (description, screenshots, feature graphic)
• Review (often faster than Apple; hours to a couple days)
• More lenient on web-based apps than Apple

In-App Purchase Rules (the Money Question)

• Digital goods/subscriptions consumed in-app must use store IAP (Apple/Google take 15-30%)
• Physical goods and services can use your own payment (Stripe) — no store cut
• SaaS subscription edge cases: rules evolving; 'reader' apps and external link allowances changing
• RevenueCat simplifies cross-platform IAP management
• Consider: stores' cut vs the distribution value they provide
• Some apps offer web signup (Stripe) + app usage to avoid IAP cut where rules allow

Common Rejection Reasons (Apple Especially)

• Thin wrapper — app is just a website with no native value-add
• Broken functionality during review
• Missing privacy policy or inaccurate privacy disclosures
• Using external payment for digital goods (IAP violation)
• Incomplete metadata or placeholder content
• Crashes during review
• Misleading screenshots or description
• Login required without a demo account provided to reviewers
• Inappropriate content rating

Navigating Review Successfully

• Provide a demo account for reviewers (critical if login required)
• Test thoroughly before submitting (crashes = rejection)
• Add native value (push, offline, device features) beyond pure web
• Accurate privacy disclosures
• Clear, accurate metadata and screenshots
• Respond promptly to reviewer questions
• Don't argue; fix and resubmit
• First submission rejection is common; iterate

Common Mistakes

• Going to stores when PWA would suffice — Stores add cost, review delays, and revenue cut. Confirm you need them.
• Submitting a thin wrapper to Apple — Pure website wrappers get rejected. Add native value.
• Not providing a demo account — Login-required apps without demo credentials get rejected.
• Using Stripe for digital goods in-app — Violates store IAP rules. Use store billing for digital goods.
• Inaccurate privacy disclosures — Apple and Google both check. Be accurate.
• Submitting with bugs — Crashes during review = rejection. Test thoroughly.
• Ignoring iOS Mac requirement — iOS builds need a Mac with Xcode. Plan for it.
• Underestimating review time — Apple can take days; rejections add time. Don't promise launch dates tied to review.
• Skipping the audit before wrapping — Wrap an audited app, not a raw generation.
• Not using RevenueCat for IAP — Cross-platform IAP is complex; RevenueCat simplifies it.
• Arguing with reviewers — Fix and resubmit; don't argue. Faster path to approval.

Frequently Asked Questions

Do I really need to be in the app stores?

Often no. Many B2B and productivity AI-built apps do fine as PWAs. You need the stores if store discovery is your acquisition channel, users expect to find you there, or you need deep native features. Decide before investing the effort.

What's the easiest path for an AI-built web app?

Capacitor wrapping. It packages your existing web app into native shells the stores accept, with plugins for native features. Least additional work for an existing Next.js/React app.

Do I need a Mac for iOS?

Yes. iOS builds require Xcode, which runs only on macOS. Options: own a Mac, use a Mac in the cloud (MacStadium, etc.), or use a CI service that provides Mac build runners (Codemagic, EAS Build). No way around the Mac requirement for iOS.

Will Apple reject my app for being a web wrapper?

Apple rejects thin wrappers (just a website with no native value). Add native features — push notifications, offline support, device integration — and provide genuine app value. Wrappers that add native value are accepted; pure website-in-a-box wrappers are not.

Can I update instantly like a web app?

No — store apps go through review for updates (though minor updates are often fast). One PWA advantage: instant updates without review. With Capacitor, you can update the web content via over-the-air updates for some changes, but native changes need store review. Factor update cadence into the stores-vs-PWA decision.

First ask whether you need the stores at all. Many AI-built B2B and productivity apps do fine as PWAs. Stores add cost, review delays, and revenue cut. Three paths: Capacitor wrapping (most common, least work), rebuild native/React Native (more work, better performance), PWA-to-store services (fastest, least control). Meet store requirements: developer accounts, privacy policies and disclosures, store IAP for digital goods, accurate metadata, demo account for reviewers. Apple is stricter than Google. Audit before you wrap. The stores are a distribution channel with real costs and benefits; enter them deliberately, not reflexively.