App provides genuine utility and is not too simple to justify a standalone app

Apple guideline 4.2 (Minimum Functionality) and Google Play's Spam policy exist specifically to block thin WebView wrappers masquerading as native apps. A single-screen app that renders an external URL full-screen provides no offline capability, no native hardware integration, and no experience a mobile browser cannot already deliver — reviewers are trained to spot this pattern and reject on first pass. Beyond the immediate rejection, an app that clears this bar only by the thinnest margin faces re-rejection on future updates whenever guidelines tighten.

Add at least one native capability that a mobile browser cannot replicate, then build a minimum of three distinct functional screens around it. The fastest defensible path is AsyncStorage-backed offline caching plus push notifications — both are available in Expo without additional entitlements.

// app.json — enable push notifications
{
  "expo": {
    "plugins": [
      ["expo-notifications", { "sounds": ["notification.wav"] }]
    ]
  }
}

If the app's primary value is web content, build a PWA instead — lower maintenance burden, no policy risk.

• ID: app-store-policy-compliance.app-quality.genuine-utility

• Severity: critical

• What to look for: Count the number of distinct, functional screens in the navigator. Look for: apps with a single screen containing only a WebView wrapping an existing website with no native augmentation; apps whose entire functionality is a single static information page that could be a website; apps that render an external URL full-screen with no offline capability or native features; apps with fewer than 3 distinct, functional screens. Check package.json for ANY native feature usage (camera, location, push notifications, local storage, auth) — even one native feature meaningfully above a website makes an app defensible. Also look at the interaction model: does the app use device hardware (camera, accelerometer, biometrics), local-first data, or a native UI paradigm that a mobile browser cannot replicate? In Expo apps, check if expo-modules-core or any expo-* sensor/device package is present — a positive signal. Apple guideline 4.2 ("Minimum Functionality") and Google Play policy require apps to do more than a mobile website.

• Pass criteria: The app has at least 3 functional screens and uses at least one native capability (device hardware, native notifications, biometric auth, local-first offline storage, or a native UI paradigm beyond simple web rendering). A partial or placeholder implementation does not count as pass. Report the count even on pass.

• Fail criteria: App is a thin WebView wrapper around an existing website with no meaningful native augmentation; app has a single screen with only a web URL rendered full-screen; app has fewer than 3 functional screens and uses no native features.

• Skip (N/A) when: Never — all apps must provide genuine utility.

• Detail on fail: Cite the specific pattern. Example: "App is a single-screen WebView rendering https://example.com with no native features — no local storage, no device hardware, no push notifications" or "App has 2 screens: a login screen and a single WebView — no distinct native functionality"

• Remediation: Apple guideline 4.2 and Google Play's Spam policy reject apps with insufficient utility.

  1. Add at least one native feature that provides value a mobile website cannot: offline caching with AsyncStorage/SQLite, push notifications, camera, biometrics, local-first data
  2. Build at least 3 distinct screens with purposeful, separate functionality
  3. If the app's primary value is content, ensure the content is cached and accessible offline — this alone differentiates it from a website
  4. If the app is genuinely a web content companion, consider building a Progressive Web App (PWA) instead of a native app — fewer policy risks and lower maintenance burden

  Review the configuration in src/ or app/ directory for implementation patterns.