Technical Compliance Guide

1. Purpose & Scope

This guide applies to every Application published by devflowbytegrid.com on the Apple App Store, the Google Play Store, and any future distribution channel. It also applies to:

• All third-party SDKs integrated into our Applications (advertising, attribution, payment, analytics, crash reporting, AI inference);
• All CI / CD pipelines that build, sign and ship our binaries;
• All vendor and contractor engagements that touch our codebase, infrastructure or distribution metadata.

Non-compliance with this guide is treated as a release-blocker. Each Application build is gated by automated checks against the rules in this document.

2. Apple App Store (iOS 18)

2.1 Privacy Labels (App Store Connect)

Every Application must accurately complete the App Store Connect Privacy Labels. Because device identifiers, purchase records and behavioural telemetry are linked to user profiles, we mark "Data Linked to User" accurately and never misrepresent the linkage.

• The data-collection scope, purpose and third-party sharing fields must exactly match the latest version of our Privacy Policy;
• Any change in data handling requires updating Privacy Labels in the same release cycle;
• Submitting false or misleading Privacy Labels is grounds for App Review rejection and store removal.

2.2 App Tracking Transparency (ATT) — iOS 14.5+ enforcement, including iOS 18 updates

The ATT framework is enforced as follows across every Application:

1. The requestTrackingAuthorization() API is called before any IDFA is read, used or transmitted;
2. The consent prompt copy clearly states the purpose of the request (e.g. "Allow devflowbytegrid to show you personalised advertising. You can change this anytime in Settings.");
3. If the user denies (ATTrackingManager.AuthorizationStatus.denied), allow_tracking = false is propagated to every third-party SDK that consumes IDFA;
4. No covert means of recovering IDFA (such as fingerprinting MAC address, IMEI, system clock offset, or any other device parameter as a stand-in for IDFA) are used;
5. Per Apple's iOS 18 enforcement: the ATT prompt is shown at most once per app installation. Subsequent prompts are not shown; users are directed to system Settings;
6. We do not gate any non-personalised functionality behind the ATT prompt. Denying tracking must not impair the core user experience.

2.3 iOS 18 additional technical requirements

• Apps must not contain hidden features or covert code paths designed to evade App Review (for example, hidden payment entry, falsified feature descriptions);
• Sensitive-data access (Photos, Contacts, Calendar, Microphone, Camera, Motion, Local Network, Bluetooth) is gated by per-use prompts with a clear purpose string. Default authorisation is never granted;
• In-app purchase items clearly display price, currency, subscription period and renewal cadence. Dark-pattern paywalls are prohibited;
• Apps that include AI-generated content must declare this on the App Store detail page and comply with Apple's emerging AI compliance expectations;
• All Applications support the latest iOS 18 privacy manifest format and declare Required Reason API usage for every flagged API.

3. Google Play (Android 14 / Android 15)

3.1 Data Safety Form

Every Application must accurately complete the Google Play Data Safety form. Specifically:

• Declare that data in transit is protected by HTTPS (TLS 1.3 minimum);
• Declare that data at rest is protected by AES-256;
• Data-collection scope, purpose and third-party sharing fields must exactly match the latest version of our Privacy Policy;
• Submitting false or misleading declarations is grounds for Play Store rejection and store removal.

3.2 SDK Transparency & Privacy Sandbox (2026 requirements)

Google requires developers to take full responsibility for the behaviour of the third-party SDKs they integrate. The following rules apply:

• Every integrated SDK must support the latest Android 14+ Privacy Sandbox APIs (Topics API, Protected Audience API, Attribution Reporting API). SDKs that are out of date or unsupported must be upgraded or removed before release;
• An up-to-date SDK manifest is published in the Google Play Console, including SDK name, version, vendor, purpose and declared data-collection scope;
• Each release audits each SDK's manifest against actual runtime behaviour (using Firebase App Check and automated privacy compliance scans). SDKs that violate the manifest must be removed;
• SDKs must not request permissions unrelated to their function (e.g. an ad SDK requesting location permission);
• Applications must support Android 15's Private Space feature: medical-category apps must warn the user not to install inside Private Space; launcher-category apps must declare required permissions and adapt their behaviour accordingly.

3.3 Android 15 additional technical requirements

• Support the Android 15 OTP-hiding API: in screen-share and screen-record scenarios, OTP fields are hidden by default and can be manually toggled by the user;
• Display a prominent "Screen sharing active" notification whenever the screen is being cast, recorded or shared with another device, in accordance with Android 15's screen-share notification requirement;
• Apps must not contain malicious code or covert advertising plug-ins. Forced push advertising, deceptive install flows, and ad-stacking are prohibited under Google Play's ad policy;
• Apps must support 64-bit architecture. 32-bit-only releases are no longer accepted;
• Apps containing subscriptions must surface a clear subscription-management entry, support in-app cancellation, and comply with Google Play's subscription policy.

4. 2026 Data Residency Compliance

With the global rise in data sovereignty, every Application must comply with the following residency rules:

4.1 Local storage thresholds

Where an Application has a significant user base in any of the following jurisdictions (the thresholds being defined by the applicable local law), user data must be stored on servers physically located within that jurisdiction:

4.2 Cross-border transfer mechanisms

• EU / UK → third countries: European Commission Standard Contractual Clauses (SCCs, 2021 modules) + UK International Data Transfer Addendum + Transfer Impact Assessment (TIA);
• US: Compliance with the Executive Order 14086 / EU-US Data Privacy Framework where applicable;
• China outbound: CAC Security Assessment, Standard Contract or Certification as required by the Cross-border Data Flow Provisions (effective 2024, updated 2026);
• India outbound: DPDP Act Section 16 governmental approval, or to jurisdictions on the central government's negative-list exemption;
• Brazil outbound: ANPD authorisation or standard contractual clauses;
• Other regions: Contractual safeguards + supplementary technical measures (pseudonymisation, encryption).

4.3 Residency compliance register

We maintain a Data Residency Compliance Register recording, for every Application: the storage location of every category of user data; the legal basis for any cross-border transfer; the date of the last residency audit; the responsible compliance owner. The register is reviewed quarterly.

5. Interaction Design Compliance

5.1 Double-confirmation mechanism

To prevent accidental high-value purchases and to comply with App Store / Play Store guidance on user protection:

• For any in-app purchase of 50 USD / EUR / GBP equivalent or more per single transaction, the Application must display an additional in-app second-confirmation dialog before handing off to the platform payment sheet. The dialog must clearly state the purchase amount, item name and payment method, and require an explicit "Confirm purchase" tap;
• For auto-renewing subscriptions, after the user taps "Subscribe", a confirmation dialog must appear stating the subscription period, price, renewal cadence, and direct cancellation path;
• For account deletion, a typed-confirmation or held-button mechanism is required to prevent accidental loss of data.

5.2 Privacy Policy discoverability (mandatory)

The Privacy Policy link must exist in all three of the following locations simultaneously, in compliance with global regulations:

1. App Store detail page (Apple App Store / Google Play description) — prominently placed;
2. App launch / splash screen — the user can tap the link to view the full policy. The splash screen offers "Agree" and "Decline" buttons. If the user declines, the Application cannot be used;
3. In-app "Settings" or "About" — the link is placed prominently and remains accessible at all times.

5.3 Permission requests

• Every permission request (Camera, Photos, Microphone, Location, Contacts, Calendar, Motion, Bluetooth, Local Network, Tracking) must be preceded by an in-app contextual explanation of why the permission is needed;
• Default authorisation is never granted;
• Users may revoke any permission at any time via the in-app or system settings.

5.4 Ad interaction

• Rewarded video ads are clearly labelled "Watch the full ad to earn a reward";
• A visible "Skip" or close button is provided no later than 5 seconds into the ad. Ads are never truly unskippable;
• Frequency capping is enforced at the platform level (mediation SDK configuration).

5.5 Complaint & feedback channels

• The Application surfaces easy-to-find complaint channels for privacy complaints, ad complaints, UGC complaints, and general feedback;
• Response time is no more than 7 working days;
• Resolution outcome is communicated to the complainant.

5.6 DSA transparency display

Where the Application falls within DSA scope, the Application surfaces in a prominent, non-buried location: (i) ad-placement rules; (ii) the main parameters of any recommender system; (iii) the data-processing flow (simplified).

5.7 Screen-share protection (Android 15+)

In line with Android 15 expectations, when the screen is being cast, recorded or shared, the Application displays a prominent "Screen sharing active" label in the status bar. Tapping the label opens a quick action to stop sharing.

6. Compliance Risk Prevention & Audit

6.1 Compliance review pipeline

• Pre-build: CI checks lint the source tree for forbidden API patterns (e.g. raw MAC address access, NSUserTrackingUsageDescription absence, raw location collection without declaration);
• Pre-submit: Manual privacy label / data safety form reconciliation, ATT prompt flow screenshot review, app-ads.txt presence check, manifest verification;
• Post-release: Quarterly automated SDK behaviour audit using App Privacy Report (iOS) and Android Privacy Sandbox reports.

6.2 Regulatory knowledge management

A dedicated compliance team monitors global privacy and store-policy updates (US state-level laws, EU DSA enforcement, Android Privacy Sandbox milestones, App Store Review Guidelines revisions). Each material change triggers a guideline refresh and a re-audit of in-flight releases.

6.3 Third-party partner management

• NDAs, DPAs and compliance questionnaires are mandatory for every vendor with access to user data;
• Vendor compliance is audited annually. Findings trigger remediation plans with deadlines. Severe or persistent violations result in termination;
• Sub-processor lists are published in-app and updated within 30 days of any change.

6.4 User-request handling

• A dedicated user-request workflow processes access, correction, deletion, portability and complaint requests within the time limits defined by the user's jurisdiction;
• Each request is logged end-to-end, with immutable audit records retained per GDPR Art. 30 and equivalent local record-keeping rules;
• Process metrics (response time, resolution rate) are reviewed monthly.

6.5 Security safeguards

• All Application code is scanned by static analysis (SAST), dynamic analysis (DAST) and software composition analysis (SCA) on every commit;
• Dependencies are pinned and rebuilt weekly;
• Annual third-party penetration test, continuous automated security testing;
• 72-hour breach-notification commitment to regulators (GDPR Art. 33) and to users where there is a likely high risk to their rights.

6.6 Staff training

All engineering, operations and customer-support staff receive mandatory privacy and compliance training on hire, and refreshers every six months. Completion is tracked and audited.

7. Periodic Review

Because the global legal environment (and store policy environment) is in continuous flux, we conduct a full review of this guide and of each Application's compliance posture every 6 months. Specific items in scope:

• Privacy Policy & Terms of Service wording vs. latest regulation;
• App behaviour vs. latest iOS / Android technical baselines (iOS 18, Android 15, Privacy Sandbox);
• Data flow residency vs. latest national residency requirements;
• Ad / IAP anti-fraud rules vs. latest observed fraud patterns;
• SDK inventory vs. latest SDK audit and version pinning policy;
• User request handling performance vs. SLA.

Material changes trigger a new release with updated Privacy Policy, updated Privacy Labels / Data Safety form and (where required) re-consent flows for existing users.

8. Contact

For any question, suggestion or report concerning this guide:

• Engineering compliance: compliance@devflowbytegrid.com
• Privacy & data requests: privacy@devflowbytegrid.com
• Security disclosure: security@devflowbytegrid.com
• Postal address: Engineering Compliance, devflowbytegrid.com, Warwick Software Industrial Park, Warwick, CV34, United Kingdom