Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageThe goal: one codebase, three destinations
Your Cursor project keeps living on its URL, and two native apps load it. WebViewGold supplies those apps as a ready Xcode project and a ready Android Studio project. The main screen is a WKWebView on iOS and an Android WebView on Android, and the shell adds what a browser tab cannot: push notifications, an offline screen, a splash screen, the native share sheet, biometric prompts and, of course, a store listing.
So the agent does not write a mobile app. It makes your web app behave like one, which is exactly what reviewers check under Guideline 4.2. Keep three places apart in your head: the repository (the agent works here), the WebViewGold projects (a handful of values in Config.swift and Config.java), and the store consoles (the agent drafts, you submit).
Step zero: a project rule the agent cannot ignore
Cursor loads project rules from .cursor/rules/, and those files must use the .mdc extension; a plain .md file in that folder is ignored. Save this as .cursor/rules/native-release.mdc. It is deliberately short and release-focused; the Cursor rules template carries the full bridge reference and a scoped UI rule.
markdown
---
description: Native app release context (WebViewGold) and store rules for this repo
alwaysApply: true
---
# This web app also ships as native iOS and Android apps
- Production URL: https://app.example.com (the only URL the native apps load).
Never point anything at localhost, preview deployments or tunnel URLs.
- The apps are WebViewGold shells around this URL. Do not suggest React Native,
Expo, Capacitor or a separate mobile codebase.
- Native app detection: the user agent contains "MyAppNative" (set in WebViewGold).
Use isNativeApp() from src/lib/platform.ts; never sniff the user agent elsewhere.
- Native features are URL schemes, e.g. window.location.href = "registerpush://".
Call them only when isNativeApp() is true and keep a web fallback.
Reference: https://www.webviewgold.com/llms-full.txt (never invent a scheme).
# Store invariants (check them at the end of every task)
- /privacy and /terms exist, have real content, are linked in footer and settings.
- If users can sign up, they can delete their account in the app (server-side).
- If Google or another social login exists, Sign in with Apple is offered too.
- No digital goods sold through Stripe or other external links inside the iOS app.
- Every screen has loading, empty and error states. No dead links, no "coming soon".
- Layout works from 320 px; fixed bars use env(safe-area-inset-*); tap targets >= 44 px.
# Commands
- Dev: npm run dev | Lint: npm run lint | Test: npm test | Build: npm run build
# Done means
Lint, tests and build pass; you checked the change in the browser at 390 px and
320 px width; you listed what I must test on a real phone.The workflow from repository to store
Plan for a day or two of your own time; most of the calendar time is account setup and review.
Commit the rule and confirm it is active
Add the rule file, commit it, and open a new agent chat. Ask "Which project rules apply to this conversation?" If native-release is not in the answer, check the extension and the front matter. If you also use Cursor's cloud agents or other tools, mirror the invariants in
AGENTS.md, which Cursor reads as well.Plan the readiness pass before any edits
Switch to Plan mode (Shift+Tab in the chat input rotates through the modes), paste the prompt below, and let the agent research the codebase and ask its questions. Edit the plan until it fits your stack, save it to the workspace so it is versioned with the code, then let the agent build it.
Let the agent check its work in the browser
Cursor's agent can control a browser to take screenshots and test pages. Ask it to open every main route at 390 px and 320 px width and report what it saw. That catches overflow and hidden buttons long before a reviewer does, but it does not replace a test of the real app on a phone.
Deploy to the permanent URL
Deploy to Vercel, Netlify, Cloudflare Pages or your own server and attach your own domain. The URL is compiled into the native apps, so use the one you will keep (why the custom domain matters). Then load /privacy and /delete-account directly to make sure deep routes do not return a 404.
Configure the WebViewGold projects
iOS: in Config.swift set
hostandwebviewurl, and put your marker intouseragent_iphoneanduseragent_ipad. Android: in Config.java setHOST,HOME_URLandUSER_AGENT. With Google login, add the trigger URLs togoogle_login_helper_triggers(iOS) andGOOGLE_LOGIN_HELPER_TRIGGERS(Android). If your web app asks for push permission later viaregisterpush://, setaskforpushpermissionatfirstrunto false. You can open these files in Cursor and let the agent edit them; review every line against the iOS setup docs.Build and upload
With a Mac, archive in Xcode and upload to App Store Connect, and build a signed App Bundle in Android Studio for the Play Console. No Mac, or no wish to install either IDE: the Cloud Builder (a one-time $349 add-on per license) builds both apps in the browser and uploads them for you.
Listings, review notes, submit
Ask the agent to draft the privacy policy, the App Privacy and Data safety answers, the description and the review notes from the real code. You paste them into the consoles, add real screenshots and submit. A new personal Google Play account has to run a closed test with testers before production access.
Great work! Never coded anything but managed to work with this. Easy and fast! Also with great help from the creators!
The store-readiness prompt (Plan mode first)
Written for a typical React or Next.js app; the agent adapts it to your stack. Expect questions about where user data lives and which auth provider you use.
Paste into Cursor in Plan mode, then build with Agent
This web app will also ship as native iOS and Android apps. WebViewGold loads our production URL in a WKWebView (iOS) and an Android WebView. Follow the project rule native-release. Plan the work below as separate commits, ask me before anything touches payments or deletes data, and end with a summary plus a list of tests I must run on a real phone. 1. Platform helper: create src/lib/platform.ts with isNativeApp() (true when navigator.userAgent contains "MyAppNative") plus isIOSApp() and isAndroidApp(). Replace every other user agent check with it. 2. Mobile layout: viewport meta tag with viewport-fit=cover, no horizontal scroll from 320 to 1024 px, tap targets of at least 44 x 44 px, inputs with a font size of 16 px or more, safe-area padding on fixed headers, tab bars and bottom sheets, no hover-only controls. 3. App-like navigation: on narrow screens the main sections are one tap away, there is always a way back, and only links that leave our domain open outside the app. 4. Legal and account: real /privacy and /terms routes based on what the code collects (check auth, analytics, payments, uploads); a Delete account action in settings that removes the data and the auth user on the server; a public /delete-account page. 5. Sign-in: if Google, Facebook, GitHub or another social login exists, add Sign in with Apple as an equal option. Never open OAuth in a popup or a new window. 6. States: loading, empty and error-with-retry for every data fetch, a friendly 404 page, no unhandled promise rejections in the console. 7. Web-only elements: when isNativeApp() is true, hide app store badges, "Download our app" and "Add to home screen" prompts, builder badges and cookie banners that are not legally required. 8. Payments: list every place that sells digital goods, subscriptions or credits. Do not change them; report them. 9. Verify: run lint, tests and the production build, then open each main route in the browser at 390 px and 320 px and describe any problem you still see. 10. Draft docs/store/review-notes.md: what the app does, how a reviewer signs in (leave the demo credentials blank for me), and which native features they can try.
Which Cursor feature does what in this workflow
| Cursor feature | Use it for | Watch out for |
|---|---|---|
Project rules (.cursor/rules/*.mdc) | Native context and store invariants in every agent run | Must be .mdc; Cursor recommends keeping each rule under 500 lines |
| Plan mode | Agreeing on the readiness pass before a single file changes | Plans are saved to your home folder unless you save them to the workspace |
| Agent browser control | Screenshots of each route at phone widths, clicking through sign-up and deletion | A desktop browser at 320 px is not the native WebView; still test on a phone |
| Checkpoints | Rolling back an agent run that went sideways | Stored locally and separate from Git; commit before big runs |
| Cloud Agents | Running independent readiness tasks in parallel as branches and pull requests | Covered in the parallel readiness pass guide |
| Bugbot | Automatic pull request review against a store checklist | Ignores .cursor/rules; it reads .cursor/BUGBOT.md |
Checklist before you press Submit
- Config.swift and Config.java point to the production domain, and the user agent marker matches the one in platform.ts.
- Airplane mode shows the WebViewGold offline screen, not a blank page.
- Google login works inside the app (Social Login Helper triggers set), and Sign in with Apple sits next to it.
- Account deletion works end to end with a test account, and the reviewer demo account is in the review notes.
- If you use push, the permission prompt appears at a sensible moment, not on the very first screen.
- The free App Store readiness check passes on your production URL.
Pitfalls Cursor users run into
- The agent suggests a Capacitor or Expo rewrite "for a better mobile experience". The rule forbids it; restate it in the prompt if it happens anyway.
- A preview deployment URL lands in Config.swift. Only the production domain belongs there, because changing it later means a new store build.
- OAuth opened with
window.openor in a popup. Embedded WebViews block that; let the Social Login Helper handle Google and Facebook. - A feature reported as "done" after a desktop check only. Insist on the 320 px check and your own phone test.
- A Stripe checkout for credits or subscriptions stays visible in the iOS app. Decide first with the Stripe vs in-app purchase guide.
- API keys in the client bundle. Ask the agent to search the production build output for secrets before you deploy.
Frequently asked questions
Do Apple or Google care that Cursor wrote the code?
No. Reviewers look at behavior, completeness, privacy and payments. Which editor or agent produced the code is invisible to them.
Can the Cursor agent edit the WebViewGold Xcode and Android Studio projects?
Yes, they are normal project folders, so the agent can change values in Config.swift and Config.java. Keep it to configuration. Signing, certificates and bundle IDs are quicker and safer to set yourself in Xcode, Android Studio or the Cloud Builder.
Do I need a Mac?
Only for the manual Xcode route. The WebViewGold Cloud Builder builds and uploads the iOS and Android apps from the browser, so the whole workflow also works on Windows or Linux.
Should I use .cursorrules or .cursor/rules?
Use the .cursor/rules folder with .mdc files; it supports always-on and scoped rules. Cursor also reads AGENTS.md in the project root and in subfolders, which is handy if other tools work on the same repository.
What if the app gets rejected?
Paste the full rejection text into a new agent chat with the project rule active and ask for a triage: what the reviewer saw, which guideline it maps to, the smallest fix, and a draft reply for the Resolution Center or Play Console.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Cloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.