App does not engage in deceptive behavior — does what it says, no fake system notifications

Apple guideline 5.6 and Google Play's Deceptive Behavior policy treat deception as grounds for permanent developer account termination, not just rejection. Fake virus or battery alerts (apps cannot access OS-level security state on iOS or Android), claims of phone-cleaning capabilities (impossible in a sandboxed app), and dark-pattern subscription cancellation flows (deliberate friction to prevent unsubscribing) are among the most scrutinized patterns in app review. Under OWASP A05 (Security Misconfiguration) and CWE-451 (UI Misrepresentation), dark patterns that obscure subscription terms also create legal exposure under FTC regulations and EU Digital Services Act enforcement.

Remove all fake system-level alerts and impossible capability claims from notification templates and UI copy. Subscription cancellation must be one tap with a direct confirmation:

// src/screens/Settings.tsx — compliant cancel flow
async function handleCancelSubscription() {
  const confirmed = await Alert.alert(
    'Cancel subscription?',
    'You will retain access until [date].',
    [{ text: 'Keep subscription' }, { text: 'Cancel', style: 'destructive' }]
  );
  if (confirmed) await cancelSubscription();
}

For feature flags (firebase/remote-config, LaunchDarkly), ensure they only gate UI variations that were visible during review. Flags that activate entirely new features after approval constitute a policy violation — all material functionality must be present and reviewable at submission time.

• ID: app-store-policy-compliance.content-restrictions.no-deceptive-behavior

• Severity: critical

• What to look for: Count all relevant instances and enumerate each. Examine the app for deception patterns across four dimensions: (1) Fake system notifications — Look for local notifications (expo-notifications, UNUserNotificationCenter, NotificationManager) that mimic OS system alerts: battery warnings, storage warnings, security alerts, virus/malware warnings, or "your account has been compromised" alerts that are not genuinely from the OS. Search for notification content templates in source files for these keywords: "virus", "malware", "infected", "security alert", "urgent" + "account", "battery low", "storage full" used in push notification bodies where the app has no actual authority to make these claims. (2) Misleading functionality — Does the app claim to do something it cannot technically do? Examples: "boosts phone speed" (apps cannot directly manage iOS/Android memory beyond their sandbox), "cleans junk files" (iOS apps cannot delete other apps' data), "improves WiFi signal" (apps cannot modify radio hardware). Search the app's description copy and any bundled marketing strings. (3) Dark patterns — Look for: deliberately confusing cancel flows in subscription screens; fake countdown timers that reset on reload; false scarcity messages ("Only 2 spots left!" for a digital product); fake social proof ("10,000 users joined today" hardcoded as a static string). (4) Hidden functionality — Search for remote feature flags that could enable functionality after store approval (firebase/remote-config, LaunchDarkly, Statsig). Determine whether these flags could activate materially different behavior. Apple guideline 5.6 and Google Play Deceptive Behavior policy apply.

• Pass criteria: The app's functionality matches its description. At least 1 implementation must be verified. No fake OS-level alerts. No claims of functionality the app is technically incapable of. No dark patterns in subscription or purchase flows. Feature flags control UI tweaks, not the activation of entirely different features not present during review.

• Fail criteria: Fake virus/security/battery alerts in notifications; claims of OS-level capabilities the app cannot perform; deliberate dark patterns in subscription cancellation; static hardcoded "social proof" numbers; feature flags that could toggle a fundamentally different app experience post-approval.

• Skip (N/A) when: Never — deception checks apply to all apps.

• Detail on fail: "Push notification template in src/notifications/alerts.ts contains 'URGENT: Your phone is infected with a virus' — the app has no virus detection capability" or "Subscription cancel flow in src/screens/Settings.tsx hides the cancel button behind 3 confirmation screens with misleading labels"

• Remediation: Deceptive behavior can result in permanent developer account termination, not just rejection.

  1. Remove all fake system-level alerts — you can only send notifications about events genuinely caused by your app
  2. Remove claims of functionality your app cannot perform on a sandboxed mobile OS
  3. Simplify subscription cancellation — one tap to cancel, no dark patterns, no confusing language
  4. If feature flags are present, ensure they only control UI variations that were visible during review, not activate entirely new features or change the app's core purpose

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