Cline & Roo Code
Cline ist ein Open-Source-Coding-Agent für VS Code, der mit dem Modell und API-Key deiner Wahl läuft. Roo Code, der bekannte Cline-Fork, wurde am 15. Mai 2026 von seinem Team eingestellt und lebt in Community-Forks weiter. So oder so ist die Aufgabe dieselbe: Bring dem Agenten mit Regeln den WebView-Kontext bei und lass ihn dann Config.swift und Config.java in kleinen, geprüften Schritten ändern, aber niemals das Signing-Setup.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Die WebViewGold-Projekte sind gewöhnliche Xcode- und Android-Studio-Projekte, deren Verhalten in zwei gut lesbaren Dateien festgelegt ist: Config.swift (iOS) und Config.java (Android). Daneben liegen Info.plist, AndroidManifest.xml, strings.xml und, für OneSignal auf Android, die IDs in build.gradle. Eine App zu konfigurieren heißt vor allem, Werte zu ändern: präzise Arbeit mit wenig Risiko, solange sich der Agent an die dokumentierten Optionsnamen in der iOS-Setup-Doku und der Android-Setup-Doku hält.
Cline bringt drei Dinge mit, die hier helfen. Bring your own model: Du verbindest einen Anbieter und Key (Anthropic, OpenAI, Google Gemini, OpenRouter, AWS Bedrock und andere oder ein lokales Modell über Ollama oder LM Studio) und kannst für Plan und Act unterschiedliche Modelle nutzen. Plan- und Act-Modus: Plan erkundet und schlägt vor, ohne Dateien anzufassen, Act führt aus. Checkpoints sind standardmäßig aktiv, du kannst also einen Schritt zurückrollen. Leg Regeln obendrauf, und der Agent weiß, wo die Grenze verläuft. (Wie sich Cline mit Claude Code, Codex und den anderen vergleicht, zeigt die Übersicht der KI-Coding-Agenten.)
Ein Hinweis zum Datenschutz: Bei einem gehosteten Anbieter wird jede Datei, die der Agent öffnet, an diesen Anbieter geschickt. Deine WebViewGold-Konfiguration enthält deinen Purchase Code und Service-IDs, bearbeite diese Werte also selbst oder nutze für die nativen Ordner ein lokales Modell.
Cline liest Workspace-Regeln aus .clinerules/ (oder .cline/rules/), globale Regeln aus ~/Documents/Cline/Rules und außerdem AGENTS.md, .cursorrules und .windsurfrules. Eine paths-Liste im YAML-Frontmatter sorgt dafür, dass eine Regel nur gilt, wenn passende Dateien im Spiel sind (Doku zu Cline-Regeln). Speichere das als .clinerules/webviewgold-config.md.
---
paths:
- "ios/**"
- "android/**"
---
# Editing the WebViewGold projects
## Allowed
- Values in Config.swift and Config.java, using option names that appear in
https://www.webviewgold.com/llms-full.txt. If an option is not documented there,
stop and ask; never invent one.
- Usage description texts in Info.plist; removing descriptions for unused APIs.
- Permission entries in AndroidManifest.xml for APIs switched off in Config.java.
- app_name in strings.xml and the OneSignal IDs in build.gradle.
## How to edit
- Change values only. Keep option names, types, comments and order as they are.
- Booleans stay true/false, strings stay quoted. Never add or delete options.
- One file per step; after each, show the diff and list what it switches on or off.
## Forbidden
- Signing: team IDs, provisioning, certificates, keystore files and passwords,
signingConfigs in build.gradle.
- Bundle ID and package name (I change them in Xcode / Android Studio).
- The purchase code field, dependency versions, Pods/, build/ and .gradle/.
- Deleting the Privacy - Tracking Usage Description key in Info.plist
(WebViewGold requires it; removing it crashes the app).
Mein iOS WebView wurde endlich genehmigt. Danke!!
.clinerules/01-context.md ohne Frontmatter (immer aktiv): die Struktur des Repositorys (web/, ios/, android/), die Produktions-URL und die Tatsache, dass Web-Deploys in den Apps live gehen, native Änderungen aber einen Store-Build brauchen..clinerules/web-app.md mit paths: ["web/**"]: die Store-Regeln für den Web-Code (Safe Areas, Sign in with Apple, Kontolöschung, keine Secrets im Client-Code). Der Guide zu Cursor Rules, das CLAUDE.md-Template und das AGENTS.md-Template haben fertige Texte.AGENTS.md im Root, falls andere Agenten im selben Repository arbeiten. Cline listet sie im Rules-Panel auf, wo sich jede Regel ein- und ausschalten lässt.Etwa eine Stunde, das meiste davon Diffs lesen.
Öffne einen VS-Code-Workspace mit dem Web-Projekt und den entpackten WebViewGold-Ordnern (oder ein Repository mit web/, ios/ und android/). Eine .clineignore hält Build-Ausgaben aus dem automatischen Kontext heraus, ist laut Cline-Doku aber keine Zugriffsgrenze: Halte Keystores und .env-Dateien komplett aus dem Workspace fern.
Ein starkes Modell für den Plan-Modus, in dem der Agent die Doku liest und entscheidet; ein günstigeres oder lokales reicht für den Act-Modus, in dem er ein Dutzend Werte ändert. Kleine lokale Modelle befolgen lange Regeldateien schlecht, halte die native Regel also kurz.
Wechsle in den Plan-Modus und füge den Prompt unten ein. Du bekommst eine Tabelle mit jeder Option, ihrem aktuellen und ihrem neuen Wert, bevor sich auch nur eine Datei ändert.
Gib das Lesen von Dateien ruhig automatisch frei, aber jede Bearbeitung und jeden Terminal-Befehl gibst du selbst frei. Verzichte bei diesem Durchgang auf den YOLO-Modus: Ein einziger falscher Boolean (Cache bei jedem Start gelöscht, Push-Abfrage beim ersten Start) trifft echte Nutzer.
Lass Cline einen Debug-Build im Terminal ausführen (zum Beispiel den Debug-Task des Gradle-Wrappers im Android-Ordner) und nur Fehler beheben, die es selbst verursacht hat. Das iOS-Projekt startest du selbst im Xcode-Simulator.
Bundle-ID, Signierung, Archiv und Upload passieren in Xcode und Android Studio oder im Cloud Builder, wenn du keine der beiden IDEs installieren möchtest.
Ersetze URL und IDs. Die Tabelle, die dabei herauskommt, ist das, was du prüfst.
Lies zuerst die Regeln in .clinerules. Suche dann Config.swift in ios/ und Config.java in android/ (such danach, rate keine Pfade) und lies in https://www.webviewgold.com/llms-full.txt nach, was zu jeder Option steht, die du anfassen willst. Ziel: beide Apps für die Produktion konfigurieren. - URL: https://app.example.com. iOS: host und webviewurl. Android: HOST und HOME_URL. - User-Agent: der Standard-Mobile-User-Agent der Plattform, gefolgt von einem Leerzeichen und dem Token WebViewGoldApp. iOS: useragent_iphone und useragent_ipad. Android: USER_AGENT. - Push mit OneSignal, App ID [einfügen]. iOS: kPushEnabled true, oneSignalID und askforpushpermissionatfirstrun false, weil die Web-App registerpush:// nach dem Onboarding aufruft. Android: PUSH_ENABLED true und die OneSignal-ID dort, wo die Dokumentation es vorsieht (build.gradle). - Automatisch injizierte JavaScript-Variablen an: autoInjectVariable (iOS), AUTO_INJECT_VARIABLES (Android). - Berechtigungen: Die App nutzt die Kamera, aber weder Standort noch Mikrofon. iOS: Entferne die ungenutzten Usage Descriptions in Info.plist, behalte aber den Schlüssel Privacy - Tracking Usage Description. Android: requireLocation und requireRecordAudio auf false, und entferne die passenden Einträge in AndroidManifest.xml. Gib im Plan-Modus eine Tabelle aus: Datei, Option, aktueller Wert, neuer Wert und die Zeile in der Dokumentation, die die Änderung begründet. Markiere jede Option, die du in der Dokumentation nicht finden konntest, statt sie zu erfinden. Plane keine Änderungen an Signierung, Provisioning, Keystores, signingConfigs, dem Purchase Code, Abhängigkeitsversionen oder Bundle Identifiern. Wenn ich in den Act-Modus wechsle, ändere eine Datei nach der anderen und zeige nach jeder das Diff.
| Datei | Der Agent darf bearbeiten | Behältst du selbst |
|---|---|---|
| Config.swift | host, webviewurl, User-Agent, Push-Schalter, autoInjectVariable, openallexternalurlsinsafaribydefault | Den Wert purchasecode (füge ihn selbst ein) |
| Config.java | HOST, HOME_URL, USER_AGENT, PUSH_ENABLED, AUTO_INJECT_VARIABLES, die Berechtigungs-Flags require... | PURCHASECODE |
| Info.plist | Usage-Description-Texte; ungenutzte löschen | Der Schlüssel Privacy - Tracking Usage Description muss bleiben |
| AndroidManifest.xml | Berechtigungen für abgeschaltete APIs entfernen | Intent-Filter für App Links, außer die Aufgabe ist Deep Linking |
| build.gradle | OneSignal-IDs | signingConfigs, Plugin- und Abhängigkeitsversionen |
| Projekteinstellungen in Xcode / Android Studio | Nichts | Team, Zertifikate, Keystore, Bundle-ID, Package-Name (einmal festlegen) |
deletecache oder CLEAR_CACHE_ON_STARTUP auf true meldet Nutzer bei jedem Start ab; uselocalhtmlfolder auf true lädt die mitgelieferte Beispielseite statt deiner URL.navigator.userAgent ausgibt, zeigt in beiden Apps das Token WebViewGoldApp.registerpush:// aufgerufen hat.Sein Team hat das Repository am 15. Mai 2026 archiviert und die Erweiterung eingestellt, rechne also nicht mit Fixes oder Updates für neue Anbieter. Das README verweist auf den Community-Fork ZooCode und auf Cline. Deine Regeldateien sind reines Markdown und lassen sich leicht übernehmen.
Jedes fähige Coding-Modell funktioniert, denn die Aufgabe ist präzise statt kreativ. Nimm im Plan-Modus ein starkes Modell, das die Dokumentation liest, und im Act-Modus gern ein günstigeres oder lokales Modell. Am wichtigsten ist eine kurze, strenge Regeldatei.
Ja. Cline liest AGENTS.md aus dem Workspace und aus ~/.agents/AGENTS.md und erkennt außerdem .cursorrules und .windsurfrules. Alle erscheinen im Rules-Panel, wo du jede einzeln umschalten kannst.
Es kann mit deiner Freigabe Builds über die Kommandozeile ausführen. Signieren, Archivieren und Hochladen zu App Store Connect und in die Play Console bleiben bei dir in den IDEs oder beim Cloud Builder.
Bei einem gehosteten Anbieter ja: Was der Agent liest, geht zu diesem Anbieter, zu dessen Bedingungen. Mit einem lokalen Modell über Ollama oder LM Studio bleibt es auf deinem Rechner. Entscheide pro Ordner, wenn die native Konfiguration Werte enthält, die du nicht teilen willst.
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.