The 2026 Compliance Guide.

Overview & Purpose

This guide is the operational handbook used by TechPulseCodeZone engineers to ship compliant mobile products to the Apple App Store, Google Play Store, and global app markets. It combines the latest published App Store Review Guidelines, Google Play Developer Policy, the EU Digital Services Act (DSA), Apple Privacy Manifest requirements, Android 15 Privacy Sandbox changes, and 2026 regional data-sovereignty developments into a single, actionable reference.

The guide is structured for direct integration into your engineering process. Each section ends with concrete acceptance criteria — a feature is not "done" until the relevant checklist is satisfied and verified.

This guide is informational and is not legal advice. For specific legal questions, consult qualified counsel in the relevant jurisdiction.

Part 1 · Apple App Store (iOS 18 / iPadOS 18 / visionOS 2)

1.1 · Privacy Labels (App Store Connect)

Every app submitted to the App Store must complete the Privacy Labels questionnaire in App Store Connect. The following rules are non-negotiable:

• Data Linked to User. You MUST check "Data Linked to User" for any data that can be tied back to a specific user or device (including IDFA, purchase history, and device-derived identifiers). Failure to declare this linkage is grounds for rejection under App Store Guideline 5.1.1(iv).
• Accurate Data Categories. Every category of data collected must be declared accurately. The declared categories and purposes must match what the app actually does and what is described in the in-app Privacy Policy and this Privacy Policy.
• Purpose Disclosure. For each declared data category, the purpose (Analytics, Product Personalisation, App Functionality, Third-Party Advertising, etc.) must be selected from Apple's taxonomy.
• Updates Required. Privacy Labels must be updated within thirty (30) days of any material change in data practices. Submitting misleading Privacy Labels is treated as a Guideline 5.1.1(x) violation and can result in app removal.

1.2 · ATT Framework (App Tracking Transparency) — 2026 Enforcement

Under iOS 14.5 and later, every access to the IDFA requires an explicit user authorisation via the ATT prompt. The 2026 enforcement posture is strict:

• Single-Prompt Rule. The ATT prompt may be shown only once per app installation. A subsequent request after the user has declined is a Guideline 5.1.1(ii) violation. Do not design "reminder" flows that re-prompt the user after a decline.
• Authorisation Copy. The string presented to the user must clearly state the purpose of the authorisation. Generic or misleading copy is grounds for rejection. We use the following recommended copy: "Allow [App Name] to track your activity across other companies' apps and websites?" — this is Apple's recommended string and is required to be the system-default string unless a compelling UX case is made.
• Pre-Prompt Disclosure. Where your app shows a custom pre-prompt screen before the system ATT prompt (a common UX pattern), the pre-prompt must (a) not be designed to manipulate the user (no dark patterns, no countdowns, no misleading graphics); (b) clearly disclose what "tracking" means in the context of your app; (c) include an obvious "Ask App Not to Track" alternative. Pre-prompts that violate these rules are reviewed under Guideline 5.1.1(ix) and are rejected.
• Forbid IDFA Workarounds. Where the user declines ATT authorisation, you MUST transmit allow_tracking = false to every downstream SDK in your mediation stack. Do not derive a fingerprint from MAC address, device serial, or any other parameter as an IDFA substitute. This is enforced under Guideline 5.1.1(ix) and the Privacy Manifest enforcement that began in 2024.
• SKAdNetworkID Declaration. Where you use Apple's SKAdNetwork for conversion attribution, every SKAdNetworkID of every mediated ad network must be declared in your Info.plist. Apple maintains the canonical list at developer.apple.com/documentation/storekit/skadnetwork.

1.3 · Privacy Manifest (Required Reason API)

Apple's Privacy Manifest (PrivacyInfo.xcprivacy) is mandatory for every app submitted from May 2024 onwards. The 2026 enforcement tier requires:

• Every API Call Declared. Every use of a "Required Reason API" — including but not limited to UserDefaults (reason code CA92.1), fileTimestamp (C617.1), systemBootTime (35F9.1), diskSpace (85F4.1), activeKeyboard (54BD.1), and the iOS 18 additions — must be declared in your Privacy Manifest with a valid reason code from Apple's published taxonomy.
• Third-Party SDK Manifests. Every third-party SDK in your app must publish its own Privacy Manifest. As of 2026, the published list of SDKs requiring manifests includes all ad mediation SDKs, all analytics SDKs, all social SDKs, and many utility SDKs. If an SDK in your app does not publish a manifest, your app will be rejected.
• Tracking Domains Declaration. Any domain that the app communicates with for the purpose of "tracking" (as defined in the App Store Review Guidelines) must be declared under NSPrivacyTrackingDomains. False declarations are enforced.
• Validation Tooling. Run the Privacy Manifest validator (privacy-manifest validate) as part of your CI/CD pipeline. Failure of the validator must block the build.

1.4 · iOS 18 Platform Compliance

• No Hidden Functionality. Apps must not contain hidden features, undocumented switches, or code that behaves differently in App Review vs. production (Guideline 2.3.1).
• Privacy-by-Permission. Sensitive data access (photos, contacts, microphone, camera, calendar, location, motion, health, Face ID, Optic ID) requires per-prompt authorisation with clear purpose disclosure. Pre-granted or default-allow access is a Guideline 5.1.1(i) violation.
• In-App Purchase Disclosure. Every auto-renewable subscription, consumable, non-consumable, and non-renewing subscription must display price, period, and renewal terms in-app before purchase (Guideline 3.1.2).
• AI-Generated Content Labelling. Apps that include AI-generated content (text, image, audio, or other) must (a) label AI content appropriately; (b) not present AI content as factual information without qualification; (c) comply with Apple's emerging AI guidelines as published.
• visionOS 2 Specifics. visionOS apps must declare their spatial-comfort level, must support the system's "comfortable viewing distance" guidance, and must not force-passthrough for purely promotional content.

Part 2 · Google Play (Android 14+ / Android 15)

2.1 · Data Safety Form (Play Console)

The Google Play Data Safety form must be completed for every app and must accurately reflect the app's data practices. The 2026 requirements include:

• Encryption in Transit. You must declare that all data in transit is encrypted via TLS (HTTPS). Plaintext HTTP traffic is prohibited and the app will fail the security review.
• Encryption at Rest. You must declare that all user data at rest is encrypted. The minimum standard is AES-256 for file-level encryption or use of the Android Keystore / StrongBox for key material.
• Data Sharing Disclosure. For every category of user data shared with third parties (e.g., ad mediation partners, analytics providers), you must declare the recipient, the purpose, and whether the user can opt out.
• Data Collection Disclosure. Every category of data collected must be declared, with purpose, retention, and opt-out status.
• False Disclosure. Submitting a misleading Data Safety form is a violation of the User Data Policy and may result in app suspension or removal. Google conducts periodic audits.

2.2 · SDK Transparency (2026 Upgrade)

• SDK Disclosure Form. Google Play now requires a separate SDK Disclosure Form in addition to the Data Safety form. For every SDK integrated into your app, you must declare: SDK name, SDK version, purpose, data collected, data shared, retention behaviour.
• SDK Privacy Sandbox Compatibility. Every SDK you integrate MUST support the Android 15 Privacy Sandbox (Topics API, Protected Audience API, Attribution Reporting API). SDKs that do not yet support Privacy Sandbox must be either (a) updated to a compatible version, or (b) removed. This requirement is enforced for apps targeting Android 14+.
• SDK Permission Audit. Every SDK's manifest is reviewed by Google. SDKs that request permissions not justified by their declared purpose are flagged and may result in your app's rejection.
• Stale SDK Prohibition. SDKs that have not been updated in over 12 months, or that are known to have security vulnerabilities, are flagged in the Play Console and require either an update or removal.

2.3 · Android 15 Platform-Specific Compliance

• Private Space Support. Apps targeting Android 15 must respect the Private Space feature. For apps that may behave differently in Private Space (e.g., health apps that need a verified user), declare the behaviour clearly. Launcher apps must declare EXPAND_STATUS_BAR permission usage if applicable.
• Dynamic OTP Hiding. For apps that handle SMS or call OTPs (one-time passwords), the app MUST participate in Android 15's Dynamic OTP Hiding feature via the OTP_REDACTION capability. Failing to do so may result in negative reviews.
• Screen-Share Awareness. Apps handling sensitive data MUST detect screen-share / screen-recording and hide sensitive UI elements. Use the FLAG_SECURE window flag (within documented scope) or equivalent Jetpack Compose APIs.
• 64-bit Requirement. Apps must support 64-bit architectures (arm64-v8a, x86_64). 32-bit-only APKs are no longer accepted on Google Play for new submissions.
• Predictive Back Gesture. Apps must support Android 13+ predictive back gesture. Failing to do so will result in reduced store placement.

2.4 · Subscriptions & IAP

• Auto-renewing subscriptions must use the Play Billing Library v8 or later for new integrations. Legacy v5/v6 are deprecated.
• The Play Billing Library's subscription disclosure UI must be presented in full before purchase — period, price, trial terms, renewal mechanics, cancellation method.
• Account-hold and restoration flows must be implemented for graceful handling of payment failures.

Part 3 · 2026 Data Sovereignty & Cross-Border Transfer

2026 marks a step-change in data-sovereignty requirements across multiple jurisdictions. The following matrix summarises the current state of play. Where a regional requirement is in flux, we follow the most conservative published guidance.

3.1 · Localisation Matrix

3.2 · Cross-Border Transfer — Engineering Checklist

• For each data category collected, classify by jurisdiction of user and determine the applicable cross-border mechanism.
• For data of users in mainland China, Saudi Arabia, Russia, Indonesia, Nigeria, Bolivia, Colombia, Turkey, or Vietnam: local-residency mandatory — do not transfer outside the jurisdiction without an explicit local exception or government approval.
• For data of users in the EU/UK/Switzerland → US: use SCCs (2021/914) + Transfer Impact Assessment, or rely on the EU-US Data Privacy Framework where applicable.
• For data of users in Brazil → outside: use ANPD-approved SCCs.
• Maintain a data residency register (where each user-data store is located, what data, retention period).
• Quarterly review of new data-sovereignty laws; annual update of the cross-border transfer matrix.

Part 4 · Interaction Design Compliance Requirements

4.1 · Double-Confirmation Mechanism (IAP)

To prevent accidental purchases (and to comply with regional consumer-protection laws):

• For any IAP with a single-charge amount greater than or equal to USD/EUR 50 (or local-equivalent), an in-app double-confirmation modal is mandatory before the platform payment sheet is shown. The modal must state the purchase amount, the item name, the payment method, and require an explicit "Confirm Purchase" tap.
• For auto-renewing subscriptions, after the user taps "Subscribe", a second modal must display: the subscription period, the price, the renewal date, the trial (if any), and a clear "Confirm Subscription" / "Cancel" choice.
• The default button on the confirmation modal must NOT be the purchase action; the "Cancel" or close button must be the visually dominant and easily accessible option.

4.2 · Privacy Policy — Accessibility Mandate

Per App Store Guideline 5.1.1(vii), Play Store Developer Distribution Agreement, and DSA Article 24, the Privacy Policy URL must be present in all three of the following locations:

1. App Store / Play Store Detail Page. In a prominent, visible location within the store description or developer field. Not buried in screenshots.
2. First-Run / Splash Screen / Login Page. A clearly tappable link from the very first screen the user sees. A first-run consent screen with explicit "Agree" and "Decline" buttons must be shown; if the user declines, the app must not function.
3. In-App Settings / About Menu. A clearly tappable link in a prominent location within the in-app settings or about menu. The link must open the full Privacy Policy, not a summary.

4.3 · Permission Requests

• Every permission request (camera, photo library, microphone, location, motion, contacts, calendar, notifications) must be accompanied by an in-app explanation of the specific purpose of the request. Generic "Allow [App] to use this?" copy is not sufficient.
• Users must be able to decline any permission and continue using the app with that feature disabled.
• Users must be able to revoke any permission at any time via the in-app settings or the device system settings. The revocation must take effect immediately, without requiring app restart.
• Apps must not request all permissions on first launch. Request permissions only when the user accesses the corresponding feature.

4.4 · Ad Interaction Quality

• Every rewarded video ad must clearly disclose the reward before the user taps "Watch". The disclosure must include the reward amount and any conditions (e.g., "Watch the full video to receive 100 coins").
• Every rewarded video ad must be skippable after a maximum of 30 seconds. Ads shorter than 30 seconds must be skippable at the end of the ad.
• No ad may be displayed on a payment flow, during onboarding, or immediately after a payment.
• Banner ads must be displayed in designated, non-intrusive areas. No banner ad may overlap interactive UI elements.
• Interstitial ads must be frequency-capped at no more than one per minute and one per three content transitions.
• App open (splash) ads must be closable after no more than 5 seconds and must never be chained.

4.5 · Complaint & Feedback Channels

• An in-app "Help / Report a Problem" section must be present and easily accessible (within two taps from any screen).
• Channels must include: privacy complaints, ad complaints, content complaints, subscription / refund requests, and general support.
• Acknowledgement within twenty-four (24) hours. Substantive response within seven (7) calendar days.

4.6 · DSA Transparency Requirements (EU)

• Public display of advertising: every paid ad or promoted content displayed in-app must be clearly labelled as "Sponsored", "Ad", or equivalent.
• Algorithmic recommendation logic: any "For You", "Recommended for You", or personalised ranking surface must disclose its parameters and allow the user to view non-personalised alternatives.
• Data processing flow: a simplified, graphical data-flow diagram must be available within the in-app privacy section.
• Public statement of content-moderation policies, statistics, and appeal mechanism.

4.7 · Screen-Share Awareness (Android 15)

• When screen-share, screen-record, or cast is active, the app must display a prominent indicator in the status bar or app toolbar.
• The indicator must be tappable to quickly stop sharing.
• For apps handling sensitive data (financial, health, credentials), sensitive content must be auto-redacted during screen-share.

Part 5 · Compliance Risk Prevention & Periodic Audit

5.1 · Pre-Launch Compliance Audit

Before any app is submitted to the App Store or Play Store, a pre-launch compliance audit is conducted:

• Privacy Manifest validation passes.
• Data Safety form completion check.
• SDK inventory matches SDK transparency disclosure.
• All third-party SDKs are at a Privacy-Sandbox-compatible version.
• ATT prompt copy reviewed against Guideline 5.1.1.
• Subscription disclosure UI reviewed against Guideline 3.1.2 and Play Billing v8 best practice.
• Data residency rules verified for each target jurisdiction.
• Privacy Policy URL present in all three mandatory locations.
• Double-confirmation modal implemented for all IAPs ≥ USD/EUR 50.
• Ad format compliance: skippability, frequency caps, disclosure.
• AI-generated content labelling in place (if applicable).

5.2 · Ongoing Compliance Monitoring

• Subscription to Apple Developer News and Google Play Developer Blog.
• Subscription to regional privacy-regulator bulletins (ICO, CNIL, BfDI, ANPD, CAC, SDAIA, etc.).
• Quarterly review of app store policy changes.
• Quarterly review of regional privacy-law changes.
• Bi-annual third-party compliance audit.
• Annual penetration test and security audit.

5.3 · Six-Monthly Compliance Refresh

Because global privacy regulation and store policy are continuously evolving, every TechPulseCodeZone app is re-audited every six (6) months. The audit cycle covers:

• Review of Terms of Service and Privacy Policy against latest regulations.
• Review of code against latest OS requirements (Privacy Manifest, ATT, Privacy Sandbox).
• Review of data collection, storage, transmission, and sharing flows.
• Review of IAA / IAP fraud prevention rules.
• Review of content moderation policies and DSA transparency reports.
• Update of third-party partner compliance documentation.

5.4 · Compliance Risk Register

Each app maintains a Compliance Risk Register that lists identified risks, the likelihood × impact score, the mitigation in place, and the residual risk. The register is reviewed quarterly.

5.5 · Incident Response

• Documented incident-response plan with roles, escalation paths, and communication templates.
• Seventy-two (72) hour breach notification commitment to affected users and regulators, where required by law (GDPR Article 33, CCPA, etc.).
• Post-incident review and remediation tracking.

5.6 · Personnel Training

• Annual mandatory privacy and security training for all engineers, designers, and product managers.
• Ad-hoc briefings on regulatory changes that affect ongoing projects.
• Quarterly tabletop exercises on incident-response scenarios.

Part 6 · Contact

For questions about this guide, for consulting engagements to apply this framework to your own apps, or for partnership on compliance tooling, please contact us.

TechPulseCodeZone
University of Texas Innovation Center
Austin, Texas 78712, United States

General: contact@techpulsecodezone.com
Privacy / DPO: privacy@techpulsecodezone.com
Legal: legal@techpulsecodezone.com
Compliance: compliance@techpulsecodezone.com