Claude Code
A subagent is a Markdown file in .claude/agents/ with its own instructions, its own tool list and its own context window. Give it the store rules that sink web-based apps and it reviews your web app and both WebViewGold projects like a strict App Review colleague, before Apple or Google do. Below is the complete agent file, how to run it and how to act on its report.
From $109 one-time per platform, or let our team do it all from $698.
You could paste a review checklist into your main Claude Code session. It works once, and then three problems show up. The review reads dozens of files (routes, auth, pricing, Info.plist, AndroidManifest.xml) and fills the context you need for the actual fix. The session that wrote the code is also the one grading it, so it tends to explain its own choices instead of flagging them. And the checklist lives in your clipboard, not in the repository.
A subagent solves all three. Claude Code starts it with a fresh context window, hands it only the task and gets back only the report. Its tools line can leave out Edit and Write, so the reviewer cannot quietly "fix" things while it reviews. And because the file sits in .claude/agents/, everyone who clones the repository, including a cloud session or a CI job, gets the same reviewer with the same rules.
Keep the division of labor clear: your CLAUDE.md tells Claude how to write store-compatible code every day; the subagent judges a release candidate on demand.
Save it as .claude/agents/store-review-checker.md. The paths native/ios and native/android assume the WebViewGold projects live next to your web app; change them to your layout. Everything below the second --- line becomes the subagent's system prompt.
---
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.The name is how you call it (@agent-store-review-checker). The description is what Claude reads when it decides whether to delegate on its own, so it lists the trigger situations: before a submission, after changes to login, payments or native config, and the question "will this pass review?".
Read, Grep and Glob to inspect files, Bash for read-only git commands, WebFetch to look up current guideline text or the WebViewGold docs. No Edit and no Write: the reviewer reports, you decide what changes.
inherit uses whatever model your session runs. Set opus for a slower, deeper pass on a large codebase or sonnet for quick checks. color only changes how the agent appears in the terminal.
Evidence or it did not happen: every finding needs a file and line, otherwise it goes to "Needs a human check". This one rule removes most of the vague warnings that make automated reviews useless.
Grouped by store and tied to a guideline or policy name, so every finding is traceable. The WebViewGold block catches configuration mistakes that never show up in a review of the web app alone.
A fixed table with severity and "where to fix" (web app, WebViewGold config, store console, human decision). Fixed output makes runs comparable and easy to paste into a fix session.
Great way of converting your web app to a native app! Fast turn-around, and a great way to get your apps into the app stores without the need to develop a full native app!
Some things are not in the repository: what you sell, which features you switched on in the native projects, how the reviewer logs in, what Apple said last time. Put them in a short file the agent reads first. Keep real passwords out of it; they belong in the App Review section of App Store Connect and the App access form of the 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.About ten minutes, most of it reading the first report.
Run mkdir -p .claude/agents in the repository root, save the file above as .claude/agents/store-review-checker.md and commit it. Claude Code watches the folder and picks up later edits within seconds; only when the agents folder is brand new does the session need one restart.
Save docs/store-review.md with your real app facts and review history. Update it after every review result, approved or rejected; the history section is what stops the same mistake from happening twice.
Paste the prompt below, or call the agent directly with @agent-store-review-checker review the release candidate. Claude Code also delegates on its own when you ask something like "will this pass App Review?", because the description says so.
Start with the verdict line, then the Blocker rows. Each row says where the fix lives. Web app fixes go back into your main session, WebViewGold config fixes are small edits in Config.swift or Config.java, and store console items become your to-do list for App Store Connect and the Play Console.
Ask the main session to fix the blockers one by one with a commit each, then run the subagent again. A clean second run on the same commit is your signal to build.
The subagent reads code. Run the free App Store readiness check and the Play Store readiness check on your production URL to catch what only the deployed site shows, then test the build on a real phone.
Replace the version, the tag and the file names with yours. The last paragraph keeps the main session from rushing into edits before you have read the report.
Use the store-review-checker subagent to review this project before we submit version 1.3 to the App Store and Google Play. Scope: the whole web app plus native/ios and native/android. The last approved release is tagged v1.2.0, so give the commits after that tag extra attention. App facts, demo account notes and our review history are in docs/store-review.md. When the subagent returns, show me its report exactly as written. Then propose a fix plan for the Blocker rows only, grouped into: web app changes, WebViewGold config changes, store console tasks. Do not edit any file until I confirm the plan.
ios/ instead of native/ios, change the file, or the agent reports the native checks as "not found"./privacy, /terms and /delete-account load on the production domain, not only in development.Project subagents live in .claude/agents/ inside the repository and are shared through Git. Personal subagents that should work in every project go in ~/.claude/agents/. Each file is Markdown with YAML frontmatter; name and description are required, everything else is optional.
It can. Claude decides from the description field, which is why the example lists concrete trigger situations and says "use proactively". If you want certainty, name the subagent in your prompt or @-mention it.
inherit is a sensible default. Switch the model line to opus for a slower, more thorough pass before a major release, or to sonnet when you run it often on small changes.
Not directly, because it only sees the repository. Copy the description, keywords, App Privacy answers and Data safety answers into a file such as docs/store-listing.md and the agent will compare them with what the code actually collects.
No. It removes the predictable problems, but reviewers test the running app and policies change. WebViewGold adds a safety net for the rest: if Apple or Google reject the app for reasons that have nothing to do with your content, you can claim a refund of the license within 14 days of purchase.
Yes. Cloud sessions and the Claude Code GitHub Action work in a checkout of your repository, so the committed agent file is available there too. The GitHub Actions guide shows a workflow that runs a store-readiness review on every pull request.
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main page$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demo$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.
App Store & Google Play approval guarantee – or your money back within 14 days
Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.
Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.