Part I. Apple App Store (iOS) Technical Compliance

1. Privacy Labels

• App Store privacy labels must accurately map all collection categories, purpose classes, and third-party sharing scenarios.
• Where data is associated to user/account context, corresponding linkage categories must be declared truthfully.
• Policy documentation and store declarations must remain consistent. Mismatches may trigger rejection or delisting risks.

2. ATT Enforcement (2026 Upgraded Expectations)

• Before any IDFA-access path, call requestTrackingAuthorization and honor user choice.
• If tracking is denied, propagate allow_tracking=false (or equivalent) to all relevant SDKs and ad layers.
• No ATT bypass through alternative persistent identifiers, hidden device fingerprint reconstruction, or obfuscated tracking code.
• For iOS 18 adaptation, follow platform prompt frequency constraints and avoid repeated coercive authorization prompts.

3. Other iOS Compliance Controls

• No hidden features, review bypass code paths, or deceptive purchase entry points.
• Sensitive permission access (photos, contacts, etc.) must be explicit, purpose-bound, and user-controllable.
• Subscription metadata (price, period, renewal logic) must be transparent and non-misleading.
• If AI-generated content is included, disclosure should also align with store listing clarity requirements.

Part II. Google Play (Android) Technical Compliance

1. Data Safety Form

• Google Play data safety declarations must accurately describe collection, sharing, encryption in transit, and storage protection controls.
• False or incomplete declarations can trigger rejection, removal, or enforcement actions.

2. SDK Transparency and Responsibility (2026 Upgrade)

• Developers remain responsible for all integrated third-party SDK behavior and downstream data implications.
• SDK inventory should remain current, documented, and compatible with modern privacy sandbox requirements where applicable.
• Deprecated, non-compliant, or over-privileged SDK modules should be replaced or removed promptly.
• For Android 15 adaptation, avoid irrelevant permission requests and implement privacy-sensitive rendering safeguards where required.

3. Other Android Compliance Controls

• Support secure behavior for OTP/masked sensitive data views in recording or sharing contexts when platform APIs support this control.
• No malicious payloads, no forced-ad click behavior, and no policy-violating ad placements.
• 64-bit support should be maintained in line with store requirements.
• Subscription services must offer clear in-app management and cancellation discoverability.

Part III. 2026 Data Residency and Sovereignty Execution

• When region-specific law imposes localization obligations, store applicable user data in compliant in-region infrastructure.
• Cross-border transfer requires lawful basis and mechanism (adequacy, SCC-equivalent contracts, assessments, approvals, or local alternatives).
• Maintain a residency compliance ledger: storage location, transfer path, legal basis, purpose, retention, and processor map.
• Re-validate residency strategies against emerging requirements in active regions, including newly tightened sovereignty regimes.

Part IV. Interaction Design Compliance Enhancements

• Dual confirmation is required for high-value purchases (recommended threshold equivalent to USD/EUR 50 or above).
• Auto-renew subscriptions should include second-step confirmation with period, price, and renewal terms.
• Privacy policy entry points must be available in store listing, launch/login experience, and in-app settings/about pages.
• Permission dialogs must disclose purpose and allow refusal without deceptive pressure patterns.
• Rewarded-ad interactions should clearly state reward conditions and avoid coercive forcing.
• Complaint channels should support privacy complaints, ad complaints, and UGC complaints with processing feedback windows.
• Where required, ad logic, recommendation logic, and simplified data-flow transparency should be made discoverable to users.

Part V. Compliance Risk Control and Periodic Audit

1. Risk Control Measures

• Establish a pre-launch compliance review process for code, SDKs, policy text, and UX compliance checkpoints.
• Assign policy-watch ownership for global privacy law changes, store policy updates, and system-version compliance impacts.
• Maintain third-party partner due diligence, contractual data duties, and rapid suspension procedures for violations.
• Build rights-request workflows for access, correction, deletion, and complaint handling with auditable logs.
• Apply encryption, access-control minimization, and periodic security assessment for leakage/tamper/loss risk reduction.
• Run recurring compliance training for engineering, operations, and support teams.

2. Required Review Cycle

• Perform a full legal and technical compliance review every 6 months.
• Review scope should include legal clauses, SDK/version fitness, ATT and privacy controls, data lifecycle mapping, anti-fraud strategy, and rights-request SLA performance.

Questions, feedback, complaint reporting, or governance communication can be sent to support@DeerCasual.com or zhaoxiaotang@DeerCasual.com.

Part VI. App Monetization Technical Checklist

• Rewarded-video completion verification and anti-loop abuse checks must be enabled before rewards are issued.
• Interstitial frequency controls and app-open placement safeguards should prevent disruptive or deceptive user flows.
• Banner rendering should respect policy-safe placement and avoid accidental-click design patterns.
• IAP receipt validation must be server-verified or equivalent secure verification path where architecture requires.

Part VII. Logging, Evidence, and Forensic Readiness

• Maintain immutable audit traces for sensitive admin operations and fraud-rule decisions where feasible.
• Store incident evidence with integrity controls for post-incident analysis and dispute handling.
• Log retention windows should align with legal obligations and minimization principles.

Part VIII. Version Governance and Continuous Improvement

• Each major app release should include a compliance delta review and sign-off checkpoint.
• Policy and SDK changes should trigger fast-track impact assessments and corrective release planning.
• Conduct recurring post-release audits to verify technical controls remain effective in production traffic.