Guideline 4.2 — Capacitor / WebView evidence checklist

Use this when App Review cites 4.2 Minimum Functionality (or “repackaged website,” “web content,” “insufficient native features”) for a Capacitor, Cordova, PWA shell, React Native WebView, or similar wrapper.

This is a checklist and drafting aid. It is not legal advice and not a guarantee of approval. Apple decides. Do not log into App Store Connect on anyone else’s behalf.

What 4.2 is actually testing

Apple is not asking whether Capacitor can call native APIs. Apple is asking whether this binary is more than a website in a frame.

Typical rejection language (paraphrased from public forum reports):

• The app provides a limited set of features / is a repackaged website.
• Features are not enough to be a useful App Store app.
• The app primarily displays web content.

If the product is still “our marketing site inside WKWebView,” a better letter will not save it. Ship native value, then reply with evidence.

Decision tree (fix vs appeal)

1. The iOS app is the website, plus a splash screen.

Do not appeal yet. Add native surfaces (below), rebuild, resubmit with screenshots.

1. Native features exist but Review only saw the WebView.

Appeal / reply with dated screenshots of native-only flows, plus a short list of what is not on the website.

1. 4.2 plus 4.3 (spam / similar).

Treat uniqueness separately. Native chrome on a template clone still looks like spam.

1. Metadata mismatch (screenshots show native; binary does not).

That is a 2.3 problem. Fix metadata or the binary first; do not argue 4.2 until they match.

Native evidence Apple can actually see

Reviewers will not SSH into your repo. They will tap the app. Prefer features that are impossible or clearly worse on the website.

High-signal (show these first)

• Native tab bar / navigation that is not the website header
• iOS share sheet (Share / UIActivityViewController) from in-app content, not a web share dialog
• Camera, Photos, document picker, or Files with a system sheet
• Push via APNs (not browser web push) with a live notification screenshot
• Offline mode with a native empty/error state when the network is off
• Face ID / Touch ID / passkeys for an in-app lock or sign-in
• Haptics + native alerts on a core action (save, complete, capture)
• In-app purchases / StoreKit if you sell digital goods (do not point to a website checkout)
• Widgets, Live Activities, App Intents, or Spotlight items if they are real

Medium-signal (supporting)

• Universal Links that open a specific in-app screen, not just the homepage WebView
• Local notifications scheduled from a native action
• Background refresh that updates a native list
• Voice input, NFC, Bluetooth, HealthKit, or other hardware only where the category needs it
• Accessibility: Dynamic Type, VoiceOver labels on native chrome

Low-signal (do not lead with these)

• “We use Capacitor / Swift / Xcode”
• A native splash screen
• App icons and launch storyboard
• Pull-to-refresh on a WebView
• “Other Capacitor apps are on the store”
• A settings page that is still HTML

Screenshot checklist (attach or describe in Resolution Center)

Capture on a real device or Simulator with no unrelated account data. Redact emails.

• [ ] Home: native chrome visible (tabs, native title, not a browser URL bar)
• [ ] Feature A that does not exist on the website (annotate the difference)
• [ ] System sheet: share, camera, document picker, or biometric prompt
• [ ] Airplane mode / offline: app still useful or shows a native fallback
• [ ] Push: lock screen or notification center from APNs
• [ ] Before/after if you just shipped native work (two builds, two dates)

Three tight screenshots beat twelve website captures.

Capacitor-specific implementation notes

• Keep the WebView for content, not for IA. Navigation chrome should be native (@capacitor/app, native tabs, or a thin Swift UI shell).
• Use official plugins (@capacitor/share, camera, push-notifications, local-notifications, preferences, filesystem) rather than injecting JS bridges Review cannot see.
• If the website and the app share a URL, add at least one app-only route (onboarding, offline library, capture inbox).
• Remove leftover “Open in Safari,” desktop nav, cookie banners that scream “mobile web.”
• Status bar, safe areas, and keyboard avoidance should look like an iOS app, not a squeezed site.

What not to claim in Resolution Center

• “Capacitor is native, therefore 4.2 does not apply.”
• “Please approve, we are a small indie / we already paid $99.”
• “Competitors with wrappers were approved.”
• “The website is the product and users prefer it.”
• Fake native screenshots or metadata that oversells.

Cursor / agent prompt (optional)

Paste into your repo agent after you decide which native surfaces are real:

Implement native iOS surfaces for a Capacitor app that was rejected under Guideline 4.2.
Do not add fake screens. Add: native tab navigation, Share sheet on [CONTENT],
offline fallback using Preferences/Filesystem, and APNs registration if we already
have a server. Keep the WebView for [CONTENT_AREA] only. Add a short in-app
“What’s native in this build” debug screen behind a hidden gesture so we can
screenshot evidence. No App Store Connect credentials. No changes to Android.

Reply skeleton

Use content/kit/resolution-center-skeletons.md (4.2 — native features added, or 4.2 — evidence of existing native). Fill brackets. Keep it under ~400 words. Lead with what the reviewer can tap, not with your stack.

Guideline 4.3 — spam / clone reply skeleton

Use this when App Review cites 4.3 Spam (similar apps, duplicate binaries, template spam, “this app is not unique enough,” or a cluster of near-identical listings from one account).

This is a drafting aid. Not legal advice. No approval guarantee. If the app is a reskin of a public template, rewrite the product before rewriting the letter.

What 4.3 is actually testing

Apple is looking for spam patterns, not a philosophical debate about originality:

• Multiple binaries that share UI, assets, and copy with tiny keyword swaps
• Apps that replicate a popular app’s look or workflow without new data or audience
• Template generators (including AI site exporters) submitted as many “unique” apps
• Developer accounts that look like a farm: 8 near-identical utilities

Public uniqueness (“we thought of it”) is weaker than demonstrable uniqueness: data, workflow, audience, and binary differences a reviewer can see in 60 seconds.

Decision tree

1. This binary is a reskin of another app you shipped, or of a public starter.

Do not argue 4.3. Merge, differentiate the IA, replace assets, and change the listing. Then resubmit.

1. Same category as a giant incumbent, but your data and workflow are yours.

Reply with side-by-side: what the user does here that they cannot do in Generic App X, plus original content sources.

1. Review confused metadata (name/screenshots) with a clone; the binary is different.

That is also a metadata problem. Align name, screenshots, and first-run experience, then explain the mismatch.

1. You submitted several micro-apps from one account.

Expect extra scrutiny. Each listing needs a distinct job-to-be-done, not a color swap.

Differentiation evidence checklist

• [ ] Original copy and icon (not a marketplace template with your hex code)
• [ ] First-run flow unique to this job (not “Sign in with the website”)
• [ ] Data the user cannot get from the wrapped marketing site or from App X
• [ ] Features that are not a thin filter on the same CRUD as your last app
• [ ] Bundle ID, display name, and screenshots that do not look like a series
• [ ] If you used Lovable / Bolt / v0 / Cursor: strip generator chrome, lorem, and identical card layouts

What not to claim

• “All to-do apps look the same, so 4.3 is unfair.”
• “We changed the color and the name.”
• “AI wrote a unique product.”
• “Please check the Android version.”
• Attacks on the reviewer or on Apple’s process.

Paste-ready skeleton (fill brackets)

Hello App Review,

Thank you for the 4.3 note on [APP_NAME] ([BUNDLE_ID]).

This submission is not a duplicate or a reskin of another app we publish, and it is not a template with swapped keywords. The job it performs is [ONE_SENTENCE_JOB], for [SPECIFIC_AUDIENCE].

What is unique in this binary (visible on first launch, no account required if possible):
1. [NATIVE_OR_IN_APP_FLOW_1 — what the reviewer taps]
2. [DATA_OR_WORKFLOW_2 — source of content / why it is not App X]
3. [DIFFERENCE_FROM_OUR_OTHER_APPS if the account has more than one listing]

We are not asking for an exception to 4.3. We aligned the name, screenshots, and first-run experience so they show this job only. Screenshots attached: [A], [B], [C].

We remain the account holder and will resubmit from App Store Connect ourselves.

[NAME]

If you also got 4.2

Do not blend the arguments. 4.3 is uniqueness. 4.2 is native value. A unique website wrapper can still fail 4.2. Ship native evidence from the Capacitor checklist, then keep this 4.3 paragraph short.

Evidence checklists and pre-submit risk list

Run this before every resubmit. Overnight packs use the same list, filled in from your rejection text.

Not legal advice. No approval guarantee.

Screenshot evidence (all 4.2 / 4.3 / metadata cases)

• [ ] Captured from the iOS binary, not the website
• [ ] No Safari / Chrome URL bar
• [ ] No debug banners, Expo QR, “localhost”, or generator watermarks
• [ ] Personal data redacted
• [ ] At least one system UI (share sheet, permission dialog, keyboard, widget)
• [ ] First launch matches the App Store screenshots
• [ ] Filename or caption maps to a sentence in the Resolution Center reply

Pre-submit risk list (wrapper / vibe-coded apps)

1. Same URL as the marketing site, same nav, same cookie banner. High 4.2 risk.
2. Lovable / Bolt / v0 / Cursor default card layout still visible. High 4.3 + metadata risk.
3. Website checkout for digital goods. StoreKit problem; do not hide it in a WebView.
4. Analytics in the wrapped site, “Data Not Collected” in App Privacy. 5.1.1 risk.
5. Screenshots from Figma or Android. 2.3 risk.
6. Multiple listings with the same IA and icon family. 4.3 risk.
7. Reply that argues process (“other apps got through”) instead of evidence. Wastes the review cycle.
8. Credentials in a shared doc or a “rescue” vendor login. Out of scope for AppGate; never do this.

What to send in an Overnight Pack (you keep ASC)

Paste into /overnight:

• Full rejection email / Resolution Center text
• Guideline code if shown
• App Store listing URL if live
• Notes: stack (Capacitor, RN WebView, etc.), native features already shipped, links to 1–3 screenshots

Do not send: Apple ID, app-specific passwords, 2FA codes, .p8 keys, or session cookies.

Pack contents you should expect back

• Guideline cite and a fix-vs-appeal call
• Filled evidence checklist
• One paste-ready Resolution Center draft
• Resubmit notes (binary vs metadata-only)
• “What not to claim” for your case
• Optional agent prompt for native screens

Metadata reply skeleton (Guideline 2.3.x)

Use this when Review cites 2.3 Accurate Metadata, screenshot mismatch, keyword stuffing, placeholder copy, or “the app is not as advertised.”

Common with vibe-coded exports: marketing site screenshots, desktop web captures, lorem in the description, or AI chrome that is not in the binary.

Not legal advice. No approval guarantee.

What to fix before you write

Metadata must match this binary, this locale, this device class.

• [ ] App name and subtitle describe the actual job (not a keyword list)
• [ ] Description has no “Lorem,” “TODO,” competitor names used as keywords, or “ChatGPT-powered” claims you cannot show
• [ ] Screenshots are from the iOS app, not the website or Figma
• [ ] 5.5" / 6.7" sets are not stretched Android captures
• [ ] In-app purchases match StoreKit products, not a website price table
• [ ] Support URL and privacy policy load, are app-specific, and match the privacy nutrition labels
• [ ] Preview video, if any, does not show features behind a web paywall Apple cannot purchase in-app

If screenshots still show a browser URL bar, fix the build first (see the 4.2 checklist).

Paste-ready skeleton

Hello App Review,

Thank you for the metadata feedback on [APP_NAME].

We updated the listing so it matches binary [VERSION] ([BUILD]):
- Name / subtitle: [ACCURATE_PHRASE]
- Description: removed [PLACEHOLDER / KEYWORD_LIST / UNSUPPORTED_CLAIM]
- Screenshots: captured on [DEVICE] from the iOS app, showing [SCREENS]. They no longer use website or mockup frames.
- Support URL and privacy policy: [URLS], aligned with the privacy labels in App Store Connect.

The binary behavior has not been oversold. If any screenshot still looks like web content, it is because [BRIEF_NATIVE_CONTEXT]; the 4.2 notes (if any) are addressed separately.

We will upload the corrected metadata / new build from our own App Store Connect account.

[NAME]

What not to claim

• “Screenshots are aspirational / coming next sprint.”
• “The website is more up to date than the app.”
• Keyword stuffing as “ASO best practice.”
• Another team’s screenshots or stock UI kits as if they were your app.

Privacy reply skeleton (Guideline 5.1.1)

Use this when Review cites 5.1.1 (privacy policy, data collection, permission strings), nutrition label mismatch, or tracking that the WebView does without declaring it.

Wrapper apps fail this when the website’s analytics SDK loads inside WKWebView while App Privacy says “Data Not Collected.”

Not legal advice. No approval guarantee. This is not a DPIA and not counsel.

Align three sources of truth

1. What the binary does (native plugins + WebView third parties)
2. App Privacy answers in App Store Connect
3. Privacy policy at the public URL

If any of the three disagrees, fix the product or the answers before arguing.

Wrapper-specific traps

• Google Analytics / Meta pixel / session replay in the wrapped site
• Third-party fonts and CDNs that set cookies
• Sign-in with a website that collects email while the label says no contact info
• Capacitor plugins: camera, geolocation, contacts, tracking ATT
• Missing NSCameraUsageDescription (and friends) when a plugin can trigger the prompt
• “Sign in with Apple” required if you offer other third-party logins

Evidence checklist

• [ ] Privacy policy names the iOS app, data categories, and retention in plain language
• [ ] App Privacy labels match actual SDKs (including those injected by the website)
• [ ] Permission strings describe a real in-app use, not “for better experience”
• [ ] Tracking vs not tracking matches ATT if you use advertising identifiers
• [ ] Account deletion path exists if you create accounts
• [ ] You can screenshot Settings → Privacy disclosures or the in-app policy screen

Paste-ready skeleton

Hello App Review,

Thank you for the 5.1.1 / privacy note on [APP_NAME].

We aligned the binary, App Privacy answers, and the policy at [POLICY_URL]:
- Data we collect: [CATEGORIES], used for [PURPOSE], linked to identity: [YES/NO].
- Third parties in the WebView: [LIST OR “none after this build”]. We [removed / disclosed] [SDK].
- Permission strings: [CAMERA / LOCATION / …] fire only when the user starts [FEATURE].
- Account deletion: [PATH], documented in the policy.

We do not ask you to ignore undeclared collection. The resubmitted build and labels match. We will upload from our own App Store Connect account; we are not providing credentials.

[NAME]

What not to claim

• “It’s just a WebView so Apple’s privacy labels do not apply.”
• “Analytics is anonymized” without checking the actual SDK.
• Copy-pasted privacy policies that name the wrong company or only GDPR for a different product.

Resolution Center reply skeletons

Six paste-ready drafts. Replace every [BRACKET]. Keep replies short, factual, and tied to what a reviewer can tap. Do not attach Apple ID passwords. Do not promise that Apple must approve.

Not legal advice. No approval guarantee.

1. 4.2 — native features added after rejection

Hello App Review,

Thank you for the Guideline 4.2 feedback on [APP_NAME] ([BUNDLE_ID]).

We treated this as a product gap, not a wording gap. Binary [VERSION] ([BUILD]) adds native iOS surfaces that are not available on [WEBSITE_URL]:

1. [FEATURE_1 — e.g. native tabs + Share sheet on saved items]
2. [FEATURE_2 — e.g. APNs alerts for [EVENT]]
3. [FEATURE_3 — e.g. offline library via on-device storage]

Attached screenshots were taken from this build on [DEVICE], including Airplane Mode for the offline path. The WebView remains for [LIMITED_CONTENT_AREA] only.

We are not requesting an exception to 4.2. Please review the new binary. We will submit from our own App Store Connect account.

[NAME]

2. 4.2 — native features already existed; evidence was unclear

Hello App Review,

Thank you for the 4.2 note. We believe the rejection reflects what was easy to miss on first launch, not the absence of native functionality.

Without creating an account, a reviewer can:
1. Open [SCREEN] from the native tab bar (not the website header)
2. Trigger [SYSTEM_SHEET: share / camera / Face ID]
3. Use [OFFLINE_OR_PUSH_FLOW]

Screenshots [A–C] show those paths on binary [VERSION]. The marketing website does not include [FEATURE].

If a specific screen still looks web-only, it is [CONTENT_VIEW]; chrome and [CORE_JOB] are native. Happy to point to a hidden gesture / debug screen if useful: [HOW].

[NAME]

3. 4.3 — not a clone of another product

Hello App Review,

Thank you for the Guideline 4.3 feedback on [APP_NAME].

This app’s job is [ONE_SENTENCE], for [AUDIENCE]. It is not a duplicate of [INCUMBENT_OR_TEMPLATE]. On first launch the reviewer can see:

1. [UNIQUE_WORKFLOW]
2. [UNIQUE_DATA_SOURCE]
3. [UI that is not a color-swap of our other listings / of a public starter]

Name, screenshots, and the binary now show this job only. We are not arguing that category similarity is enough; we are showing a different product. Screenshots attached.

[NAME]

4. 4.3 — not spam from a multi-app account

Hello App Review,

Thank you for the 4.3 spam note.

[APP_NAME] is the only listing we intend for [JOB]. Our other apps (if any) serve [OTHER_JOBS] with separate binaries, data, and UI. This submission is not a keyword variant of those apps.

Differentiation visible in this binary:
- [BUNDLE_ID / name]
- [FIRST_RUN]
- [FEATURE unique to this listing]

We removed shared template assets and aligned metadata so the apps cannot be mistaken for a farm. Please review [VERSION].

[NAME]

5. Metadata (2.3.x) — listing now matches the binary

Hello App Review,

Thank you for the metadata feedback.

We corrected the listing for [APP_NAME] so it matches binary [VERSION]:
- Replaced website / mockup screenshots with device captures of [SCREENS]
- Rewrote the description to remove [PLACEHOLDERS / UNSUPPORTED CLAIMS]
- Matched IAP / support URL / privacy policy to what the app actually does

We will not ship aspirational screenshots. Please review the updated metadata and build.

[NAME]

6. Privacy (5.1.1) — labels, policy, and binary aligned

Hello App Review,

Thank you for the privacy / 5.1.1 feedback.

We aligned three things: the binary, App Privacy answers, and [POLICY_URL].
- Collected data: [CATEGORIES] for [PURPOSE]
- WebView third parties: [REMOVED or DISCLOSED]
- Permission strings: [KEYS] used only for [FEATURES]
- Account deletion: [PATH] if accounts exist

Please review the resubmitted build and labels. We are not providing App Store Connect access.

[NAME]