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

App Store rejection

Guideline 5.1.1 (Data Collection and Storage): privacy policy, permissions, account deletion and labels

5.1.1 is the most frequent privacy rejection for apps built with AI tools, and it almost never concerns what you do with data. It concerns what you failed to declare: a policy link, a purpose string, a delete button, a label. Each fix takes minutes once you know where it goes.

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

What 5.1.1 covers

The section asks apps that collect any user or usage data to have a privacy policy, linked in App Store Connect and inside the app, that explains what is collected, how it is used, who it is shared with, and how users can request deletion. Permission requests must explain their purpose in the system dialog and may only be made when the feature needs them. Apps must ask for the minimum data their core features require, and apps that let people create an account must let them delete it inside the app.

Web-wrapped apps inherit the website's data flows, so the policy usually exists already. The rejection comes from the missing pieces around it: no policy URL in the store record, no "Delete account" in settings, a template permission text, or App Privacy labels filled in as "no data collected" while the app has a sign-up form.

The sub-rules reviewers quote

  • 5.1.1(i)

    Privacy policy

    A link in the App Store Connect metadata and inside the app, with the data collected, its use, third-party sharing, retention and deletion.

  • 5.1.1(ii)

    Permission

    Purpose strings that explain the use, requested only when the feature needs them; the app must keep working if the user declines.

  • 5.1.1(iii)

    Data minimization

    Ask only for data relevant to the core functionality. A recipe app does not need contacts.

  • 5.1.1(iv)

    Access

    Do not trick, pressure or block users into granting permissions they do not need for the task at hand.

  • 5.1.1(v)

    Account sign-in

    Apps that support account creation must offer account deletion within the app, not just by email request.

Fix the four findings that make up most 5.1.1 rejections

  1. Privacy policy, reachable from both places

    Publish it at yourdomain.com/privacy and link it from the app's settings or footer and from the privacy policy field of the app version in App Store Connect. The privacy policy guide has a structure that covers web and app; the WebViewGold docs offer an optional sentence explaining that the app shows the website's content in a WebView and that the same policy applies.

  2. Account deletion in the app

    A "Delete account" button in settings that calls a backend function (Supabase Edge Function with the service role, Firebase callable function), deletes the auth user and their rows, then signs out. A mailto link or "contact support" is rejected. Walkthrough: account deletion for Supabase apps.

  3. Purpose strings that say why

    In the WebViewGold project, rewrite every Info.plist usage description you keep: "Use your location to show nearby courts" instead of template text. Ask at the moment of use: call the geolocation API only when the user taps "Near me"; keep askforpushpermissionatfirstrun false and trigger registerpush:// after onboarding.

  4. App Privacy labels that match reality

    In App Store Connect, declare what the web app collects: email and name from sign-up (Contact Info), user ID (Identifiers), analytics events (Usage Data), purchases (RevenueCat or Stripe), device identifier only with AdMob. Mark whether data is linked to the user and whether it is used for tracking. The policy, the labels and the app must tell the same story.

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

What a typical vibe-coded app collects

DataSourceLabel category
Email, nameSign-up, Sign in with Apple, Google loginContact Info, linked to user
User IDSupabase, Firebase, ClerkIdentifiers, linked to user
Usage events, screens viewedPostHog, Plausible, GA4Usage Data; linked if tied to the user ID
Purchase historyRevenueCat, StripePurchases, linked to user
Device advertising IDAdMob personalized adsIdentifiers, used for tracking (needs ATT)

A delete-account flow that reviewers accept

Confirmation, backend deletion, sign-out. The Edge Function removes the auth user and related rows with the service role key.

javascript
// Settings page: Delete account (Supabase example)
async function deleteAccount() {
  if (!confirm("Delete your account and all of your data? This cannot be undone.")) return;
  const { error } = await supabase.functions.invoke("delete-account");
  if (error) { alert("Deletion failed. Please contact [email protected]."); return; }
  await supabase.auth.signOut();
  window.location.href = "/account-deleted";
}

Frequently asked questions

Can account deletion be a request form that I process manually?

No. The user must be able to start the deletion in the app and it must actually remove the account. A short grace period or a confirmation email is acceptable if the deletion then happens without further action.

Which privacy policy URL do I enter: the website one or an app-specific one?

The same policy can serve both if it mentions the app. Add a sentence that the iOS app displays the website and uses the same data practices, plus any app-only data such as push tokens.

Do App Privacy labels need to list the WebViewGold SDKs?

You declare data your app collects, whatever collects it. OneSignal push tokens, RevenueCat purchase data and AdMob identifiers belong in the labels if you enabled those features; dormant SDKs that collect nothing do not.

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.