Skip to content
WebViewGold Vibe Coding to App Store
English
Get WebViewGold

Claude Code

Writing the privacy policy, store listing and screenshot plan with Claude Code

Store metadata is where honest, specific writing wins. Claude Code has one advantage over a template generator: it can read your code and describe what the app actually does and collects. Use that, keep the honesty rules of Guideline 2.3 in mind, and the listing side of your submission is done in an hour.

From $109 one-time per platform, or let our team do it all from $698.

  • Approval guarantee – or money back within 14 days
  • No coding needed
  • One-time payment, free updates
  • 24/7 human support
  • Made in Germany since 2014 · ISO 27001

The rule that governs all of it: say what is true

Apple Guideline 2.3 (Accurate Metadata) and the Google Play policies on misleading claims and Data safety accuracy are enforced strictly against web-based apps, because reviewers expect screenshots of a website and descriptions that oversell. The privacy answers in App Store Connect and the Data safety form in the Play Console must match what the code does; a mismatch is a rejection on Google and a reason for removal later on both stores.

That is why every prompt here starts with "inspect the codebase". An agent that lists your Supabase tables, your analytics SDK and your Stripe webhook before writing a sentence produces a policy you can defend. The privacy labels guide explains the categories; this page gives you the prompts.

Privacy policy plus the store privacy answers

Prompt: data inventory, policy and console answers
Inspect this codebase and produce three things.

1. A data inventory as a table: data type (email, name, user ID, payment info, photos, location, usage data, crash data, device identifiers), where it is collected (file or component), where it is stored (database table, third-party service), purpose, whether it is linked to the user identity, and whether it is used for tracking across apps or websites. Include third-party SDKs and APIs (auth provider, analytics, error tracking, payments, push service, AI APIs that receive user content).
2. A privacy policy page at /privacy written from that inventory in plain English: what we collect, why, who receives it, how long we keep it, how users can delete their account in the app (/delete-account) and contact us. Mention that the iOS and Android apps use the same service. No practices we do not have, no boilerplate about cookies we do not set. Mark uncertain statements with TODO.
3. Draft answers for the Apple App Privacy questionnaire (data types, linked to user yes/no, used for tracking yes/no, purposes) and for the Google Play Data safety form (collected or shared, required or optional, encrypted in transit, deletion available), both derived from the same inventory so they cannot contradict each other. Note that the native iOS wrapper integrates the AdMob SDK even when ads are off; if we do not show ads, say that advertising data is not collected, but flag the App Store Connect advertising identifier (IDFA) question for me to answer as the wrapper documentation describes.

Typical stack, typical answers

ComponentWhat it means for App PrivacyWhat it means for Data safety
Supabase / Firebase AuthContact info (email), User ID; linked to user; not trackingPersonal info collected, required, encrypted in transit, deletable
Stripe on the web onlyNot collected in the app if checkout is hidden nativelyNot collected in the app; otherwise financial info via a payment processor
RevenueCat in-app purchasesPurchase history; linked to userApp activity: in-app purchases
OneSignal pushDevice ID (push token); linked to user if you store itDevice or other IDs; collected, optional
Product analytics (e.g. PostHog, Plausible)Usage data; tracking only if shared with ad networksApp activity and diagnostics; check the SDK docs for sharing
Camera or photo uploadsPhotos or videos; linked to userPhotos and videos; collected, optional

With a good optimized version of your web app you can have a stunning mobile app within a couple of minutes. Additionally to that the customer service is very nice and very helpful! I can just recommend WebViewGold :-)

Julian Koch · Co-Founder of DuelDonkey · CodeCanyon

Description, keywords and review notes

Prompt: the listing text
Write the store listing for this app based on the features that exist in the codebase today (check routes and components; do not list anything that is behind a feature flag or marked as coming soon).

Apple: app name (max 30 characters), subtitle (max 30), promotional text (max 170), description (up to 4000 characters, first two lines carry the message), keywords field (max 100 characters, comma separated, no spaces after commas, no words already in the name).
Google Play: title (max 30), short description (max 80), full description (up to 4000 characters).
Review notes for both stores: what the app does in two sentences, the demo account (I will fill in the credentials), the native features the app uses (push notifications, biometric login, native share, offline screen) and where to find them, and that users can delete their account under Settings.

Rules: no superlatives we cannot prove, no mention of other platforms or of being a beta, no references to the website version, no competitor names, no AI buzzwords unless the app is an AI product. Use the language the app UI uses.

The screenshot plan

Screenshots must show the real app on a device, not the website in a browser frame.

  1. Ask the agent for a shot list

    Prompt: "List the five screens that best show what this app does, in the order a new user meets them, with a seven-word caption for each." Captions become the text overlays if you add any.

  2. Prepare demo data

    Have Claude Code write a seed script for a demo account with realistic content (no Lorem ipsum, no test123). Screenshots of empty states are a 2.3 risk.

  3. Capture on devices or simulators

    Install the WebViewGold build (TestFlight or the Cloud Builder preview) and capture at the sizes App Store Connect and the Play Console require: current iPhone sizes, iPad if the app supports it, and a phone size for Android.

  4. Hide what is not the app

    No browser bars, no cursor, no desktop layouts, no Android screenshots in the Apple listing. Status bars are fine.

  5. Check against the description

    Every feature named in the description should be visible in a screenshot or reachable in the demo account. The reviewer will look for it.

Honesty rules the agent must follow (2.3 and Play policies)

  • No feature in the description that is not in the build the reviewer will see.
  • No "free" if the core features require a subscription; say what is free and what is paid.
  • No privacy answer of "not collected" for data a third-party SDK collects on your behalf.
  • No screenshot that is a mockup of a future design.
  • No ratings, awards or user counts you cannot document.
  • The privacy policy URL in both consoles must open the deployed page without login.

Frequently asked questions

Can I let Claude write the privacy policy without a lawyer?

For most small apps a policy that truthfully describes the data flow is what the stores check. If you operate in a regulated field or process health or financial data, have the draft reviewed by a professional.

Do iOS and Android need different privacy policies?

No. One policy page for the service is normal. Mention that the iOS and Android apps use the same service and link the same URL in both consoles.

Why does the agent mention AdMob when I do not show ads?

The WebViewGold iOS project integrates the AdMob SDK even when ads are switched off, so App Store Connect asks about the advertising identifier (IDFA). The WebViewGold publishing documentation describes the exact selection; if you show no ads, your App Privacy and Data safety answers simply state that no advertising data is collected.

Can I reuse the website screenshots?

No. Apple rejects screenshots that show a browser or a desktop layout under Guideline 2.3. Capture the running app.

How many keywords should I use?

Fill the 100 characters with specific terms people search for, without repeating words from the name or subtitle. The ASO guide in this section goes deeper.

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.

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 page

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 demo

Full 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 WeSetupYourWebViewApp

Winter Sale prices valid until December 31, 2026.

Ready to ship your app?

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.