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

Cursor

Cursor Background Agents für den Store-Readiness-Pass: parallele Aufgaben, geprüft als Pull Requests

Die Background Agents von Cursor, inzwischen Cloud Agents genannt, laufen auf isolierten Cloud-Maschinen, arbeiten auf einem eigenen Branch und liefern einen Pull Request zurück. Das passt gut zur Vorbereitung auf den App Store: Teile die Readiness-Arbeit in unabhängige Aufgaben auf, starte sie parallel und prüfe jedes Ergebnis wie den PR eines Teamkollegen, bevor irgendetwas in den nativen Build gelangt.

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

Warum die Store-Vorbereitung ein guter Job für parallele Agenten ist

Ein Store-Readiness-Pass ist eine Checkliste aus weitgehend unabhängigen Fixes: Rechtsseiten, Kontolöschung, mobiles Layout, Fehlerzustände, das Ausblenden reiner Web-Elemente, Review-Notizen. In einer langen lokalen Session stapeln sich diese Änderungen zu einem einzigen Diff, das schwer zu prüfen ist. Auf Cloud Agents verteilt, fasst jede Aufgabe ihre eigenen Dateien an, landet als eigener Pull Request und lässt sich einzeln annehmen, zurückgeben oder neu starten.

Das Ziel ist dasselbe wie im kompletten Cursor-Workflow: eine Web-App, die sich wie eine App verhält, wenn WebViewGold sie in einer nativen WebView lädt. Diese Seite behandelt nur den parallelen Teil und das, was du weiterhin selbst erledigen musst. Alles andere zum Veröffentlichen von Cursor-Projekten findest du auf der Cursor-Übersichtsseite.

Was Cloud Agents sind, in sechs Fakten

Isolierte Maschinen

Jeder Agent läuft in einer eigenen Cloud-VM mit vollständiger Entwicklungsumgebung. Er klont dein Repository, arbeitet auf einem separaten Branch und pusht das Ergebnis zum Review zurück.

Viele Wege zum Start

Wähle Cloud unter dem Agent-Eingabefeld in Cursor, nutze cursor.com/agents auf jedem Gerät, erwähne @cursor in Slack oder Linear oder kommentiere @cursor in einem GitHub-Issue oder Pull Request.

Zuerst die Versionsverwaltung

Ein Admin des Cursor-Kontos verbindet die Versionsverwaltung (GitHub, GitLab, Bitbucket Cloud oder Azure DevOps), und der Agent braucht Lese- und Schreibzugriff auf das Repository.

Secrets im Dashboard

Lege API-Keys und Test-Zugangsdaten als Secrets im Cursor-Dashboard an, statt eine .env-Datei zu committen. Sie werden beim Start eines Agenten injiziert, bereits laufende Agenten sehen neue Secrets also nicht.

Sie lesen AGENTS.md

Die Doku von Cursor zu Cloud Agents sagt es klar, also schreib den Kontext der nativen App und die Store-Regeln in AGENTS.md, nicht nur in .cursor/rules.

Nutzungsbasierte Kosten

Läufe werden zum Tarif des gewählten Modells abgerechnet, und nicht jeder Plan enthält sie. Beim ersten Einsatz legst du ein Ausgabenlimit fest; halte es vernünftig, bevor du sechs Agenten auf einmal startest.

Gib jedem Agenten eine funktionierende Umgebung

Agenten können die Umgebung selbst einrichten (und als Snapshot speichern), oder du committest .cursor/environment.json. Für eine typische Node-Web-App reicht das hier: Abhängigkeiten installieren, den Dev-Server in einem Terminal starten, das der Agent sieht, den Port freigeben. Die Feldnamen stammen aus dem veröffentlichten Schema von Cursor; die Beschreibung des Terminals bekommt der Agent angezeigt.

json
{
  "install": "npm ci",
  "terminals": [
    {
      "name": "web",
      "command": "npm run dev -- --port 3000",
      "description": "Dev server. Check changed routes here at 390 px and 320 px width."
    }
  ],
  "ports": [
    { "name": "web app", "port": 3000 }
  ]
}

Mit einer gut optimierten Version Ihrer Web-App können Sie innerhalb von wenigen Minuten eine beeindruckende mobile App erstellen. Zusätzlich dazu ist der Kundenservice sehr nett und hilfsbereit! Ich kann WebViewGold nur empfehlen :-)

Julian Koch · Mitbegründer von DuelDonkey · CodeCanyon

Einen Abschnitt für Cloud Agents in AGENTS.md ergänzen

Committe das in den Default-Branch, bevor du irgendetwas startest. Der erste Block ist der gemeinsame Kontext der nativen App; der zweite sagt jedem Agenten, wie er sich als einer von mehreren Workern verhält.

markdown
## Native app (WebViewGold)
This web app also ships as iOS and Android apps. WebViewGold loads
https://app.example.com in a native WebView; every deploy is live in both apps.
- Detect the app only with isNativeApp() (user agent contains "MyAppNative").
- Native features are URL schemes from https://www.webviewgold.com/llms-full.txt.
  Never invent one; always keep a web fallback.
- Store invariants: real /privacy and /terms; in-app account deletion (server-side);
  Sign in with Apple next to any social login; no external checkout for digital
  goods in the iOS app; loading, empty and error states; layout works at 320 px.

## Cloud agents
- One task per agent. Touch only the files the task needs. If you must edit a
  shared layout file, say so at the top of the PR description.
- Run npm run lint, npm test and npm run build before you push.
- Check every route you changed in the browser at 390 px and 320 px and describe
  what you saw in the PR.
- PR description: what changed, how you verified it, open questions, and what
  needs a test on a real iPhone and Android phone.
- You cannot run the native app. Never claim you tested on iOS or Android.

Den Pass in parallele Aufgaben aufteilen

AgentAufgabeTypische DateienFertig, wenn
1. RechtsseitenEchte Seiten /privacy und /terms auf Basis dessen, was der Code erhebt, verlinkt in Footer und EinstellungenRouten, Footer, Einstellungs-ScreenBeide URLs laden direkt und nennen jedes SDK, das Daten erhebt
2. Kontolöschung"Konto löschen" in den Einstellungen plus öffentliche Seite /delete-account; der Server löscht Daten, Dateien und den Auth-NutzerEinstellungen, API-Route, Auth-HelperEin Testnutzer ist aus der Datenbank und beim Auth-Provider verschwunden (Anforderungen an die Löschung)
3. Zustände und SackgassenLade-, Leer- und Fehlerzustände mit Wiederholen; eine 404-Seite; "Coming soon"-Buttons entfernenDaten-Komponenten, RouterKlicks ohne Verbindung zeigen einen Fehlerzustand, nie einen leeren Bildschirm
4. App-ModusHelper isNativeApp(); Store-Badges, Installationshinweise und Builder-Badges in der App ausblendenPlattform-Helper, BannerMit gefälschtem User-Agent verschwindet jedes reine Web-Element
5. Store-Entwürfedocs/store/: Review-Notizen, Beschreibung, Keywords, eine Dateninventur für App Privacy und Data safetyNur DokuJeder Datentyp in der Inventur verweist auf Code im Repo
6. Mobiles Layout (zuletzt)Überlauf, Tap-Targets, Safe-Area-Padding, 16-px-Eingabefelder, keine reinen Hover-BedienelementeCSS, Layout-KomponentenKein horizontales Scrollen bei 320 px auf irgendeiner Hauptroute

Eine Prompt-Vorlage für alle sechs Agenten

Halte den gemeinsamen Teil identisch, damit jeder Pull Request gleich aussieht; nur der Aufgabenblock ändert sich. Das Beispiel zeigt Agent 2.

In jeden Cloud Agent einfügen, nur den Block AUFGABE austauschen
Kontext: Diese Web-App erscheint über WebViewGold zusätzlich als native iOS- und Android-App; WebViewGold lädt unsere Produktions-URL in einer WKWebView und einer Android WebView. Lies zuerst AGENTS.md und halte dich an die Abschnitte "Native app" und "Cloud agents".

Regeln für diesen Lauf:
- Arbeite nur an der Aufgabe unten. Refaktoriere keinen fremden Code und füge keine Abhängigkeiten hinzu, außer die Aufgabe braucht sie.
- Führe vor dem Push Lint, Tests und den Produktions-Build aus.
- Öffne einen Pull Request mit dem Titel "store-readiness: <Name der Aufgabe>". Liste in der Beschreibung auf, was sich geändert hat, wie du es geprüft hast (Routen und Breiten), offene Fragen und was ich auf einem echten iPhone und Android-Handy testen muss.
- Wenn etwas unklar ist, zum Beispiel welche Tabellen Nutzerdaten enthalten, halte an und frag im Pull Request nach, statt zu raten.

AUFGABE: Kontolöschung
- Ergänze in den Einstellungen eine Aktion "Konto löschen" mit Bestätigungsschritt.
- Rufe nach der Bestätigung einen serverseitigen Endpoint auf, der die Zeilen des Nutzers in jeder Tabelle löscht, die auf den Nutzer verweist, seine gespeicherten Dateien löscht und den Auth-Nutzer löscht. Melde ihn danach ab und zeige einen Bestätigungsbildschirm.
- Ergänze eine öffentliche Seite /delete-account, die die Schritte in der App erklärt und eine Möglichkeit bietet, die Löschung ohne App anzufordern (Formular oder E-Mail-Adresse).
- Ergänze einen Test, der einen Nutzer anlegt, ihn löscht und sicherstellt, dass keine Zeilen oder Dateien übrig bleiben.

Den Pass durchführen

Etwa eine Stunde Einrichtung, danach vor allem Review-Zeit.

  1. Versionsverwaltung verbinden und Umgebung vorbereiten

    Ein Admin verbindet in Cursor den Repository-Anbieter. Committe environment.json oder lass den ersten Agenten die Umgebung einrichten und als Snapshot speichern, damit spätere Agenten schneller starten.

  2. AGENTS.md und .cursor/BUGBOT.md committen

    Agenten lesen AGENTS.md; Bugbot liest .cursor/BUGBOT.md (Beispiel unten). Beide müssen vor dem ersten Start im Default-Branch liegen.

  3. Secrets und ein Testkonto anlegen

    Hinterlege die URL der Staging-Datenbank, Test-Zugangsdaten und API-Keys als Secrets im Dashboard. Ohne Test-Login können Agenten keine Screens hinter dem Login prüfen und sagen dir dann, sie "sollten funktionieren".

  4. Agenten 1 bis 5 gemeinsam starten

    Starte sie über das Agent-Eingabefeld (Cloud), über cursor.com/agents oder lege pro Aufgabe ein GitHub-Issue an und kommentiere @cursor mit dem Prompt. Starte Agent 6 erst, wenn die anderen gemergt sind, denn die Layout-Arbeit betrifft dieselben Komponenten.

  5. Jeden Pull Request prüfen

    Lies Diff und Beschreibung, lass Bugbot kommentieren und öffne das Preview-Deployment im Browser deines Handys. Für Änderungswünsche kommentierst du @cursor im Pull Request mit dem, was korrigiert werden soll.

  6. Mergen, deployen, in der echten App testen

    Merge in einer sinnvollen Reihenfolge, deploye in die Produktion und teste dann den WebViewGold-Build auf echten Geräten. Cloud Agents können die native App nicht ausführen, dieser Schritt bleibt also bei dir.

.cursor/BUGBOT.md: eine Store-Review-Checkliste für jeden Pull Request

Bugbot nutzt deine .cursor/rules-Dateien nicht; er liest .cursor/BUGBOT.md (die Datei im Root immer, verschachtelte in der Nähe der geänderten Dateien). Er läuft bei jedem Update eines Pull Requests, und ein Kommentar cursor review oder bugbot run startet ihn von Hand.

markdown
# Store review rules
This app ships as iOS and Android apps via WebViewGold (native WebView around our URL).

Flag as a bug:
- New fixed or sticky UI without env(safe-area-inset-*) padding.
- Tap targets smaller than 44 x 44 px, or hover-only interactions.
- OAuth opened via window.open, target="_blank" or a popup.
- A native URL scheme (registerpush://, shareapp://, bioauth:// ...) called without
  an isNativeApp() check or without a web fallback.
- Purchase or upgrade buttons for digital goods that link to an external checkout
  inside the native app.
- Removing or breaking /privacy, /terms, /delete-account or the Delete account action.
- Data fetching without loading, empty and error states.
- Secrets or service-role keys in client-side code.

Ignore: styling preferences, naming, and refactors that do not change behavior.

Was du in jedem Pull Request prüfst

  • Das Diff fasst nur Dateien an, die zur Aufgabe passen; fremde Änderungen sind ein Grund, den PR zurückzugeben.
  • Lint, Tests und Build sind gelaufen, und die Beschreibung sagt das.
  • Screens hinter dem Login wurden wirklich geprüft: Die Beschreibung nennt das Testkonto, nicht "sollte funktionieren".
  • Es ist kein neues SDK und kein Tracker hineingerutscht, den du in App Privacy und Data safety angeben müsstest.
  • Die Texte sind echt: kein Lorem ipsum, kein "Your Company Inc." in der Datenschutzerklärung.
  • Alles Native (Push, Teilen, Biometrie) liegt hinter isNativeApp() mit Web-Fallback.

Stolperfallen

  • Mehrere Agenten an denselben Dateien: Merge-Konflikte fressen die gesparte Zeit. Teile nach Dateibereichen auf, nicht nach Ideen.
  • Agenten, die "auf iOS getestet" melden. Sie laufen in Cloud-VMs ohne deine native App; Tests auf echten Geräten bleiben bei dir.
  • Eine Preview-Deployment-URL, die in die WebViewGold-Config kopiert wurde. In Config.swift und Config.java gehört nur die Produktionsdomain.
  • Committete Secrets, weil ein Agent sie "brauchte". Nutze Secrets im Dashboard und rotiere alles, was ins Repository gelangt ist.
  • Sechs Agenten auf einem großen Modell summieren sich. Fang mit zwei oder drei an, prüfe die Qualität der Pull Requests und skaliere dann.
  • AGENTS.md und .cursor/rules widersprechen sich. Agenten folgen dem, was sie gerade lesen; halte die Store-Regeln identisch (so behältst du eine einzige Quelle).

Häufig gestellte Fragen

Sind Background Agents und Cloud Agents dasselbe?

Ja. Cursor hat die Background Agents in Cloud Agents umbenannt. Ältere Tutorials verwenden noch den alten Namen; die Idee ist dieselbe: ein Agent in einer isolierten Cloud-VM, der auf einem eigenen Branch arbeitet und das Ergebnis zurückgibt.

Folgen Cloud Agents meinen .cursor/rules?

Die Doku von Cursor zu Cloud Agents sagt ausdrücklich, dass sie AGENTS.md lesen; das ist also der sichere Ort für alles, woran sich jeder Agent halten muss. Behalte deine Projektregeln für die lokale Arbeit, mit denselben Store-Regeln.

Kann ein Cloud Agent die iOS-App bauen?

Nein. Bauen und Signieren einer iOS-App braucht Xcode auf macOS, und die Agenten arbeiten in Cloud-Entwicklungsumgebungen. Baue mit Xcode auf einem Mac oder mit dem WebViewGold Cloud Builder, der beide Apps im Browser baut und hochlädt.

Kann ich einen Agenten aus einem GitHub-Issue starten?

Ja. Sobald die Versionsverwaltung verbunden ist, kommentierst du @cursor mit deinen Anweisungen in einem Issue oder Pull Request. Ein Issue pro Readiness-Aufgabe gibt dir außerdem eine saubere Dokumentation dessen, was erledigt wurde.

Merged ein Agent von selbst in main?

Cloud Agents arbeiten auf einem separaten Branch und pushen ihn zurück, damit du ihn prüfst. Schütze deinen Default-Branch trotzdem, damit nichts ohne menschliches Review in die Produktion gelangt.

Wie viele Agenten sollte ich gleichzeitig laufen lassen?

So viele, wie du unabhängige Aufgaben hast. Für diesen Pass passen sechs, aber fang mit zwei oder drei an, bis du dem Ergebnis vertraust, und lass die Layout-Arbeit zuletzt laufen.

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.