Do it yourself
$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 pageWhy a wrapped app needs a review on every pull request
In a fully native app, code reaches users only after you build, submit and pass review. A WebViewGold app loads your production URL, so a merge to main is live in the store version as soon as it deploys. That is the big advantage of the approach (no resubmission for web changes, see web vs native updates) and the reason a careless pull request can break the app on every phone, or put a Stripe checkout for credits in front of iOS users between two reviews. Apple and Google look again with every native update you submit, and a rule broken in the meantime surfaces then.
Codex code review closes the gap. Once the repository is connected to Codex, it reviews pull requests on GitHub automatically or when someone comments @codex review, and posts a normal GitHub review with findings on specific lines. Two details shape the setup: on GitHub it reports only high-priority findings (P0 and P1), and it reads review rules from a ## Code Review Rules section in your AGENTS.md files, applying the root file plus the most specific nested file for each changed path. So the store rules have to be written down, and they have to be marked as P1.
Set it up in fifteen minutes
Connect the repository
In Codex, connect GitHub and grant the Codex connector access to the repository. Reviews on GitHub do not need a cloud environment; Codex reads the pull request itself.
Turn on automatic reviews
Open the code review settings in Codex, choose the repository and switch on automatic review. Configuring it needs push or admin permission on the GitHub repository. Without automatic reviews, a comment with
@codex reviewon a pull request requests one.Write the rules
Add the
## Code Review Rulessection below to the root AGENTS.md (or to the AGENTS.md from our template). Start short: OpenAI recommends a few concise rules and leaving formatting and lint to CI. Nested AGENTS.md files can add folder rules, for example stricter ones for your server functions.Protect main
Require pull requests and passing checks for the main branch in the GitHub repository settings. Codex comments; it does not block merges. Branch protection does.
Prove that it works
Open a throwaway pull request that breaks one rule on purpose, for example a Stripe payment link shown when
isNativeApp()is true. If Codex does not flag it, make the rule more concrete and try again, then close the pull request without merging.
Code Review Rules for a WebViewGold app
Paste into AGENTS.md and adjust names to your codebase. The "Treat as P1" line matters: GitHub reviews show only P0 and P1 findings, so without it a store rule may be judged minor and never appear.
markdown
## Code Review Rules
These rules protect the App Store and Google Play releases of our WebViewGold
apps, which load this web app in a native WebView. Treat every violation below
as P1.
### Secrets
- No API keys, service-role keys, private keys or tokens in client code, in
public env variables (NEXT_PUBLIC_*, VITE_*) or in committed .env files.
- Server-only keys (database service role, OpenAI, Stripe secret) are read in
server code only.
### Store rules
- Digital goods, subscriptions and credits: when isNativeApp() is true, buy
buttons use the in-app purchase path (revenuecat://purchase?...). No Stripe
checkout, card form or external payment link for digital goods in the app.
- Account deletion (settings screen and /delete-account) keeps working and
deletes server-side.
- A new Google, Facebook or other third-party login requires Sign in with
Apple with equal prominence.
- /privacy and /terms stay reachable from settings and the footer.
- No placeholder text, lorem ipsum, "coming soon" screens or dead links in
routes reachable from the app.
- No "Download our app" banners or App Store / Google Play links when
isNativeApp() is true.
### Mobile layout inside the WebView
- Fixed headers, footers and bottom sheets pad with env(safe-area-inset-*).
- Tap targets 44x44px or larger; inputs use font-size 16px or more.
- No hover-only controls; no horizontal scrolling at 320px width.
- Login and payment flows do not depend on window.open popups.
### WebViewGold bridge
- Bridge calls run only behind isNativeApp() and keep a web fallback.
- Only URL schemes documented in https://www.webviewgold.com/llms-full.txt.
Flag any scheme that is not in that file.
I am very happy I bought this app! Extremely easy and great documentation. Was in contact with the customer service, they replied very quickly and very friendly. They solved my question within a day. 10/10 would recommend.
What each rule protects
| Rule | Why it matters | A typical P1 finding |
|---|---|---|
| No secrets in client code | Anything in the bundle is readable by everyone who opens the app or the site; a database service-role or OpenAI key means a data leak or a large bill | VITE_OPENAI_API_KEY used directly in a React component |
| Digital goods through in-app purchase | Apple Guideline 3.1.1 and Google Play's payments policy (with regional exceptions); the most common rejection for AI and SaaS apps, see Guideline 3.1.1 | A credits pack button opens Stripe Checkout without an isNativeApp() branch |
| Account deletion keeps working | Apple 5.1.1(v) and Google Play require in-app deletion for apps with sign-up | A refactor removed the call to the server-side delete function |
| Sign in with Apple parity | Apple 4.8 applies when a third-party login exists | A new "Continue with Google" button with no Apple option |
| Safe areas, 44 px targets, 16 px inputs | Apple 4.0 design rejections; iOS zooms into inputs smaller than 16 px, see safe areas and tap targets | A new bottom navigation with position: fixed; bottom: 0 and no inset |
| No website leftovers in the app | Reviewers read download banners and store links as "this is a website" (Guidelines 4.2 and 2.3) | A "Get the app" banner rendered for every user agent |
| Only documented bridge schemes | An invented scheme fails silently inside the app | window.location.href = "share://..." instead of shareapp:// |
The pre-release review request
Automatic reviews already apply your rules. Before a store submission, ask for a focused pass on the release pull request; the text after @codex review narrows that one review without changing AGENTS.md.
Comment on the pull request
@codex review for App Store and Google Play release blockers. Apply the Code Review Rules in AGENTS.md and focus on: secrets or server-only keys reachable from client code; digital goods, subscriptions or credits sold without the in-app purchase path when isNativeApp() is true; any change that weakens account deletion, the privacy and terms pages or Sign in with Apple parity; fixed headers, footers or sheets without safe-area insets, tap targets below 44px and inputs below 16px; download banners or store links visible inside the app; bridge URL schemes that are not documented in https://www.webviewgold.com/llms-full.txt.
Review everything since the last store build
A pull request review sees one change. Before you submit a new native build, review the whole distance since the last submission: tag each submitted state, then open a review-only pull request from main against a branch made from that tag. Comment the request above, work through the findings, and close the pull request without merging.
bash
# when you submit a build to the stores, tag the state of main
git tag store-1.2.0
git push origin store-1.2.0
# before the next submission: a base branch at the old state
git branch review/store-1.2.0 store-1.2.0
git push origin review/store-1.2.0
# review-only pull request: base = the old state, head = main
gh pr create --base review/store-1.2.0 --head main \
--title "Release review: changes since store 1.2.0" \
--body "Review only. Do not merge."Review locally before you push
In the Codex CLI, /review starts a separate reviewer that reads a diff (against a base branch, uncommitted changes or a commit) and reports prioritized findings without changing your files. Pick custom review instructions and paste this:
Codex CLI: /review, then custom review instructions
Review the changes against main as a release gate for our WebViewGold iOS and Android apps, which load this web app in a native WebView. Report every violation of the Code Review Rules in AGENTS.md with file, line, the rule, why it would block an App Store or Google Play release, and the smallest fix. Then list what needs a check on a real phone (layout under the notch and home indicator, the keyboard covering inputs, login and purchase flows). Do not report formatting or naming issues.
What Codex review will not do for you
- Replace tests, branch protection or a human approval. OpenAI says the rules guide Codex; they do not replace those. Treat findings as a second pair of eyes.
- See outside the repository. Config.swift, Config.java and the console settings are invisible unless the WebViewGold project is in the same repository, and your App Privacy and Data safety answers are never checked.
- Surface minor findings on GitHub. Only P0 and P1 appear there; a store rule without "Treat as P1" may never show up.
- Run the app on a phone. Layout findings come from reading CSS, not from a screenshot; the Play Store readiness check and a device build remain your job.
- Always be right. Check each finding against the diff before you act. A request like
@codex fix the P1 finding(any mention other thanreview) starts a cloud task that can push to the branch, so review that commit too.
Frequently asked questions
Does Codex code review cost extra?
Code review is a Codex feature, and Codex comes with paid ChatGPT plans that have plan-dependent usage limits. Check the current terms for your plan before you enable automatic reviews on a busy repository.
Will Codex comment on style and naming?
Not on GitHub: there it reports only P0 and P1 findings. That is also why store rules need an explicit "treat as P1". Keep formatting in your linter and CI.
Can Codex fix what it finds?
Yes. Comment @codex with a request other than review, for example "@codex fix the P1 finding about the Stripe button". It starts a task with the pull request as context and can push a fix to the branch if it has permission. Review that commit like any other.
Does it work for private repositories?
Yes, once you grant the Codex GitHub connector access to the repository. Configuring automatic reviews requires push or admin permission on it.
An older tutorial used a "Review guidelines" heading. Does that still work?
Current OpenAI documentation names the section ## Code Review Rules. Rename the heading to match, keep the rules underneath, and test with a pull request that breaks a rule on purpose.
Should the WebViewGold project live in the same repository?
It can, and then reviews also see changes to Config.swift and Config.java. Many teams keep it separate because native changes are rare. Either way, never commit certificates, provisioning files or keystores.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Cloud Builder
$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 demoFull Service
$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.