Claude Code
Gib ihm die URL im Prompt; es ruft Webseiten auf Anfrage ab. Leg die URL und eine einzeilige Notiz in der CLAUDE.md ab, damit jede Session weiß, wo die Referenz liegt (Guide zur Bridge mit Claude Code).
Die drei Dateien
| Datei | Was sie enthält | Wofür du sie nutzt |
|---|---|---|
| llms.txt | Ein kurzer Index: Produktzusammenfassung, kanonische URLs der iOS-, Android- und macOS-Docs, des Cloud Builders, der Vibe-Coding-Guides und der Readiness-Checks, dazu Nutzungshinweise für Agenten. | Orientierung und eine schnelle Antwort auf "Was macht WebViewGold?"; klein genug, um sie in jeden Prompt einzufügen. |
| llms-full.txt | Die komplette Dokumentation als reiner Text in einer Datei: jede Seite zu iOS, Android und macOS, jede Option in Config.swift und Config.java, jedes URL-Schema und jede injizierte Variable, mit Überschriften wie "Biometric Authentication API (iOS)". | Implementierung. Der Agent liest den Abschnitt zum Feature und übernimmt die exakten Namen von Schema, Parametern und Variablen. |
| webmcp.json | Ein Discovery-Manifest: Name, Beschreibung, Links zu llms.txt und zur Sitemap, eine Liste von GET-"Tools" (Produktüberblick, Docs-Hub, Sitemap, Vibe-Coding-Guides) und Hinweise für Crawler. | Research-Agenten und Crawler, die wissen müssen, wo die kanonischen Seiten liegen, bevor sie sie lesen. |
Warum Agenten Bridge-Aufrufe halluzinieren
Die WebViewGold-Bridge ist ungewöhnlich: Du löst native Features aus, indem du zu einem URL-Schema navigierst (window.location.href = "bioauth://"), und Ergebnisse kommen als injizierte globale Variablen oder Callback-Funktionen zurück. Die meisten Trainingsdaten beschreiben Bridges mit Message Handlern, also schreibt ein Agent, der die Docs nicht gelesen hat, window.webkit.messageHandlers.share.postMessage(...) oder WebViewGold.share(), und beides bewirkt nichts. Auch die Namen zählen: Das Share Sheet heißt shareapp://message?=TEXT&url=URL, nicht share://; das Scanner-Ergebnis heißt barcodescanresult, nicht scanResult.
Gibst du dem Agenten die llms-full.txt, entfällt das Raten. Die Datei ist reiner Text, also kann jeder Agent sie mit seinem Fetch-Tool lesen, und du kannst seine Ausgabe mit grep prüfen.
Wie jeder Agent die Docs liest
OpenAI Codex
Die CLI und die IDE-Erweiterung können die Datei per Shell-Befehl herunterladen, wenn Netzwerkzugriff erlaubt ist; Cloud-Aufgaben laufen in einer Sandbox, deren Internetzugang du steuerst. Am sichersten ist deshalb eine committete Kopie unter docs/vendor/, auf die die AGENTS.md verweist.
Cursor
Füge die URL einmal als Docs-Quelle hinzu (@Docs); danach kann der Agent darin suchen. @Web funktioniert für einzelne Fragen. Erwähne die Datei in .cursor/rules, damit der Agent-Modus sie liest, bevor er irgendein Schema verwendet.
Windsurf
Füge die URL oder den relevanten Abschnitt in die Unterhaltung ein, oder committe eine lokale Kopie und verweise aus der Rules-Datei des Workspaces darauf. Bitte den Agenten (Devin Local, früher Cascade), den Abschnitt zu zitieren, auf den er sich gestützt hat.
Gemini CLI und Google AI Studio
Gemini CLI ruft URLs auf Anfrage ab und liest eine Kontextdatei GEMINI.md; AI-Studio-Apps kannst du den Abschnitt als Kontext mitgeben. Dieselbe Regel: erst zitieren, dann coden.
Mein iOS WebView wurde endlich genehmigt. Danke!!
Ein Workflow, der mit jedem Agenten funktioniert
Die Dokumentation ins Repository übernehmen
Lade llms-full.txt nach
docs/vendor/webviewgold-llms-full.txtherunter und committe sie mit dem Datum in der Commit-Nachricht. Eine lokale Datei ist schneller, deterministisch und auch in Sandboxes ohne Netzwerkzugriff verfügbar. Aktualisiere sie, wenn du WebViewGold aktualisierst.Die Anweisungsdatei darauf verweisen lassen
Eine Zeile in AGENTS.md, CLAUDE.md, .cursor/rules oder dem jeweiligen Gegenstück: "Bevor du ein WebViewGold-Feature nutzt, lies den passenden Abschnitt in docs/vendor/webviewgold-llms-full.txt und zitiere das Schema."
Mit Zitierpflicht prompten
Nutze den Prompt unten. Wenn der Agent den Abschnitt zuerst zitieren muss, entstehen korrekte Schema-Namen, und ein falscher Tipp wird sichtbar, bevor er zu Code wird.
Mit grep prüfen
Führe die Prüfung aus dem Codeblock unten aus: Jedes Schema, das der Agent verwendet hat, muss in der Dokumentation vorkommen. Unbekannte Schemas sind Halluzinationen.
Auf einem Geräte-Build testen
Schemas tun in einem Desktop-Browser nichts. Baue mit Xcode, Android Studio oder dem Cloud Builder und teste auf einem Handy; mit TestFlight und internen Test-Tracks geht das schnell.
Ein Prompt, der auf die Docs verweist
In Claude Code, Codex, Cursor, Windsurf oder Gemini CLI einfügen
Bevor du Code schreibst, lies https://www.webviewgold.com/llms-full.txt (oder docs/vendor/webviewgold-llms-full.txt, falls vorhanden) und finde den Abschnitt zu [FEATURE, z. B. Biometric Authentication API]. Zitiere das exakte URL-Schema, die Parameter und die Namen der Callbacks oder Variablen aus diesem Abschnitt. Implementiere dann [FEATURE] in [DATEI ODER ROUTE], abgesichert durch isNativeApp() (User-Agent-Marker MYAPPNATIVE), mit Web-Fallback. Von der App injizierte Variablen kommen asynchron an, also polle mit Timeout. Deckt die Dokumentation etwas nicht ab, das du brauchst, sag das, statt zu raten. Schließe mit den Überschriften der Dokumentation, auf die du dich gestützt hast, und mit dem, was ich auf einem Gerät testen muss.
Agenten-Ausgabe gegen die Docs prüfen
Führe das im Repository aus, wenn der Agent fertig ist. Es listet jedes eigene Schema in deinem Quellcode auf und prüft es gegen die Dokumentation.
bash
# Fetch the full documentation once (or use the committed copy)
curl -sL https://www.webviewgold.com/llms-full.txt -o /tmp/wvg-docs.txt
# Every "something://" the agent used in src must exist in the docs
grep -rhoE "[a-zA-Z-]+://" src | sort -u | while read scheme; do
if grep -qF "$scheme" /tmp/wvg-docs.txt; then
echo "ok $scheme"
else
echo "UNKNOWN $scheme <- not in the WebViewGold docs"
fi
done
# Read the section for one feature before you test on a device
grep -n -A 40 "Biometric Authentication API (Face ID / Touch ID) (iOS)" /tmp/wvg-docs.txtFehler, die wir in Agenten-Ausgaben sehen
- Erfundene Bridges:
window.WebViewGold,postMessage-Handler, Capacitor- oder Cordova-Plugins. Die Bridge ist URL-Navigation. - Injizierte Variablen gleich in der nächsten Zeile synchron lesen. Sie kommen erst nach der Navigation an; polle ein paar hundert Millisekunden lang.
- Schemas im Browser aufrufen. Sichere mit dem User-Agent-Marker ab; ein Schema in Safari oder Chrome ist ein kaputter Link.
- Die Web Share API oder ein PWA-Push-Setup statt des nativen Share Sheets und der WebViewGold-Push-Integration verwenden.
- Plattformspezifische Features als universell behandeln:
settingsapp://undreconnect://sind für Android dokumentiert, die Biometrie-Callbacks für iOS. Die Datei sagt, welche Plattform jeder Abschnitt abdeckt. - RevenueCat-Produkt-IDs an mehreren Stellen hart codieren statt in einer Config-Map, und Entitlements auf dem Client vergeben statt über den Webhook.
Häufig gestellte Fragen
Gibt es einen WebViewGold-MCP-Server, den ich verbinden kann?
webmcp.json ist ein Discovery-Manifest, das öffentliche GET-Ressourcen auflistet; dabei werden keine Tools ausgeführt. Agenten, die das Format verstehen, finden damit die kanonischen Seiten und lesen dann llms.txt und llms-full.txt.
Welche Datei nehme ich für eine schnelle Frage?
llms.txt. Sie ist ein paar Kilobyte groß und beantwortet, was WebViewGold ist und wo die Docs liegen. Nimm llms-full.txt, wenn der Agent Code schreiben muss.
Wie oft ändert sich llms-full.txt?
Mit jedem Update der Dokumentation. Hast du eine Kopie committet, aktualisiere sie, wenn du das WebViewGold-Projekt aktualisierst; die grep-Prüfung oben markiert Schemas, die verschoben oder umbenannt wurden.
Kann der Agent anhand der Docs auch Config.swift und Config.java konfigurieren?
Ja. Die Datei dokumentiert jede Option mit Namen und erlaubten Werten, ein Agent mit geöffnetem WebViewGold-Projekt kann also URL, Host, Push-Optionen und Feature-Schalter setzen. Signierung und Uploads bleiben manuell oder laufen über den Cloud Builder.
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 ansehenCloud Builder
$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 ausprobierenFull 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
Winter-Sale-Preise gültig bis 31. Dezember 2026.