Technical Compliance Guide

1. Scope

This Technical Compliance Guide is mandatory reading for any engineer, designer, product manager, or partner who ships a build under the primecodevaultlink publisher account. It defines the technical execution standards that ensure full compliance with the Apple App Store 2026 review guidelines, Google Play 2026 policies, the EU Digital Services Act (DSA), the EU AI Act, and regional data-residency rules.

Failure to comply with this Guide may result in app rejection, removal from the store, account suspension, or regulatory enforcement. Material deviation must be documented in writing and approved by primecodevaultlink's compliance lead.

2. Apple App Store (iOS / iPadOS) 2026 Requirements

2.1 Privacy Labels (App Privacy Section)

Every App published by primecodevaultlink must declare its privacy practices accurately in App Store Connect under "App Privacy". In particular, since IDFA, purchase records, and similar signals are linked to the user:

• The box "Data Linked to User" must be checked for any data category that is associated with the user, the device, or the account.
• The data categories (Contact Info, Financial Info, Health & Fitness, Identifiers, Usage Data & Diagnostics, etc.) must be completed exhaustively.
• Each declared purpose must match the actual SDK usage. Misdeclaration is grounds for rejection and removal.

2.2 ATT (App Tracking Transparency) 2026 — Mandatory Execution

Per Apple's 2026 App Tracking Transparency framework:

• Before any access to the device's device_id (i.e. IDFA), the App must call requestTrackingAuthorization and present the system ATT prompt. The prompt text must clearly explain the purpose of the request (e.g. "to personalise the ads you see and to measure their effectiveness"). Misleading copy is grounds for rejection.
• If the user denies tracking authorisation, the App must pass allow_tracking = false to every third-party SDK that participates in the bid stream. The App must not use any other device identifier (e.g. MAC address, randomised fingerprint) as an IDFA substitute to circumvent the user's choice.
• Per iOS 18, the ATT prompt may be shown at most once per app lifetime. Re-prompting the user is prohibited. If the user denies, the App must not re-request; the user can re-enable only through the device's system settings.
• The App must not implement any "soft prompt" or pre-prompt flow that conditions the user to tap "Allow". Such flows are explicitly prohibited by Apple.

2.3 iOS 18 — Sensitive Data Access

For each sensitive iOS API (PhotoKit, Contacts, Calendar, Microphone, Camera, Location, HealthKit, Motion, etc.):

• Request authorisation only when the feature is actually invoked (no up-front mass request).
• Per-use authorisation is preferred where the API supports it (e.g. PhotoKit limited-library access).
• Display a custom in-app rationale before invoking requestAccess, describing why the permission is needed and what will happen if it is denied.
• Never default-enable a permission via a misleading toggle or hidden switch.

2.4 IAP & Subscription Display

• All IAP items must display their price, billing period (for subscriptions), and renewal terms clearly. The display must use the system localisation for currency.
• No "dark patterns" — no pre-checked auto-renew opt-in, no obscured unsubscribe flow, no countdown pressure that is not grounded in a real deadline.
• Where a free trial is offered, the trial length, the post-trial price, and the renewal cycle must be displayed in the same view as the "Subscribe" button.
• Where the App uses StoreKit 2, the App must implement Product.PurchaseResult correctly and never assume a successful purchase without a verified transaction in Transaction.currentEntitlements.

2.5 Other Apple Requirements

• The App must not contain hidden features, undocumented code paths, or stealth SDK calls.
• The App must not bypass App Store review (e.g. by changing feature behaviour after review).
• AI-generated content (if any) must be labelled per Apple's guidelines and disclosed on the product page.
• App must support 64-bit, must declare its privacy manifest, must list its required reason APIs in the privacy manifest, and must support iOS 18 by the 2026 deadline.

3. Google Play (Android) 2026 Requirements

3.1 Data Safety Form

Every App must accurately complete the Google Play Console "Data Safety" form. In particular:

• Data in transit must be declared as encrypted (HTTPS / TLS 1.3).
• Data at rest must be declared as encrypted (AES-256).
• All data categories collected, all purposes, and all third-party SDKs that receive data must be declared.
• Misdeclaration is grounds for rejection or removal.

3.2 SDK Transparency & Privacy Sandbox (2026)

Per Google Play's 2026 SDK transparency requirements:

• Developers are fully responsible for the behaviour of every third-party SDK embedded in the App. We only use SDK versions that support Android 14+ Privacy Sandbox.
• The list of integrated third-party SDKs must be published in the Play Console, with name, purpose, and data-collection scope per SDK.
• If any SDK is found to be in violation of Google's policies, the SDK is removed immediately and the App is rebuilt without it.
• Where a SDK requests a permission unrelated to its declared purpose, the SDK is rejected during code review.

3.3 Android 15 — Privacy Sandbox & Private Space

• The App must support the Android 15 Privacy Sandbox: Topics API for cohort-based ad relevance, Protected App Signals for app-defined signals, and Attribution Reporting for ad measurement.
• Where a user installs the App in Private Space (a sandboxed profile for sensitive apps), the App must declare the appropriate behaviour. Medical, financial, and identity-sensitive apps must explicitly tell the user not to install in Private Space. Launcher apps must declare related permissions and adapt to Private Space app visibility rules.
• The App must support the Android 15 OTP hiding feature: any OTP field displayed while screen sharing / casting is automatically hidden, with a status-bar indicator visible to the user.
• The App must support the Android 15 partial screenshot / partial screen share flow and adapt sensitive UI accordingly.

3.4 Google Play Billing 2026

• All IAP must use Google Play Billing 7.0+ (or the current major version as required by Google). Third-party payment methods are not permitted for digital goods.
• Subscription terms must be visible before purchase. The user must be able to manage the subscription from the App and from Google Play Subscriptions.
• The App must implement AcknowledgePurchase for all non-consumable purchases within the required window (3 days). Unacknowledged purchases are refunded automatically.

3.5 64-bit & SDK Hygiene

• App must ship 64-bit (arm64-v8a, x86_64). 32-bit-only is no longer accepted on Google Play.
• All embedded SDKs must be on the latest stable version with no known security advisories.
• The App must not bundle ad SDKs that do not respect the Google Play Ads policy (e.g. full-screen interstitials immediately on app launch, accidental clicks, etc.).

4. 2026 Data Residency & Sovereignty

With global data-sovereignty expectations rising sharply in 2026, the following rules apply to any data we store, process, or transfer on behalf of our users.

4.1 Localisation Threshold

Where an App has a significant user base in a country / region with a data-localisation law (including the EU, UK, China, India, Saudi Arabia, Brazil, Canada, Russia, Indonesia, Nigeria, Turkey, and any country that has enacted a new localisation law since 2024), the relevant user data is stored on servers within that jurisdiction. The threshold follows the local law; where no threshold is defined, the default is 10,000 active monthly users.

4.2 Cross-Border Transfer — Required Approvals

4.3 U.S. Cloud Act Considerations

Where an App serves U.S. users and the U.S. Cloud Act may apply, we cooperate with lawful U.S. government data-access requests. We challenge over-broad requests through judicial process where appropriate. Users are notified of any government request to the extent permitted by law.

4.4 2026 New-Requirement Watchlist

Several jurisdictions enacted or amended data-localisation rules effective 2026. We track and adapt to:

• Canada: Quebec Law 25 enforcement — biometric and sensitive-data protections.
• Japan: APPI 2022 amendment — expanded extraterritorial scope and breach notification.
• Bolivia, Colombia, Chile: emerging data-protection regimes.
• Indonesia, Nigeria, Turkey: data-localisation rules for digital-payment and certain e-commerce flows.
• U.S. state-level laws: 14 states with comprehensive privacy laws now in force as of 2026.

4.5 Internal Data-Residency Ledger

We maintain an internal data-residency ledger that records, for each user record: the storage region, the data controller, the data processor, the legal basis for any cross-border transfer, and the date of last verification. The ledger is reviewed quarterly and audited annually by an independent third party.

5. Interaction-Design Compliance

5.1 Double-Confirmation for Large IAP

For any IAP purchase with a single-transaction value at or above USD / EUR 50 (or the regional equivalent), the App must present an in-app second confirmation modal before launching the platform payment sheet. The modal must state:

• The exact amount to be charged.
• The product or subscription being purchased.
• The payment method to be used.
• A clear "Confirm" CTA that the user must tap to proceed.

For auto-renewable subscriptions, a second confirmation is mandatory for all price tiers, stating the period, the price, and the renewal rule.

5.2 Privacy Policy Visibility (Mandatory Placement)

The link to this Privacy Policy must be present in at least three locations:

1. The App Store / Google Play product page (a clearly visible link in the description).
2. The App's first-launch screen (or login screen) — a clearly tappable link, with "Accept" / "Decline" buttons. A "Decline" must prevent the App from proceeding.
3. The App's "Settings" or "About" menu — a clearly tappable link that opens the full Privacy Policy in-app or in the browser.

5.3 Permission Requests

Each permission request must be preceded by a custom in-app rationale that explains the purpose, what happens if the user denies, and how to enable the permission later in system settings. Bulk permission requests at first launch are not permitted.

5.4 Ad-Format Disclosure

• Rewarded video: a clear "Watch the full ad to earn X" copy; a "Skip" button must appear after 5 seconds.
• Interstitial: a visible "Ad" badge; a close button visible from the start.
• Banner: a "Why this ad?" link is recommended.
• All personalised ads must be served only after explicit consent.

5.5 Complaint & Feedback Channel

The App must provide an in-app feedback channel for privacy complaints, ad complaints, UGC complaints, and general feedback. The complaint handling SLA is 7 business days, with a confirmation of receipt within 48 hours.

5.6 DSA Transparency Display

For any App with personalised ads or algorithmic recommendation, the App must display, in an easily discoverable location:

• The main parameters used for ad targeting.
• The user-facing logic of any recommendation system.
• A simplified diagram of the data flow.

5.7 Screen-Share Indicator (Android 15+)

Where the App runs on Android 15 or later, the system-managed screen-share indicator is honoured. The App may additionally display its own indicator for sensitive screens (e.g. payment, login, personal data).

6. SDK Inventory & Transparency

The full SDK inventory across the primecodevaultlink app matrix is listed below. Each SDK is on a signed Data Processing Agreement, has a current compliance audit, and is on a supported version.

6.1 Ad Mediation SDKs

6.2 Attribution / MMP SDKs

6.3 Payment SDKs

6.4 Consent / CMP SDKs

7. Risk Control & Periodic Review

7.1 Risk Control Measures

• Pre-release compliance review: every build, before submission, is reviewed by primecodevaultlink's compliance lead against this Guide, the App Store Review Guidelines, the Google Play Developer Policy, the DSA, and any region-specific regulations applicable to the App's target markets.
• Compliance training: engineering, design, ops, and support staff receive a quarterly compliance briefing covering changes in regional law, App Store / Google Play policy updates, and any new SDK restrictions.
• Partner audit: each third-party SDK and ad platform is reviewed quarterly. Any partner found in violation is replaced.
• User-request handling: data-subject, refund, and ad-complaint requests are tracked in a dedicated ticketing queue with strict SLAs and full audit trail.
• Security testing: encrypted storage, encrypted transit, biometric gate, role-based access, third-party penetration test annually, internal pen-test quarterly.

7.2 Periodic Review Schedule

Because the global legal environment — especially U.S. state privacy laws, the EU DSA implementing acts, the EU AI Act delegated acts, the India DPDP Rules, the China PIPL implementing rules, and the Saudi NDPA regulations — is in constant flux, and because Apple and Google update their platform policies at least twice a year, we conduct a formal review of this Guide every 6 months. The next scheduled review is Q4 2026.

7.3 Out-of-Cycle Triggers

An out-of-cycle review is triggered by any of the following events:

• A material change in the Apple App Store Review Guidelines or Google Play Developer Policy.
• A new regional privacy or data-localisation law taking effect.
• A regulator's enforcement action against any primecodevaultlink App.
• A change to the data-handling behaviour of any integrated third-party SDK or ad platform.
• A material change in the threat landscape (e.g. a new class of IAA fraud or IAP chargeback fraud).

8. Contact

For any question related to this Guide, please contact:

• Compliance Lead — compliance@primecodevaultlink.com
• Data Protection Officer — privacy@primecodevaultlink.com
• Security Disclosure — security@primecodevaultlink.com
• Postal address — St John's Innovation Centre, Cambridge, United Kingdom