App provides genuine utility and is not too simple to justify a standalone app
Why it matters
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.
Severity rationale
Critical because a thin-wrapper app will be rejected outright on first review, wasting weeks of submission time and potentially triggering heightened scrutiny on subsequent submissions from the same developer account.
Remediation
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.
Detection
-
ID:
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
WebViewwrapping 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. Checkpackage.jsonfor 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 ifexpo-modules-coreor anyexpo-*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.
- 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
- Build at least 3 distinct screens with purposeful, separate functionality
- If the app's primary value is content, ensure the content is cached and accessible offline — this alone differentiates it from a website
- 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/orapp/directory for implementation patterns.
External references
- external · apple-guideline-4.2 — App Store Review Guidelines 4.2 — Minimum Functionality
- external · google-play-spam-policy — Google Play Developer Policy — Spam and Minimum Functionality
Taxons
History
- 2026-04-18·v1.0.0·Initial import from app-store-policy-compliance·automated