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 Cline suits the WebViewGold projects
The WebViewGold projects are ordinary Xcode and Android Studio projects whose behavior is set in two readable files: Config.swift (iOS) and Config.java (Android). Next to them sit Info.plist, AndroidManifest.xml, strings.xml and, for OneSignal on Android, the IDs in build.gradle. Configuring an app is mostly changing values, which is precise, low-risk work if the agent sticks to the documented option names in the iOS setup docs and Android setup docs.
Cline brings three things that help here. Bring your own model: you connect a provider and key (Anthropic, OpenAI, Google Gemini, OpenRouter, AWS Bedrock and others, or a local model through Ollama or LM Studio), and you can use different models for Plan and Act. Plan and Act modes: Plan explores and proposes without touching files, Act executes. Checkpoints are on by default, so you can roll a step back. Add rules on top and the agent knows where the line is. (For how Cline compares with Claude Code, Codex and the rest, see the AI coding agents overview.)
One privacy note: with a hosted provider, every file the agent opens is sent to that provider. Your WebViewGold configuration contains your purchase code and service IDs, so either keep those for a manual edit or use a local model for the native folders.
A scoped rule for the native projects
Cline reads workspace rules from .clinerules/ (or .cline/rules/), global rules from ~/Documents/Cline/Rules, and also AGENTS.md, .cursorrules and .windsurfrules. A paths list in YAML frontmatter makes a rule apply only when matching files are in play (Cline rules documentation). Save this as .clinerules/webviewgold-config.md.
markdown
---
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).
My iOS WebView is finally approved. Thanks!!
Other rule files worth adding
.clinerules/01-context.mdwithout frontmatter (always active): the repository layout (web/, ios/, android/), the production URL, and the fact that web deploys go live in the apps while native changes need a store build..clinerules/web-app.mdwithpaths: ["web/**"]: the store rules for the web code (safe areas, Sign in with Apple, account deletion, no secrets in client code). The Cursor rules guide, the CLAUDE.md template and the AGENTS.md template have ready-made text.- An
AGENTS.mdat the root if other agents work in the same repository. Cline lists it in the Rules panel, where every rule can be toggled on or off.
The configuration pass, step by step
About an hour, most of it reading diffs.
Set up the workspace
Open one VS Code workspace with the web project and the unzipped WebViewGold folders (or one repository with web/, ios/ and android/). A
.clineignorekeeps build output out of the automatic context, but per Cline's docs it is not an access boundary: keep keystores and .env files out of the workspace entirely.Choose models
A strong model for Plan mode, where the agent reads the docs and decides; a cheaper or local one is fine for Act mode, where it changes a dozen values. Small local models follow long rule files poorly, so keep the native rule short.
Plan first
Switch to Plan mode and paste the prompt below. You get a table of every option, its current value and the new one, before a single file changes.
Act with tight approvals
Auto-approve file reads if you like, but approve every edit and every terminal command yourself. Avoid YOLO mode for this pass: a single wrong boolean (cache cleared on every start, push prompt on first launch) costs real users.
Build to verify
Let Cline run a debug build from the terminal (for example the Gradle wrapper's debug task in the Android folder) and fix only errors it introduced. Run the iOS project in the Xcode simulator yourself.
Sign and ship outside the agent
Bundle ID, signing, archive and upload happen in Xcode and Android Studio, or in the Cloud Builder if you do not want to install either IDE.
Plan-mode prompt for the configuration pass
Replace the URL and IDs. The table it produces is the thing to review.
Paste into Cline in Plan mode
Read the rules in .clinerules first. Then locate Config.swift in ios/ and Config.java in android/ (search for them, do not guess paths), and read https://www.webviewgold.com/llms-full.txt for every option you are about to touch. Goal: configure both apps for production. - URL: https://app.example.com. iOS: host and webviewurl. Android: HOST and HOME_URL. - User agent: the platform's default mobile user agent followed by a space and the token WebViewGoldApp. iOS: useragent_iphone and useragent_ipad. Android: USER_AGENT. - Push with OneSignal, App ID [paste]. iOS: kPushEnabled true, oneSignalID, and askforpushpermissionatfirstrun false because the web app calls registerpush:// after onboarding. Android: PUSH_ENABLED true and the OneSignal ID where the documentation says (build.gradle). - Auto-injected JavaScript variables on: autoInjectVariable (iOS), AUTO_INJECT_VARIABLES (Android). - Permissions: the app uses the camera; it does not use location or the microphone. iOS: remove the unused usage descriptions in Info.plist but keep the Privacy - Tracking Usage Description key. Android: requireLocation and requireRecordAudio false, and remove the matching AndroidManifest.xml entries. In Plan mode, output a table: file, option, current value, new value, and the documentation line that justifies it. Flag every option you could not find in the documentation instead of inventing it. Do not plan changes to signing, provisioning, keystores, signingConfigs, the purchase code, dependency versions or bundle identifiers. When I switch to Act mode, apply one file at a time and show the diff after each.
What the agent may touch, and what stays with you
| File | Let the agent edit | Keep for yourself |
|---|---|---|
| Config.swift | host, webviewurl, user agent, push switches, autoInjectVariable, openallexternalurlsinsafaribydefault | The purchasecode value (paste it yourself) |
| Config.java | HOST, HOME_URL, USER_AGENT, PUSH_ENABLED, AUTO_INJECT_VARIABLES, the require... permission flags | PURCHASECODE |
| Info.plist | Usage description texts; deleting unused ones | The Privacy - Tracking Usage Description key must stay |
| AndroidManifest.xml | Removing permissions for APIs you switched off | Intent filters for App Links, unless the task is deep linking |
| build.gradle | OneSignal IDs | signingConfigs, plugin and dependency versions |
| Xcode / Android Studio project settings | Nothing | Team, certificates, keystore, bundle ID, package name (choose once) |
Pitfalls
- Settings that look harmless:
deletecacheorCLEAR_CACHE_ON_STARTUPset to true logs users out on every launch;uselocalhtmlfoldertrue loads the bundled sample page instead of your URL. - Find-and-replace on the package name. The Android package and the iOS bundle ID appear in several places and extension targets; rename through the IDE.
- A small model "fixing" Swift syntax by restructuring Config.swift. The rule "values only, keep structure" exists for exactly this.
- Treating .clineignore as a vault. It only controls what is loaded automatically; explicit mentions and shell commands can still read ignored files.
- Secrets copied from the web project into the native config. RevenueCat's public SDK key and the OneSignal App ID belong there; server keys never do (see the secrets guide).
- Old Roo custom modes with broad edit permissions. If you move to a fork or to Cline, re-check what each mode is allowed to change.
Verify after the agent is done
- The iOS simulator and an Android emulator open your production URL, not a sample page.
- A test page that prints
navigator.userAgentshows the WebViewGoldApp token in both apps. - On iOS, the push prompt only appears after your Enable notifications button calls
registerpush://. - Info.plist contains usage descriptions only for APIs you use, plus the tracking key.
- The diff of Config.swift and Config.java contains value changes only. Read it once, line by line.
- Native feature calls in the web app follow the push notification docs for each platform.
Frequently asked questions
Can I still use Roo Code?
Its team archived the repository and shut the extension down on May 15, 2026, so expect no fixes or provider updates. The README points to the community fork ZooCode and to Cline. Your rule files are plain Markdown and move over easily.
Which model should I use with Cline for this?
Any capable coding model works, because the task is precise rather than creative. Use a strong model in Plan mode to read the documentation and a cheaper or local model in Act mode if you like. What matters most is a short, strict rule file.
Does Cline read AGENTS.md?
Yes. Cline reads AGENTS.md from the workspace and from ~/.agents/AGENTS.md, and it also detects .cursorrules and .windsurfrules. All of them appear in the Rules panel, where you can toggle each one.
Can Cline build and upload the apps?
It can run command-line builds with your approval. Signing, archiving and uploading to App Store Connect and the Play Console stay with you in the IDEs, or with the Cloud Builder.
Is my code sent to the model provider?
With a hosted provider, yes: whatever the agent reads goes to that provider under its terms. With a local model through Ollama or LM Studio, it stays on your machine. Decide per folder if the native configuration holds values you do not want to share.
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.