# 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.
2. **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.
3. **4.2 plus 4.3 (spam / similar).**  
   Treat uniqueness separately. Native chrome on a template clone still looks like spam.
4. **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:

```text
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.