Cursor
Du hast die Web-App mit dem Agenten von Cursor gebaut, und für iOS- und Android-Apps brauchst du keine zweite Codebasis. Bring dem Agenten mit einer einzigen Projektregel den nativen Kontext bei, lass ihn einen Store-Readiness-Pass planen und umsetzen, deploye, richte WebViewGold auf die URL aus, baue und reiche ein. Hier ist der ganze Ablauf mit Regeldatei und Prompt.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Dein Cursor-Projekt lebt weiter unter seiner URL, und zwei native Apps laden es. WebViewGold liefert diese Apps als fertiges Xcode-Projekt und fertiges Android-Studio-Projekt. Der Hauptbildschirm ist auf iOS eine WKWebView und auf Android eine Android WebView, und die Hülle ergänzt, was ein Browser-Tab nicht kann: Push-Benachrichtigungen, einen Offline-Bildschirm, einen Splash-Screen, das native Share Sheet, biometrische Abfragen und natürlich einen Eintrag im Store.
Der Agent schreibt also keine mobile App. Er sorgt dafür, dass sich deine Web-App wie eine App verhält, und genau das prüfen Reviewer unter Richtlinie 4.2. Halte drei Orte auseinander: das Repository (hier arbeitet der Agent), die WebViewGold-Projekte (eine Handvoll Werte in Config.swift und Config.java) und die Store-Konsolen (der Agent entwirft, du reichst ein).
Cursor lädt Projektregeln aus .cursor/rules/, und diese Dateien brauchen die Endung .mdc; eine normale .md-Datei in diesem Ordner wird ignoriert. Speichere das hier als .cursor/rules/native-release.mdc. Die Regel ist bewusst kurz und aufs Release ausgerichtet; das Cursor-Rules-Template enthält die vollständige Bridge-Referenz und eine Regel speziell für UI-Dateien.
---
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.Plane ein bis zwei Tage deiner eigenen Zeit ein; die meiste Kalenderzeit geht für Konten und Review drauf.
Füge die Regeldatei hinzu, committe sie und öffne einen neuen Agent-Chat. Frag: "Welche Projektregeln gelten für diese Unterhaltung?" Taucht native-release in der Antwort nicht auf, prüfe Dateiendung und Front Matter. Nutzt du auch die Cloud Agents von Cursor oder andere Tools, übernimm die Store-Regeln zusätzlich in AGENTS.md, die Cursor ebenfalls liest.
Wechsle in den Plan-Modus (Shift+Tab im Chat-Eingabefeld schaltet durch die Modi), füge den Prompt unten ein und lass den Agenten die Codebasis untersuchen und seine Fragen stellen. Überarbeite den Plan, bis er zu deinem Stack passt, speichere ihn im Workspace, damit er mit dem Code versioniert wird, und lass den Agenten ihn dann umsetzen.
Der Agent von Cursor kann einen Browser steuern, Screenshots machen und Seiten testen. Bitte ihn, jede Hauptroute bei 390 px und 320 px Breite zu öffnen und zu berichten, was er gesehen hat. So findest du Überläufe und verdeckte Buttons lange vor einem Reviewer, aber einen Test der echten App auf einem Handy ersetzt das nicht.
Deploye auf Vercel, Netlify, Cloudflare Pages oder deinen eigenen Server und hänge deine eigene Domain an. Die URL wird in die nativen Apps kompiliert, also nimm die, die du behalten wirst (warum die eigene Domain zählt). Lade danach /privacy und /delete-account direkt, um sicherzugehen, dass Unterseiten keinen 404 liefern.
iOS: Setze in Config.swift host und webviewurl und trage deinen Marker in useragent_iphone und useragent_ipad ein. Android: Setze in Config.java HOST, HOME_URL und USER_AGENT. Bei Google-Login kommen die Trigger-URLs in google_login_helper_triggers (iOS) und GOOGLE_LOGIN_HELPER_TRIGGERS (Android). Fragt deine Web-App die Push-Berechtigung erst später über registerpush:// an, setze askforpushpermissionatfirstrun auf false. Du kannst diese Dateien in Cursor öffnen und vom Agenten bearbeiten lassen; prüfe jede Zeile anhand der iOS-Setup-Doku.
Mit einem Mac archivierst du in Xcode und lädst zu App Store Connect hoch; in Android Studio baust du ein signiertes App Bundle für die Play Console. Kein Mac, oder keine Lust, eine der beiden IDEs zu installieren? Der Cloud Builder (ein einmaliges Add-on für $349 pro Lizenz) baut beide Apps im Browser und lädt sie für dich hoch.
Lass den Agenten die Datenschutzerklärung, die Antworten zu App Privacy und Data safety, die Beschreibung und die Review-Notizen aus dem echten Code entwerfen. Du fügst sie in die Konsolen ein, ergänzt echte Screenshots und reichst ein. Ein neues privates Google-Play-Konto muss vor dem Zugang zur Produktion einen geschlossenen Test mit Testern durchlaufen.
Großartige Arbeit! Ich habe noch nie etwas programmiert, aber ich konnte damit arbeiten. Einfach und schnell! Auch mit großartiger Hilfe von den Erstellern!
Geschrieben für eine typische React- oder Next.js-App; der Agent passt ihn an deinen Stack an. Rechne mit Fragen dazu, wo Nutzerdaten liegen und welchen Auth-Provider du nutzt.
Diese Web-App erscheint zusätzlich als native iOS- und Android-App. WebViewGold lädt unsere Produktions-URL in einer WKWebView (iOS) und einer Android WebView. Halte dich an die Projektregel native-release. Plane die Arbeit unten als einzelne Commits, frag mich, bevor etwas Zahlungen berührt oder Daten löscht, und schließe mit einer Zusammenfassung und einer Liste der Tests ab, die ich auf einem echten Handy machen muss. 1. Plattform-Helper: Lege src/lib/platform.ts mit isNativeApp() an (true, wenn navigator.userAgent "MyAppNative" enthält) sowie isIOSApp() und isAndroidApp(). Ersetze jede andere User-Agent-Prüfung dadurch. 2. Mobiles Layout: Viewport-Meta-Tag mit viewport-fit=cover, kein horizontales Scrollen von 320 bis 1024 px, Tap-Targets von mindestens 44 x 44 px, Eingabefelder mit mindestens 16 px Schriftgröße, Safe-Area-Padding an fixierten Headern, Tab-Bars und Bottom Sheets, keine Bedienelemente, die nur per Hover funktionieren. 3. App-typische Navigation: Auf schmalen Bildschirmen sind die Hauptbereiche einen Tipp entfernt, es gibt immer einen Weg zurück, und nur Links, die unsere Domain verlassen, öffnen sich außerhalb der App. 4. Rechtliches und Konto: echte Routen /privacy und /terms auf Basis dessen, was der Code erhebt (prüfe Auth, Analytics, Zahlungen, Uploads); eine Aktion "Konto löschen" in den Einstellungen, die die Daten und den Auth-Nutzer auf dem Server entfernt; eine öffentliche Seite /delete-account. 5. Anmeldung: Gibt es einen Login mit Google, Facebook, GitHub oder einem anderen Social Login, ergänze Sign in with Apple als gleichwertige Option. Öffne OAuth nie in einem Popup oder einem neuen Fenster. 6. Zustände: Lade-, Leer- und Fehlerzustand mit Wiederholen für jeden Datenabruf, eine freundliche 404-Seite, keine unbehandelten Promise-Rejections in der Konsole. 7. Reine Web-Elemente: Wenn isNativeApp() true ist, blende App-Store-Badges, Hinweise wie "Lade unsere App herunter" und "Zum Home-Bildschirm hinzufügen", Builder-Badges und rechtlich nicht vorgeschriebene Cookie-Banner aus. 8. Zahlungen: Liste jede Stelle auf, an der digitale Güter, Abos oder Credits verkauft werden. Ändere nichts daran; berichte nur. 9. Prüfen: Führe Lint, Tests und den Produktions-Build aus, öffne dann jede Hauptroute im Browser bei 390 px und 320 px und beschreibe jedes Problem, das du noch siehst. 10. Entwirf docs/store/review-notes.md: was die App tut, wie sich ein Reviewer anmeldet (lass die Demo-Zugangsdaten für mich leer) und welche nativen Features er ausprobieren kann.
| Cursor-Feature | Wofür | Achte auf |
|---|---|---|
Projektregeln (.cursor/rules/*.mdc) | Nativer Kontext und Store-Regeln in jedem Agent-Lauf | Müssen .mdc sein; Cursor empfiehlt, jede Regel unter 500 Zeilen zu halten |
| Plan-Modus | Den Readiness-Pass abstimmen, bevor sich auch nur eine Datei ändert | Pläne landen in deinem Home-Ordner, wenn du sie nicht im Workspace speicherst |
| Browser-Steuerung des Agenten | Screenshots jeder Route in Handy-Breite, Registrierung und Löschung durchklicken | Ein Desktop-Browser bei 320 px ist nicht die native WebView; trotzdem auf einem Handy testen |
| Checkpoints | Einen Agent-Lauf zurückrollen, der aus dem Ruder gelaufen ist | Lokal gespeichert und unabhängig von Git; vor großen Läufen committen |
| Cloud Agents | Unabhängige Readiness-Aufgaben parallel als Branches und Pull Requests abarbeiten | Erklärt im Guide zum parallelen Readiness-Pass |
| Bugbot | Automatisches Review von Pull Requests anhand einer Store-Checkliste | Ignoriert .cursor/rules; liest .cursor/BUGBOT.md |
window.open oder in einem Popup geöffnet. Eingebettete WebViews blockieren das; überlass Google und Facebook dem Social-Login-Helper.Nein. Reviewer schauen auf Verhalten, Vollständigkeit, Datenschutz und Zahlungen. Welcher Editor oder Agent den Code erzeugt hat, sehen sie gar nicht.
Ja, das sind normale Projektordner, also kann der Agent Werte in Config.swift und Config.java ändern. Beschränke ihn auf die Konfiguration. Signierung, Zertifikate und Bundle-IDs stellst du schneller und sicherer selbst in Xcode, Android Studio oder im Cloud Builder ein.
Nur für den manuellen Weg über Xcode. Der WebViewGold Cloud Builder baut die iOS- und die Android-App im Browser und lädt sie hoch, der ganze Workflow funktioniert also auch unter Windows oder Linux.
Nimm den Ordner .cursor/rules mit .mdc-Dateien; er unterstützt immer aktive und auf bestimmte Dateien beschränkte Regeln. Cursor liest außerdem AGENTS.md im Projekt-Root und in Unterordnern, praktisch, wenn andere Tools am selben Repository arbeiten.
Füge den vollständigen Ablehnungstext in einen neuen Agent-Chat mit aktiver Projektregel ein und bitte um eine Triage: was der Reviewer gesehen hat, welche Richtlinie dahintersteht, der kleinste Fix und ein englischer Antwortentwurf für das Resolution Center oder die Play Console.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$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$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$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
Winter-Sale-Preise gültig bis 31. Dezember 2026.
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.