Skip to content
WebViewGold Vibe Coding to App Store
English
Get WebViewGold

Cursor

Cursor rules for WebViewGold apps: a .cursor/rules template that keeps every edit store-ready

Cursor applies project rules to chat, Composer and agent runs. For an app you ship through WebViewGold, the rules should carry the WebView context, the bridge syntax and the store checklist, so the agent stops suggesting browser-only solutions. Here is a two-file template and how to use it.

From $109 one-time per platform, or let our team do it all from $698.

  • Approval guarantee – or money back within 14 days
  • No coding needed
  • One-time payment, free updates
  • 24/7 human support
  • Made in Germany since 2014 · ISO 27001

How Cursor rules work

Project rules live in .cursor/rules/ as .mdc files: Markdown with a short front matter that decides when the rule is loaded. alwaysApply: true puts it in every conversation; globs attaches it automatically when matching files are in context; a description alone lets the agent pull it in when it decides the rule is relevant; and you can always reference a rule by name with @. The older single .cursorrules file in the repository root still works, but new projects should use the folder, because it allows one always-on rule and several scoped ones.

That split is exactly what a WebViewGold app needs: the WebView context and the store rules always on, and the mobile layout rules attached only when the agent edits UI files, so they do not clutter backend work.

Rule 1: webviewgold-app.mdc (always on)

Save as .cursor/rules/webviewgold-app.mdc. Replace the placeholders and remove the bridge rows you do not use. Every scheme is from the WebViewGold iOS docs and Android docs.

markdown
---
description: WebView runtime context, WebViewGold bridge and store rules for this app
alwaysApply: true
---

# Runtime
- This web app (production: https://app.example.com) is also published as native iOS and
  Android apps with WebViewGold. The native apps load the production URL in a WebView.
  There is no separate mobile codebase; never propose React Native, Expo or Capacitor.
- The native app sets the user agent marker `MYAPPNATIVE`. Detect it only via
  `isNativeApp()` in `src/lib/platform.ts`.
- Google/Facebook OAuth is handled by the wrapper (Social Login Helper); Sign in with
  Apple is handled automatically. Do not open OAuth in new windows or popups.
- When `isNativeApp()`: no "Download our app" or "Add to home screen" banners, no cookie
  banner unless legally required, no service worker install prompts.

# WebViewGold bridge (native app only, always with a web fallback)
Call a feature by navigating: `window.location.href = "scheme://..."`. Results arrive
asynchronously as global variables or callbacks; poll with a timeout.
- Push permission prompt: `registerpush://`; status: `checkNativePushPermissions://` -> `nativePushEnabled`
- OneSignal subscription ID: `getonesignalplayerid://` -> `onesignalplayerid`
- Local notification: `sendlocalpushmsg://push.send?s=SECONDS=msg!MESSAGE&!#TITLE&!#URL`
- Share sheet: `shareapp://message?=TEXT&url=URL`
- Haptics: `lighthaptic://`, `mediumhaptic://`, `heavyhaptic://`, `successhaptic://`, `warninghaptic://`, `errorhaptic://`
- Biometrics: `bioauth://` -> iOS callbacks `onBioAuthSuccess()`, `onBioAuthFailure(code, msg)`, `onBioAuthUnavailable()`
- QR scanner: `qrcode://` (scanned URL is loaded); barcode: `barcodescanner://` -> `barcodescanresult`
- Purchases (RevenueCat): `revenuecat://purchase?external_id=USER_ID&product=PRODUCT_ID`;
  restore `restoreinapppurchases://`; manage `cancelinapppurchase://`
- App version: `getappversion://` -> `versionNumber`, `bundleNumber`; install ID: `get-uuid://` -> `uuid`
- Full reference: https://www.webviewgold.com/llms-full.txt (read it before using any other scheme)

# Store rules (invariants)
- /privacy and /terms are real routes linked from footer and settings.
- Sign-up exists => Delete account exists (server-side deletion) plus a public /delete-account page.
- Third-party login exists => Sign in with Apple is offered with equal prominence.
- Digital goods, subscriptions and credits in the native app go through `revenuecat://`;
  Stripe only for browser users and for physical goods. No external payment links in the app.
- Every fetch has loading, empty, error and retry states; never a blank screen.
- User-generated or AI-generated content has report and block actions.
- No placeholder text, dead links or mixed content.

# Done means
Works in a desktop browser and at 320px; native code behind `isNativeApp()`;
no new store-rule violations; lint and tests pass; summarize device tests I must run.

Rule 2: mobile-ui.mdc (auto-attached to UI files)

Save as .cursor/rules/mobile-ui.mdc. Adjust the globs to your folder layout.

markdown
---
description: Mobile layout rules for screens rendered inside the native WebView apps
globs: src/components/**/*.tsx, src/app/**/*.tsx, src/pages/**/*.tsx, src/**/*.css
alwaysApply: false
---

- Viewport: `width=device-width, initial-scale=1, viewport-fit=cover` must stay in the document head.
- No horizontal overflow between 320px and 1024px; test flex and grid children with `min-width: 0`.
- Tap targets at least 44x44px; spacing between adjacent targets at least 8px.
- Fixed or sticky headers, footers, tab bars and bottom sheets use
  `padding-top: env(safe-area-inset-top)` / `padding-bottom: env(safe-area-inset-bottom)`.
- Inputs and selects use `font-size: 16px` or larger (prevents zoom on iOS).
- No hover-only interactions; every hover state has a tap equivalent.
- Images and embeds have explicit width and height or aspect-ratio to avoid layout shift.
- Long lists are paginated or virtualized; a WebView has less memory than a desktop tab.
- Prefer in-app bottom navigation over a hamburger menu in the native app.
- Dark mode: respect `prefers-color-scheme` or provide a setting; never pure white flashes on navigation.

WebViewGold has allowed us the shortest and most efficient time-to-market ever possible from among all the other app platforms we have ever tried during the past 5 years. I don’t know why I hadn’t discovered you sooner, but I am really, really glad I did. Currently nearing 6000 app downloads on both iOS App Store & Google Play Store without any problem!

Antonio Davila · CodeCanyon

What each block does

Runtime block

Stops the three most common wrong turns: proposing a native rewrite, breaking OAuth with popups, and shipping web-only banners into the app. The user agent marker is set in WebViewGold: useragent_iphone / useragent_ipad in Config.swift, USER_AGENT in Config.java.

Bridge block

Exact schemes and result variable names. Without it, Cursor invents a window.native object or reaches for the Web Share API. The last line sends it to the full documentation for anything not listed.

Store rules block

Invariants, so they apply to every future task and are checked at the end. The payment rule prevents the most expensive rejection (Apple 3.1.1); the deletion and Sign in with Apple rules prevent the most common ones (5.1.1, 4.8).

Mobile UI rule

Auto-attached only when UI files are in context, which keeps backend conversations clean. It is the same checklist reviewers apply under Guideline 4.0 and Google's broken functionality policy.

How Cursor agent mode uses the rules

In agent mode, Cursor plans, edits files, runs commands and iterates. The always-on rule is part of every plan, so when you ask for "a Face ID lock on the wallet page", the plan already says: guard with isNativeApp(), navigate to bioauth://, implement the iOS callbacks, keep a password fallback on the web, and keep a server-side check. The mobile rule joins the context as soon as the agent opens a component file.

Two habits make it reliable. First, add the WebViewGold documentation as a docs source in Cursor (the @Docs feature accepts a URL; use https://www.webviewgold.com/llms-full.txt) so the agent can read a feature section instead of guessing. Second, end feature prompts with "check the result against the WebViewGold docs and the store rules", which makes the agent re-read both before it reports. The llms.txt guide describes the verification routine in detail.

A prompt to test the rules

Paste into Cursor agent mode
Add a biometric lock in front of the /wallet route. Follow the project rules: in the native app, navigate to the biometric scheme from the rules and handle the success, failure and unavailable callbacks; on the web, fall back to re-entering the password. Unlock state lives in session storage for 5 minutes and the server must still verify the session on every wallet request. Keep the mobile UI rules for the lock screen. Then check your result against https://www.webviewgold.com/llms-full.txt and the store rules, and list what you verified.

Before you commit the rules

  • The production URL and the user agent marker in the rule match the values in Config.swift and Config.java.
  • The globs in mobile-ui.mdc match your real folder layout; open a component and confirm the rule attaches.
  • Every bridge row you kept is a feature that is enabled in the WebViewGold project, or will be.
  • The commands section names scripts that exist in package.json, so the agent can run lint and tests.

Frequently asked questions

.cursorrules or .cursor/rules?

Use the .cursor/rules folder for new projects; it supports several scoped rules and the front matter that controls when each one loads. A legacy .cursorrules file still works if you have one.

Do the rules apply to Tab completions?

Rules are for chat, Composer and agent conversations. Inline completions are driven by the surrounding code, which is another reason to keep isNativeApp() and the bridge calls in one well-named helper file.

How does Cursor read llms-full.txt?

Add it as a docs source (@Docs with the URL), reference it with @Web in a prompt, or commit a copy into the repository and mention the path in the rule. A committed copy is the most deterministic.

Can I ship the app from Cursor without a Mac?

The web app, yes. The native build needs Xcode for iOS, or the WebViewGold Cloud Builder, which builds and uploads both apps from the browser.

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.

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 page

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 demo

Full 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 WeSetupYourWebViewApp

Winter Sale prices valid until December 31, 2026.

Ready to ship your app?

App Store & Google Play approval guarantee – or your money back within 14 days

Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.

Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.