Zum Inhalt springen
WebViewGold Vibe Coding in den App Store
Deutsch
WebViewGold holen

Cursor

Cursor Rules für WebViewGold-Apps: ein .cursor/rules-Template, das jede Änderung Store-fertig hält

Cursor wendet Project Rules auf Chat, Composer und Agent-Läufe an. Für eine App, die du mit WebViewGold veröffentlichst, sollten die Rules den WebView-Kontext, die Syntax der Bridge und die Store-Checkliste enthalten, damit der Agent aufhört, reine Browser-Lösungen vorzuschlagen. Hier ist ein Template aus zwei Dateien und wie du es nutzt.

Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.

  • Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
  • Kein Programmieren nötig
  • Einmalzahlung, kostenlose Updates
  • 24/7 Support von echten Menschen
  • Made in Germany seit 2014 · ISO 27001

Wie Cursor Rules funktionieren

Project Rules liegen in .cursor/rules/ als .mdc-Dateien: Markdown mit einem kurzen Front Matter, das festlegt, wann die Rule geladen wird. alwaysApply: true nimmt sie in jede Unterhaltung auf; globs hängt sie automatisch an, wenn passende Dateien im Kontext sind; eine description allein lässt den Agenten sie hinzuziehen, wenn er sie für relevant hält; und per @ kannst du eine Rule jederzeit namentlich referenzieren. Die ältere einzelne .cursorrules-Datei im Root des Repositorys funktioniert weiterhin, aber neue Projekte sollten den Ordner nutzen, weil er eine immer aktive Rule und mehrere gezielt angehängte erlaubt.

Genau diese Aufteilung braucht eine WebViewGold-App: WebView-Kontext und Store-Regeln sind immer aktiv, die Regeln für das mobile Layout nur dann, wenn der Agent UI-Dateien bearbeitet, damit sie die Backend-Arbeit nicht überfrachten.

Rule 1: webviewgold-app.mdc (immer aktiv)

Speichere sie als .cursor/rules/webviewgold-app.mdc. Ersetze die Platzhalter und entferne die Bridge-Zeilen, die du nicht nutzt. Jedes Schema stammt aus den WebViewGold-iOS-Docs und den 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 (automatisch an UI-Dateien angehängt)

Speichere sie als .cursor/rules/mobile-ui.mdc. Passe die Globs an deine Ordnerstruktur an.

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 hat uns die kürzeste und effizienteste Time-to-Market ermöglicht, die jemals möglich war, verglichen mit allen anderen App-Plattformen, die wir in den letzten 5 Jahren ausprobiert haben. Ich weiß nicht, warum ich euch nicht schon früher entdeckt habe, aber ich bin wirklich, wirklich froh, dass ich es getan habe. Wir nähern uns derzeit fast 6000 App-Downloads im iOS App Store & Google Play Store ohne Probleme!

Antonio Davila · CodeCanyon

Was die einzelnen Blöcke tun

Runtime-Block

Verhindert die drei häufigsten Irrwege: einen nativen Rewrite vorschlagen, OAuth mit Popups kaputtmachen und reine Web-Banner in die App ausliefern. Der User-Agent-Marker wird in WebViewGold gesetzt: useragent_iphone / useragent_ipad in Config.swift, USER_AGENT in Config.java.

Bridge-Block

Exakte Schemas und Namen der Ergebnisvariablen. Ohne ihn erfindet Cursor ein window.native-Objekt oder greift zur Web Share API. Die letzte Zeile verweist für alles, was nicht gelistet ist, auf die vollständige Dokumentation.

Block mit den Store-Regeln

Invarianten, damit sie für jede künftige Aufgabe gelten und am Ende geprüft werden. Die Zahlungsregel verhindert die teuerste Ablehnung (Apple 3.1.1); die Regeln zur Kontolöschung und zu Sign in with Apple verhindern die häufigsten (5.1.1, 4.8).

Mobile-UI-Rule

Wird nur angehängt, wenn UI-Dateien im Kontext sind, und hält so Backend-Unterhaltungen sauber. Es ist dieselbe Checkliste, die Reviewer unter Richtlinie 4.0 und Googles Richtlinie zu fehlerhafter Funktionalität anwenden.

Wie der Agent-Modus von Cursor die Rules nutzt

Im Agent-Modus plant Cursor, bearbeitet Dateien, führt Befehle aus und iteriert. Die immer aktive Rule ist Teil jedes Plans: Wenn du nach "einer Face-ID-Sperre für die Wallet-Seite" fragst, steht im Plan bereits: mit isNativeApp() absichern, zu bioauth:// navigieren, die iOS-Callbacks implementieren, im Web einen Passwort-Fallback behalten und eine serverseitige Prüfung beibehalten. Die Mobile-Rule kommt in den Kontext, sobald der Agent eine Komponentendatei öffnet.

Zwei Gewohnheiten machen das zuverlässig. Erstens: Füge die WebViewGold-Dokumentation in Cursor als Docs-Quelle hinzu (das @Docs-Feature akzeptiert eine URL; nutze https://www.webviewgold.com/llms-full.txt), damit der Agent einen Feature-Abschnitt lesen kann, statt zu raten. Zweitens: Beende Feature-Prompts mit "prüfe das Ergebnis gegen die WebViewGold-Docs und die Store-Regeln", damit der Agent beides noch einmal liest, bevor er berichtet. Der llms.txt-Guide beschreibt die Prüfroutine im Detail.

Ein Prompt, um die Rules zu testen

In den Agent-Modus von Cursor einfügen
Füge vor der Route /wallet eine biometrische Sperre ein. Halte dich an die Project Rules: In der nativen App navigierst du zum Biometrie-Schema aus den Rules und behandelst die Callbacks für Erfolg, Fehlschlag und Nichtverfügbarkeit; im Web fällst du auf die erneute Passworteingabe zurück. Der Entsperrstatus liegt 5 Minuten lang im Session Storage, und der Server muss die Session trotzdem bei jedem Wallet-Request prüfen. Halte für den Sperrbildschirm die Mobile-UI-Rules ein. Prüfe dann dein Ergebnis gegen https://www.webviewgold.com/llms-full.txt und die Store-Regeln und liste auf, was du geprüft hast.

Bevor du die Rules committest

  • Produktions-URL und User-Agent-Marker in der Rule stimmen mit den Werten in Config.swift und Config.java überein.
  • Die Globs in mobile-ui.mdc passen zu deiner echten Ordnerstruktur; öffne eine Komponente und prüfe, ob die Rule angehängt wird.
  • Jede Bridge-Zeile, die du behalten hast, ist ein Feature, das im WebViewGold-Projekt aktiviert ist oder noch aktiviert wird.
  • Der Abschnitt mit den Befehlen nennt Scripts, die es in package.json wirklich gibt, damit der Agent Lint und Tests ausführen kann.

Häufig gestellte Fragen

.cursorrules oder .cursor/rules?

Nutze für neue Projekte den Ordner .cursor/rules; er unterstützt mehrere gezielte Rules und das Front Matter, das steuert, wann welche geladen wird. Eine alte .cursorrules-Datei funktioniert weiterhin, falls du eine hast.

Gelten die Rules auch für Tab-Vervollständigungen?

Rules sind für Chat, Composer und Agent-Unterhaltungen gedacht. Inline-Vervollständigungen richten sich nach dem umgebenden Code; ein weiterer Grund, isNativeApp() und die Bridge-Aufrufe in einer gut benannten Helper-Datei zu bündeln.

Wie liest Cursor die llms-full.txt?

Füge sie als Docs-Quelle hinzu (@Docs mit der URL), referenziere sie in einem Prompt mit @Web oder committe eine Kopie ins Repository und nenne den Pfad in der Rule. Eine committete Kopie ist am deterministischsten.

Kann ich die App ohne Mac aus Cursor heraus veröffentlichen?

Die Web-App ja. Für den nativen Build brauchst du Xcode für iOS oder den WebViewGold Cloud Builder, der beide Apps aus dem Browser baut und hochlädt.

Drei Wege, deine App in die Stores zu bringen

Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.

Selbst machen

$109 pro Plattform, einmalig

Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.

Pakete auf der Hauptseite ansehen

Full Service

$698 pro Plattform $798

Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.

Full-Service-Details Powered by WeSetupYourWebViewApp

Winter-Sale-Preise gültig bis 31. Dezember 2026.

Bereit, deine App zu veröffentlichen?

App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen

Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.

Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.