Cline & Roo Code
Cline est un agent de code open source pour VS Code qui fonctionne avec le modèle et la clé API de votre choix. Roo Code, le fork bien connu de Cline, a été arrêté par son équipe le 15 mai 2026 et survit dans des forks communautaires. Dans tous les cas, le travail est le même : apprenez à l'agent le contexte WebView avec des règles, puis laissez-le modifier Config.swift et Config.java par petites étapes relues, jamais la configuration de signature.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Les projets WebViewGold sont des projets Xcode et Android Studio ordinaires dont le comportement est défini dans deux fichiers lisibles : Config.swift (iOS) et Config.java (Android). À côté se trouvent Info.plist, AndroidManifest.xml, strings.xml et, pour OneSignal sur Android, les ID dans build.gradle. Configurer une app consiste surtout à changer des valeurs : un travail précis et peu risqué, à condition que l'agent s'en tienne aux noms d'options documentés dans la documentation de configuration iOS et la documentation de configuration Android.
Cline apporte trois choses utiles ici. Votre propre modèle : vous connectez un fournisseur et une clé (Anthropic, OpenAI, Google Gemini, OpenRouter, AWS Bedrock et d'autres, ou un modèle local via Ollama ou LM Studio), et vous pouvez utiliser des modèles différents pour Plan et Act. Les modes Plan et Act : Plan explore et propose sans toucher aux fichiers, Act exécute. Les checkpoints sont activés par défaut, ce qui vous permet d'annuler une étape. Ajoutez des règles par-dessus, et l'agent sait où se trouve la limite. (Pour comparer Cline avec Claude Code, Codex et les autres, consultez la vue d'ensemble des agents de code IA.)
Une remarque sur la confidentialité : avec un fournisseur hébergé, chaque fichier que l'agent ouvre est envoyé à ce fournisseur. Votre configuration WebViewGold contient votre code d'achat et vos ID de services : gardez-les pour une modification manuelle, ou utilisez un modèle local pour les dossiers natifs.
Cline lit les règles du workspace dans .clinerules/ (ou .cline/rules/), les règles globales dans ~/Documents/Cline/Rules, ainsi que AGENTS.md, .cursorrules et .windsurfrules. Une liste paths dans le frontmatter YAML fait qu'une règle ne s'applique que lorsque des fichiers correspondants sont en jeu (documentation des règles Cline). Enregistrez ceci sous .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).
Mon WebView iOS est enfin approuvé. Merci !!
.clinerules/01-context.md sans frontmatter (toujours actif) : l'organisation du dépôt (web/, ios/, android/), l'URL de production et le fait que les déploiements web sont en ligne dans les apps, alors que les modifications natives exigent un build pour les stores..clinerules/web-app.md avec paths: ["web/**"] : les règles des stores pour le code web (safe areas, Sign in with Apple, suppression de compte, aucun secret dans le code client). Le guide des règles Cursor, le modèle CLAUDE.md et le modèle AGENTS.md contiennent des textes prêts à l'emploi.AGENTS.md à la racine si d'autres agents travaillent dans le même dépôt. Cline le liste dans le panneau Rules, où chaque règle peut être activée ou désactivée.Environ une heure, passée surtout à lire des diffs.
Ouvrez un seul workspace VS Code avec le projet web et les dossiers WebViewGold décompressés (ou un seul dépôt avec web/, ios/ et android/). Un fichier .clineignore garde les résultats de build hors du contexte automatique, mais d'après la documentation de Cline, ce n'est pas une frontière d'accès : gardez les keystores et les fichiers .env complètement hors du workspace.
Un modèle puissant pour le mode Plan, où l'agent lit la documentation et décide ; un modèle moins cher ou local suffit pour le mode Act, où il change une douzaine de valeurs. Les petits modèles locaux suivent mal les longs fichiers de règles : gardez donc la règle native courte.
Passez en mode Plan et collez le prompt ci-dessous. Vous obtenez un tableau de chaque option, avec sa valeur actuelle et la nouvelle, avant qu'un seul fichier ne change.
Approuvez automatiquement les lectures de fichiers si vous le souhaitez, mais validez vous-même chaque modification et chaque commande du terminal. Évitez le mode YOLO pour cette passe : un seul booléen erroné (cache vidé à chaque démarrage, demande push au premier lancement) coûte de vrais utilisateurs.
Laissez Cline lancer un build de debug depuis le terminal (par exemple la tâche debug du wrapper Gradle dans le dossier Android) et ne corriger que les erreurs qu'il a introduites. Lancez vous-même le projet iOS dans le simulateur Xcode.
Le bundle ID, la signature, l'archivage et l'envoi se font dans Xcode et Android Studio, ou dans le Cloud Builder si vous ne voulez installer aucun des deux IDE.
Remplacez l'URL et les ID. Le tableau qu'il produit est ce que vous devez relire.
Lisez d'abord les règles de .clinerules. Localisez ensuite Config.swift dans ios/ et Config.java dans android/ (cherchez-les, ne devinez pas les chemins), et lisez https://www.webviewgold.com/llms-full.txt pour chaque option que vous allez toucher. Objectif : configurer les deux apps pour la production. - URL : https://app.example.com. iOS : host et webviewurl. Android : HOST et HOME_URL. - User agent : le user agent mobile par défaut de la plateforme, suivi d'un espace et du jeton WebViewGoldApp. iOS : useragent_iphone et useragent_ipad. Android : USER_AGENT. - Push avec OneSignal, App ID [à coller]. iOS : kPushEnabled sur true, oneSignalID, et askforpushpermissionatfirstrun sur false, car la web app appelle registerpush:// après l'onboarding. Android : PUSH_ENABLED sur true et l'ID OneSignal à l'endroit indiqué par la documentation (build.gradle). - Variables JavaScript injectées automatiquement, activées : autoInjectVariable (iOS), AUTO_INJECT_VARIABLES (Android). - Autorisations : l'app utilise la caméra ; elle n'utilise ni la localisation ni le micro. iOS : supprimez les descriptions d'utilisation inutilisées dans Info.plist, mais gardez la clé Privacy - Tracking Usage Description. Android : requireLocation et requireRecordAudio sur false, et supprimez les entrées correspondantes dans AndroidManifest.xml. En mode Plan, produisez un tableau : fichier, option, valeur actuelle, nouvelle valeur, et la ligne de documentation qui la justifie. Signalez chaque option que vous n'avez pas trouvée dans la documentation au lieu de l'inventer. Ne planifiez aucune modification de la signature, du provisioning, des keystores, des signingConfigs, du code d'achat, des versions de dépendances ou des identifiants de bundle. Quand je passerai en mode Act, appliquez les changements un fichier à la fois et montrez le diff après chacun.
| Fichier | L'agent peut modifier | Gardez pour vous |
|---|---|---|
| Config.swift | host, webviewurl, user agent, interrupteurs push, autoInjectVariable, openallexternalurlsinsafaribydefault | La valeur purchasecode (collez-la vous-même) |
| Config.java | HOST, HOME_URL, USER_AGENT, PUSH_ENABLED, AUTO_INJECT_VARIABLES, les indicateurs d'autorisation require... | PURCHASECODE |
| Info.plist | Textes des descriptions d'utilisation ; suppression de celles qui ne servent pas | La clé Privacy - Tracking Usage Description doit rester |
| AndroidManifest.xml | Supprimer les autorisations des API que vous avez désactivées | Les intent filters des App Links, sauf si la tâche porte sur les deep links |
| build.gradle | ID OneSignal | signingConfigs, versions des plugins et des dépendances |
| Réglages des projets Xcode / Android Studio | Rien | Team, certificats, keystore, bundle ID, nom de package (à choisir une seule fois) |
deletecache ou CLEAR_CACHE_ON_STARTUP réglé sur true déconnecte les utilisateurs à chaque lancement ; uselocalhtmlfolder sur true charge la page d'exemple embarquée au lieu de votre URL.navigator.userAgent montre le jeton WebViewGoldApp dans les deux apps.registerpush://.Son équipe a archivé le dépôt et arrêté l'extension le 15 mai 2026 : ne comptez donc plus sur des correctifs ni sur des mises à jour des fournisseurs. Le README oriente vers le fork communautaire ZooCode et vers Cline. Vos fichiers de règles sont du Markdown simple et se transfèrent facilement.
N'importe quel modèle de code compétent fait l'affaire, car la tâche demande de la précision plutôt que de la créativité. Utilisez un modèle puissant en mode Plan pour lire la documentation et, si vous voulez, un modèle moins cher ou local en mode Act. Le plus important est un fichier de règles court et strict.
Oui. Cline lit AGENTS.md dans le workspace et dans ~/.agents/AGENTS.md, et il détecte aussi .cursorrules et .windsurfrules. Tous apparaissent dans le panneau Rules, où vous pouvez activer ou désactiver chacun d'eux.
Il peut lancer des builds en ligne de commande avec votre accord. La signature, l'archivage et l'envoi sur App Store Connect et la Play Console restent entre vos mains, dans les IDE, ou passent par le Cloud Builder.
Avec un fournisseur hébergé, oui : tout ce que l'agent lit part chez ce fournisseur, selon ses conditions. Avec un modèle local via Ollama ou LM Studio, cela reste sur votre machine. Décidez dossier par dossier si la configuration native contient des valeurs que vous ne voulez pas partager.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.