Claude Code
Un sous-agent est un fichier Markdown placé dans .claude/agents/, avec ses propres instructions, sa propre liste d'outils et sa propre fenêtre de contexte. Donnez-lui les règles des stores qui font chuter les apps basées sur le web, et il passe en revue votre web app et les deux projets WebViewGold comme un collègue intransigeant de l'App Review, avant qu'Apple ou Google ne le fassent. Vous trouverez ci-dessous le fichier d'agent complet, la façon de le lancer et ce qu'il faut faire de son rapport.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Vous pourriez coller une checklist de review dans votre session Claude Code principale. Cela marche une fois, puis trois problèmes apparaissent. La review lit des dizaines de fichiers (routes, authentification, tarifs, Info.plist, AndroidManifest.xml) et remplit le contexte dont vous avez besoin pour la correction elle-même. La session qui a écrit le code est aussi celle qui le note, si bien qu'elle a tendance à justifier ses propres choix au lieu de les signaler. Et la checklist vit dans votre presse-papiers, pas dans le dépôt.
Un sous-agent règle ces trois problèmes. Claude Code le démarre avec une fenêtre de contexte vierge, ne lui transmet que la tâche et ne récupère que le rapport. Sa ligne tools peut exclure Edit et Write, pour que le reviewer ne puisse pas « corriger » discrètement des choses pendant sa relecture. Et comme le fichier se trouve dans .claude/agents/, toute personne qui clone le dépôt, y compris une session cloud ou un job de CI, obtient le même reviewer avec les mêmes règles.
Gardez une répartition des rôles nette : votre CLAUDE.md indique chaque jour à Claude comment écrire du code compatible avec les stores ; le sous-agent juge une release candidate à la demande.
Enregistrez-le sous .claude/agents/store-review-checker.md. Les chemins native/ios et native/android supposent que les projets WebViewGold se trouvent à côté de votre web app ; adaptez-les à votre arborescence. Tout ce qui suit la deuxième ligne --- devient le prompt système du sous-agent.
---
name: store-review-checker
description: Strict pre-submission reviewer for the Apple App Store and Google Play. Reviews this web app and its WebViewGold iOS and Android projects against the store rules that reject web-based apps and returns a prioritized report. Use proactively before every store submission, after changes to login, payments, account settings, legal pages or native config, and whenever the user asks whether the app will pass review. Read-only, it reports and never edits.
tools: Read, Grep, Glob, Bash, WebFetch
model: inherit
color: orange
---
You are a senior App Store and Google Play reviewer. You review a web app that is
published as native iOS and Android apps with WebViewGold, a native shell that loads
the production URL of this web app in a WKWebView (iOS) or Android WebView.
Your job: find what would get the next submission rejected, before Apple or Google do.
## Ground rules
- You are read-only. Never create, edit or delete files. Use Bash only for read-only
commands such as git log, git diff, git show, git tag and ls. Never install, build,
deploy, commit or push.
- Every finding needs evidence: a file path and line, a route, or a file that is missing.
If you cannot verify something from the repository, put it under "Needs a human check"
instead of guessing.
- Do not invent WebViewGold settings or URL schemes. The sources of truth are the pages
under https://www.webviewgold.com/docs/ and https://www.webviewgold.com/llms-full.txt.
- Store rules change. When a finding depends on the exact current wording of a guideline
(external purchase links, target API level, account deletion details), name the
guideline to re-check instead of presenting the rule as permanent.
## Where to look
1. CLAUDE.md and docs/store-review.md first: app facts, demo account notes, review history.
2. Web app: routes, auth flows, settings, pricing and checkout, legal pages, error and
empty states, and everything gated by isNativeApp() or the WebViewGold user agent token.
3. iOS project in native/ios: Config.swift (host, webviewurl, useragent_iphone,
useragent_ipad, feature switches), Info.plist (usage descriptions, display name),
entitlements.
4. Android project in native/android: Config.java (HOST, HOME_URL, USER_AGENT, require*
flags), AndroidManifest.xml (permissions, intent filters), app/build.gradle
(applicationId, targetSdk, versionCode, versionName).
5. If a release tag exists, review git diff <last-release-tag>..HEAD with extra care.
## What to check
Apple App Store
- 4.2 Minimum functionality: the app offers more than the website in a browser tab.
Push, offline handling, the share sheet, biometrics or similar are actually wired in.
A marketing site or a list of links as the main experience is a blocker.
- 2.1 App completeness: no placeholder text, lorem ipsum, "coming soon", dead buttons,
404 links or test data. Everything behind a login is reachable with a demo account.
- 2.3 Accurate metadata: in-app wording matches the app name; no "Get it on Google Play"
or other platform references inside the iOS app.
- 3.1.1 and 3.1.2 Payments: digital goods and subscriptions used in the app go through
in-app purchase in the native app. Flag every web checkout, price and external payment
link visible inside the app. US storefront rules for external purchase links have
changed since 2025: mark those findings "decide with the current guideline text".
- 4.8 Login services: if Google, Facebook or another third-party login exists, an
equivalent privacy-focused option such as Sign in with Apple is offered.
- 5.1.1 Privacy: a privacy policy route that describes real data practices; account
deletion inside the app (not only by email) when users can create accounts; every
usage description in Info.plist belongs to a feature that is used and states a
specific purpose.
- 5.1.2 Tracking: ads or cross-app tracking only after the App Tracking Transparency prompt.
- 1.2 User-generated content (posts, chat, shared AI output): report, block, filtering
and a published contact.
- 4.0 Design: safe-area padding on fixed bars, tap targets of at least 44 pt, no
horizontal scrolling at 320 px width, no hover-only controls.
Google Play
- Minimum functionality and webview spam: the same substance test as Apple 4.2.
- User Data policy and Data safety: list every SDK and endpoint that receives user data
and compare it with the privacy policy; mismatches with the Data safety form are blockers.
- Account deletion: an in-app path plus a public web URL for deletion requests.
- Permissions: every permission in AndroidManifest.xml is used; unused require* flags
in Config.java are false.
- Target API level: report targetSdk and tell the user to compare it with Google's
current requirement.
- Impersonation and intellectual property: no brand names, logos or screenshots the
developer does not own.
- Families: if children could be part of the audience, flag it as a human decision.
WebViewGold configuration
- Config.swift and Config.java point to the production domain over HTTPS, never to
localhost, a LAN address, 10.0.2.2, a tunnel or a preview deployment.
- The user agent token the web app checks for is set in useragent_iphone,
useragent_ipad and USER_AGENT.
- askforpushpermissionatfirstrun is false if the web app asks later with registerpush://.
- deletecache (iOS) and CLEAR_CACHE_ON_STARTUP (Android) are false unless the user
wants a logout on every launch.
## Report format
Return exactly these four parts and nothing else.
### Verdict
One sentence: "Ready to submit", "Ready after fixing N blockers" or "Not ready".
### Findings
| # | Severity | Store | Guideline | Evidence | Fix | Where to fix |
Severity: Blocker (likely rejection), Risk (rejection possible), Polish.
Where to fix: web app, WebViewGold config, store console, or human decision.
Sort by severity, merge duplicates, at most 15 rows.
### Needs a human check
What you could not verify from the repository: device behavior, App Store Connect
metadata, screenshots, Data safety answers.
### Review notes draft
Three to six sentences for App Review: what the app does, which native features to try,
where the demo account is provided. Never include passwords.Le name sert à l'appeler (@agent-store-review-checker). La description est ce que Claude lit quand il décide de déléguer de lui-même ; elle énumère donc les situations déclencheuses : avant une soumission, après des modifications de la connexion, des paiements ou de la config native, et la question « est-ce que ça passera la validation ? ».
Read, Grep et Glob pour inspecter les fichiers, Bash pour des commandes git en lecture seule, WebFetch pour consulter le texte actuel des guidelines ou la documentation WebViewGold. Ni Edit ni Write : le reviewer rapporte, c'est vous qui décidez de ce qui change.
inherit reprend le modèle de votre session. Indiquez opus pour une passe plus lente et plus approfondie sur une grosse base de code, ou sonnet pour des vérifications rapides. color change seulement l'apparence de l'agent dans le terminal.
Pas de preuve, pas de constat : chaque constat exige un fichier et une ligne, sinon il atterrit sous « Needs a human check ». Cette seule règle élimine la plupart des avertissements vagues qui rendent les reviews automatisées inutiles.
Regroupées par store et rattachées chacune à une guideline ou à une règle nommée, pour que chaque constat reste traçable. Le bloc WebViewGold repère les erreurs de configuration qui n'apparaîtraient jamais dans une review de la seule web app.
Un tableau fixe avec la gravité et la colonne « Where to fix » (web app, config WebViewGold, console du store, décision humaine). Une sortie fixe rend les passages comparables et faciles à coller dans une session de correction.
Excellente façon de convertir son app web en app native ! Un délai très court, et un super moyen de mettre ses apps dans les stores sans devoir développer une app native complète !
Certaines choses ne figurent pas dans le dépôt : ce que vous vendez, les fonctionnalités que vous avez activées dans les projets natifs, la façon dont le reviewer se connecte, ce qu'Apple a dit la dernière fois. Mettez-les dans un court fichier que l'agent lit en premier. N'y mettez aucun vrai mot de passe : leur place est dans la section App Review d'App Store Connect et dans le formulaire App access de la Play Console.
# Store review facts (read first by the store-review-checker subagent)
## App
- Store name: Example App
- iOS bundle ID: com.example.app / Android applicationId: com.example.app
- Production URL loaded by both apps: https://app.example.com
- User agent token checked by the web app: WebViewGoldApp
## Native features switched on in WebViewGold
- iOS: OneSignal push (kPushEnabled), QR scanner, Face ID via bioauth://
- Android: OneSignal push (PUSH_ENABLED), QR scanner, biometrics via bioauth://
- Not used: location, microphone, contacts, AdMob
## Money
- Pro subscription. Web: Stripe checkout. Native apps: in-app purchase via RevenueCat only.
## Accounts
- Email sign-up and Google login; Sign in with Apple offered on iOS.
- Reviewer demo account: credentials are entered in App Store Connect (App Review
Information) and in the Play Console (App access). Role: regular user with sample data.
## Review history
- 1.0 rejected under Guideline 4.2 (no native features). 1.1 added push and QR check-in.
- 1.2 approved on both stores.Une dizaine de minutes, passées surtout à lire le premier rapport.
Lancez mkdir -p .claude/agents à la racine du dépôt, enregistrez le fichier ci-dessus sous .claude/agents/store-review-checker.md et commitez-le. Claude Code surveille le dossier et prend en compte les modifications ultérieures en quelques secondes ; la session n'a besoin d'un redémarrage que si le dossier agents vient d'être créé.
Enregistrez docs/store-review.md avec les vrais faits de votre app et l'historique de vos validations. Mettez-le à jour après chaque résultat, accepté ou refusé ; c'est la section d'historique qui empêche la même erreur de se reproduire.
Collez le prompt ci-dessous, ou appelez directement l'agent avec @agent-store-review-checker vérifie la release candidate. Claude Code délègue aussi de lui-même quand vous demandez par exemple « est-ce que ça passera l'App Review ? », parce que la description le prévoit.
Commencez par la ligne de verdict, puis les lignes Blocker. Chaque ligne indique où se fait la correction. Les corrections de la web app retournent dans votre session principale, celles de la config WebViewGold sont de petites modifications dans Config.swift ou Config.java, et les points liés aux consoles deviennent votre liste de tâches pour App Store Connect et la Play Console.
Demandez à la session principale de corriger les blockers un par un, avec un commit pour chacun, puis relancez le sous-agent. Un second passage propre sur le même commit est votre signal pour lancer le build.
Le sous-agent lit du code. Lancez la vérification de conformité App Store gratuite et la vérification de conformité Play Store sur votre URL de production pour repérer ce que seul le site déployé révèle, puis testez le build sur un vrai téléphone.
Remplacez la version, le tag et les noms de fichiers par les vôtres. Le dernier paragraphe empêche la session principale de se lancer dans des modifications avant que vous ayez lu le rapport.
Utilisez le sous-agent store-review-checker pour passer en revue ce projet avant que nous soumettions la version 1.3 à l'App Store et à Google Play. Périmètre : toute la web app, plus native/ios et native/android. La dernière version acceptée porte le tag v1.2.0 ; accordez donc une attention particulière aux commits postérieurs à ce tag. Les faits sur l'app, les notes sur le compte de démo et notre historique de validation se trouvent dans docs/store-review.md. Quand le sous-agent a terminé, montrez-moi son rapport exactement tel qu'il l'a rédigé. Proposez ensuite un plan de correction pour les lignes Blocker uniquement, regroupé en : modifications de la web app, modifications de la config WebViewGold, tâches dans les consoles des stores. Ne modifiez aucun fichier avant que j'aie confirmé le plan.
ios/ et non dans native/ios, modifiez le fichier, sinon l'agent signalera les vérifications natives comme « introuvables »./privacy, /terms et /delete-account se chargent sur le domaine de production, pas seulement en développement.Les sous-agents de projet se trouvent dans .claude/agents/ à l'intérieur du dépôt et sont partagés via Git. Les sous-agents personnels, qui doivent fonctionner dans tous vos projets, vont dans ~/.claude/agents/. Chaque fichier est écrit en Markdown avec un frontmatter YAML ; name et description sont obligatoires, tout le reste est facultatif.
C'est possible. Claude décide à partir du champ description ; c'est pourquoi l'exemple énumère des situations déclencheuses concrètes et précise « use proactively ». Si vous voulez en être certain, nommez le sous-agent dans votre prompt ou mentionnez-le avec @.
inherit est un bon choix par défaut. Passez la ligne model à opus pour une passe plus lente et plus minutieuse avant une version majeure, ou à sonnet si vous le lancez souvent sur de petites modifications.
Pas directement, car il ne voit que le dépôt. Copiez la description, les mots-clés et les réponses App Privacy et Data safety dans un fichier comme docs/store-listing.md, et l'agent les comparera avec ce que le code collecte réellement.
Non. Il élimine les problèmes prévisibles, mais les reviewers testent l'app en fonctionnement et les règles changent. WebViewGold ajoute un filet de sécurité pour le reste : si Apple ou Google refusent l'app pour des raisons sans rapport avec votre contenu, vous pouvez demander le remboursement de la licence dans les 14 jours suivant l'achat.
Oui. Les sessions cloud et la GitHub Action de Claude Code travaillent dans un checkout de votre dépôt : le fichier d'agent commité y est donc disponible aussi. Le guide GitHub Actions montre un workflow qui lance une review de conformité aux stores sur chaque pull request.
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.