Convert WeWeb to an iOS App: The App Store Guide (2026)

Key takeaways

WeWeb publishes a Vue.js web app and offers no native export; staff called native apps "not a priority" in 2024. A wrapper around the hosted app is the practical path.
Wrap the hosted app on a custom subdomain rather than exporting code: plugins such as WeWeb Auth, Stripe and OpenAI rely on WeWeb's servers and stop working when self-hosted.
Plan sign-in for the app: Google blocks its OAuth flow in embedded WebViews, magic links open Safari, and social logins call for an equivalent option such as Sign in with Apple.
WebViewGold, made by our team, turns the WeWeb URL into an Xcode project with push, Face ID, scanners, StoreKit and a native offline screen; appsubmitter.io handles signing and submission.

Our recommended solution

Turn your WeWeb app into a real iOS app with WebViewGold

WebViewGold wraps the WeWeb web app you already have in a native Xcode project and adds push notifications, a native offline screen, deep links, a QR scanner and more – the native value reviewers at the App Store look for. Built by our own team, and we submit WebViewGold apps all the time.

Get WebViewGold How it helps ↓

Can you convert a WeWeb app into an iOS app?

Yes. You convert WeWeb to an iOS app by wrapping the published web app in a native iOS project, adding native features that matter to your users and submitting it from your own Apple Developer account. WeWeb doesn't build iPhone apps itself, so the wrapper, the App Store listing and the review are your part of the job. Most of the effort goes into sign-in, payments and privacy details, not into the wrapping.

WeWeb comes from WEWEB SAS in Paris, a Y Combinator alumnus, and calls itself a full-stack AI application builder. Each time you publish, it builds a Vue.js application with prerendered pages and serves it from a CDN – on AWS in Northern Virginia with CloudFront, according to its FAQ. The result runs in any modern browser, which is exactly what a WebView wrapper needs.

What WeWeb doesn't offer, as of October 2026, is a path into the App Store. In March 2024 a staff member wrote that the PWA plugin would "NOT include (for now) … a feature to wrap the PWA and push it to app stores", and in September 2024 that native apps were "not a priority for now". Community members have suggested Capacitor, Expo, PWABuilder and webtonative over the years; none of them is a WeWeb product or an official recommendation.

What your WeWeb project means for an iOS build

Part of the project	What WeWeb gives you	What it means for the iOS app
Front end	A Vue.js app with prerendered pages on a CDN	Loads quickly in `WKWebView`; every publish updates the app without a new build
Address	`<id>-production.weweb.io` since April 8, 2026 (previously `<id>.weweb-preview.io`) or your custom domain	Wrap a custom subdomain such as `app.yourdomain.com` – WeWeb's domain docs say naked root domains aren't supported
Backend	WeWeb tables on Postgres with automatic CRUD APIs (since April 2026), or Supabase, Xano, REST and GraphQL	The server region you picked – US, Europe or Asia – belongs in your privacy policy
Sign-in	WeWeb Auth (password, one-time code, magic link, social providers), Supabase Auth, Xano, Auth0 or OpenID Connect	Social providers and magic links need extra work inside an app
Payments	Stripe integration	Fine for physical goods and services; digital content needs In-App Purchase
PWA	Name, icon, colors and display mode in the PWA settings; a legacy plugin whose notifications don't arrive while the app is closed	A Home Screen install, not an App Store listing
Branding	WeWeb logo on the free plan only	Publish from a paid plan before you take screenshots

Code export is available from the Essential seat plan, and you can self-host on AWS, Cloudflare, Netlify or your own servers. For an iOS app that detour rarely pays off. Plugins that talk to WeWeb's servers – Airtable, Google services, Notion, OpenAI, SQL databases, Stripe, SOAP APIs and WeWeb Auth – stop working outside WeWeb hosting, while Supabase, Xano and plain REST or GraphQL APIs keep working.

Want your WeWeb app in the App Store without the trial and error?

Book a free consultation call: we check your web app, tell you which native features it needs and what to fix before review. Or hand it off – our App Specialists set up signing and CI/CD, prepare the store listing and submit the app for you.

Free consultation call Book our service →

WeWeb to the App Store: four routes compared

Route	How it works for WeWeb	Strong points	Watch out for
Native wrapper (WebViewGold)	Loads your hosted WeWeb app in a native Xcode project with switchable native modules	Every WeWeb plugin keeps working; content goes live with a publish; one-time purchase	You still need native value and review-ready sign-in, payments and deletion
Capacitor with exported code	You export the build and bundle it in a Capacitor project with native plugins	Full control over native code; offline-first is possible	Server-dependent plugins break; every WeWeb change means a new export and build; needs developers
Progressive web app	Users add the WeWeb app to the Home Screen from Safari	No App Review, no developer account	Not in the App Store; web push only for Home Screen web apps on iOS 16.4 and later; limited device access
Native rebuild	You rebuild the screens in Swift, SwiftUI or React Native against your WeWeb backend APIs	The most native experience	Two front ends to maintain; the slowest and most expensive option

For the typical WeWeb project – an internal tool, a customer portal, a dashboard – the wrapper keeps WeWeb as the single place where you build. A rebuild makes sense when the app needs heavy offline work or device features beyond what a wrapper exposes.

What you need before you start

An Apple Developer Program membership as an individual or an organization. Publish under the company that runs the service, so the seller name matches the business behind your WeWeb app.
A Mac with Xcode – or WebViewGold's Cloud Builder, sold separately, which configures, builds and uploads the app in your browser.
A WeWeb seat and hosting plan with a custom subdomain such as app.yourcompany.com; custom domains require a hosting plan.
A privacy policy and a support URL on public pages – not on WeWeb pages restricted to authenticated users, where reviewers would bounce off a login.
A review account that signs in with a password, holds every role and contains realistic data.
App Store assets: an icon, screenshots taken from the app itself and a description that matches what the app really does.

Prepare your WeWeb project for life inside an iPhone app

The wrapper shows exactly what WeWeb publishes, so most of the preparation happens in the editor:

Check every page at phone width. Internal tools are often designed on a desktop first. Wide tables, hover menus and tiny icons need a mobile layout before an iPhone user – or a reviewer – sees them.
Mind the notch and the home indicator. Test fixed headers and bottom navigation on a current iPhone. If they collide with the system areas, use viewport-fit=cover together with env(safe-area-inset-*) padding.
Detect app mode for layout only. WebViewGold sends a custom user agent. Let WeWeb check it once on app load and store the result in a variable that your Conditional Rendering uses to hide the website footer or the legacy PWA plugin's install prompt – and to show any cookie consent you still need in an app-friendly style rather than dropping it. Features must stay identical for every user – our article on a WeWeb app rejected under Guideline 5.6 explains why.
Remove the WeWeb logo the proper way. WeWeb staff confirmed in September 2025 that the logo appears only on the free plan and disappears on paid plans. Upgrade instead of hiding it with CSS.
Route foreign links outward. Help centers, social profiles and other domains should open in Safari or an in-app browser sheet rather than replacing your app.
Update old addresses. If auth redirect pages, workflows or emails still point at a pre-April 2026 weweb-preview.io address, switch them to your custom subdomain.

The shortcut from WeWeb to the App Store

WebViewGold: your WeWeb app, native on iOS

Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:

Push notificationsOneSignal or Firebase, for real, personal events
Native offline screenNo browser error pages when the connection drops
Native splash screenApp-like start instead of a loading web page
Deep linksLinks open the right screen inside the app
QR & barcode scannerDevice features the website alone can't offer
In-app purchasesNative purchase flows where the store requires them

No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.

Discover WebViewGold Let us submit your WebViewGold app

Turn your WeWeb app into an iOS app with WebViewGold, step by step

WebViewGold is the website-to-app product built by our own team at jocapps. It gives you a ready-made Xcode project in Swift that you own, so you configure the native layer instead of writing it.

Pick the license. The Regular license covers a standard app; the Extended license is required if the app sells In-App Purchases. Both are one-time purchases with free updates.
Set the start URL. In Config.swift, enter https://app.yourcompany.com – your production custom subdomain, never the editor, a staging address or a weweb.io subdomain.
Define the user agent your WeWeb project checks to recognize app mode.
Brand the shell: bundle ID, app name, icon, splash screen and dark mode.
Switch on the modules your users need – see the list below.
Build and test on a real iPhone via TestFlight, signed in with the review account.

Which native features make sense depends on what you built in WeWeb:

Push notifications via OneSignal, Firebase or Pushwoosh when a workflow event concerns the user – a request approved, a task assigned, an order shipped.
Face ID or Touch ID to get back into a portal in a second.
QR and barcode scanner for inventory, asset tracking or event check-in.
VisionKit document scanner where users currently upload photos of paper forms or receipts.
File downloader and AirPrint for reports and exports from your dashboards.
Native offline screen with a retry button instead of a blank page when the connection drops.
Native share dialog and in-app rating dialog in place of their web equivalents.

Universal links are worth setting up if magic links or notification emails should open the app. They need an apple-app-site-association file under /.well-known/ on your domain, and WeWeb community members have reported trouble placing files at that path – confirm your domain can serve it before you depend on it. No Mac? Use the Cloud Builder, or let our team set everything up for you. And no tool can promise an approval: the app still has to meet the guidelines in the next section.

Sign-in, payments and account deletion: where WeWeb apps meet App Review

Topic	Typical WeWeb setup	What Apple expects	What to do
Social sign-in	WeWeb Auth opens a provider window for Google or GitHub	Google rejects sign-in requests from embedded WebViews (`disallowed_useragent`); Guideline 4.8 asks for an equivalent privacy-friendly login next to social logins; Apple calls linking out to the browser to sign in a poor experience under Guideline 4	Add Google natively with `ASWebAuthenticationSession` or Google's iOS SDK (custom code in the Xcode project) next to Sign in with Apple, which WebViewGold supports – or keep Google on the web and offer email and password plus Sign in with Apple in the app. Never change the user agent to get around Google's block
Magic links	An email with a link to `/magic-link?token=…`	The reviewer must be able to sign in inside the app	Passwords or one-time codes in the app; universal links if you keep magic links
Paid features	Stripe checkout	Digital content and features need In-App Purchase (3.1.1); physical goods and services use other methods (3.1.3(e))	StoreKit purchases through WebViewGold (Extended license) for digital goods
Accounts	A sign-up workflow	"If your app supports account creation, you must also offer account deletion within the app" (5.1.1(v))	A Delete account page whose workflow removes the user and their data in your backend
Uploads with the camera	An upload element that offers camera and photo library	"Ensure your purpose strings clearly and completely describe your use of the data" (5.1.1(ii))	Specific `NSCameraUsageDescription` and `NSPhotoLibraryUsageDescription` texts in the Xcode project
AI features	The OpenAI plugin or an AI gateway	Disclose sharing with third-party AI and obtain explicit permission (5.1.2(i))	A consent screen before the first AI request, mirrored in your privacy policy

The upload row comes from a real case. In August 2024 a developer whose WeWeb app had been wrapped with PWABuilder reported an Apple rejection over the generic camera prompt that appeared after tapping upload. They couldn't change that system text in their wrapper, so they removed file uploads on iOS, declared all data collection and opened sign-up to anyone; in April 2025 they reported approval on both stores. In a native project you write the purpose strings yourself, so you can keep the feature.

The WebView-specific details are in our articles on Guideline 4.8, Guideline 3.1.1 and Guideline 5.1.1(v) for wrapped apps.

Submitting the WeWeb app – and the rejections to prepare for

In App Store Connect, create the app with the bundle ID from your Xcode project, fill in the listing with screenshots from the wrapped app and complete the App Privacy details – including data your WeWeb pages collect through forms, analytics, Stripe or AI plugins. Enter the review account under App Review Information and use the Notes for Review to list the pages per role and each native feature with the steps to try it. Then select the TestFlight-tested build and submit.

These are the guidelines that matter most for a wrapped WeWeb app:

4.2 Minimum Functionality when the app feels like the website in a frame – see 4.2 for WebView apps.
2.1 App Completeness when the review account fails or dashboards stay empty – see 2.1 for WebView apps.
5.6 Developer Code of Conduct when roles, conditions or mid-review publishes make features look hidden.
4.2.6 when an agency or a wrapper vendor submits the app instead of the business that provides its content – see 4.2.6 for WebView apps.

appsubmitter.io takes over the parts most WeWeb teams don't want to learn: certificates, provisioning profiles and code signing, a CI/CD pipeline with fastlane, the listing and App Privacy details, AI-powered pre-submission checks with a human App Specialist on top, the submission itself and every message with App Review – all in your own developer account. Code or WeWeb changes are quoted separately upfront, and your app doesn't need to be finished when you book. Book the iOS package or start with a free consultation call. Planning Android as well? Read converting WeWeb to an Android app.

Checklist before you submit

The iOS app loads your production custom subdomain, never the editor, staging or a weweb.io address.
Every page works at phone width, and fixed bars don't collide with the notch or the home indicator.
App-mode detection only changes layout – footer, PWA install prompt, the style of the consent dialog – never features.
You publish from a paid WeWeb plan, so the free-plan logo appears neither in the app nor in screenshots.
Google sign-in is native (ASWebAuthenticationSession or Google's SDK) or stays on the web, and Sign in with Apple is offered in the app.
Digital content uses In-App Purchase; Stripe only handles physical goods or services.
Users can delete their account inside the app, and the workflow really deletes their data.
Camera and photo library prompts carry specific purpose strings.
App Privacy details cover data collected by your WeWeb pages, Stripe and AI plugins.
The review account signs in with a password, holds every role and has realistic data.
The Notes for Review list the pages per role and each native feature with test steps.

Frequently asked questions

Can I publish a WeWeb app on the App Store?

Yes, as long as you package it as a native app and it meets the App Review Guidelines. WeWeb has no App Store export, so you wrap the published app – for example with WebViewGold – and submit it from your own Apple Developer account with native features, working sign-in, In-App Purchase where required and in-app account deletion.

Do I need a Mac to convert WeWeb to an iOS app?

Not necessarily. Building an iOS app normally requires Xcode on a Mac. WebViewGold's Cloud Builder, sold separately, configures, builds and uploads the app in your browser instead. Alternatively, our team can set up WebViewGold for you, and appsubmitter.io handles code signing and submission through a CI/CD pipeline.

Should I export my WeWeb code instead of wrapping the hosted app?

Only if you have a reason to. Export and self-hosting need the Essential seat plan or higher, and plugins that depend on WeWeb's servers – WeWeb Auth, Stripe, OpenAI, Airtable, Google services, SQL databases and others – stop working when self-hosted. Supabase, Xano and REST or GraphQL APIs keep working, so export suits projects built on those.

Will changes I publish in WeWeb show up in the iOS app?

Yes, immediately, because the app loads your published WeWeb project. That is convenient for content and fixes. New features, new payment flows or anything that changes what the app does should ship with a new build whose Notes for Review describe them, so the app Apple approved stays the app your users get.

How long does App Review take for a WeWeb app?

Apple doesn't promise a fixed time. Its guidelines say App Review examines apps as soon as it can, that complex apps or new issues may need more scrutiny and that repeated rejections for the same violation make review take longer. A complete submission with a working review account is the best way to avoid extra rounds.

What does it cost to get a WeWeb app into the App Store?

Plan for four kinds of cost: the annual Apple Developer Program fee, your WeWeb seat and hosting plan for the custom domain, a one-time WebViewGold license – Extended if you sell In-App Purchases – and, optionally, an appsubmitter.io package for signing and submission. Code changes, if your app needs any, are quoted separately.

Sources and further reading

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.

Convert WeWeb to an iOS App: How to Get Your WeWeb Project Into the App Store