iOS SDK Privacy Compliance — Code Review & Scope Validation

1. Project Overview We maintain an iOS SDK ("IOS-Listener SDK") that is embedded in third-party apps. This is an event tracking SDK based on a 2019 fork of Snowplow iOS codebase. Apps using our SDK are currently being rejected by Apple's App Store review process due to privacy and tracking violations in the SDK code. We have completed an internal audit and identified what we believe are the root causes of rejection. This engagement (Part A) is a paid code review to validate our findings, identify anything we may have missed, and produce a detailed scope of work for the remediation itself (Part B). 2. Objective of This Engagement (Part A) The contractor will: * Review the full SDK source code (Objective-C, CocoaPods-distributed). * Validate each issue listed in Section 4 below — confirm it is a real rejection risk, or flag it as not applicable. * Identify any additional App Store compliance issues not covered in our initial audit. * Produce a written deliverable (see Section 5) that becomes the basis the scope of work for Part B (implementation). 3. Contractor Requirements * Demonstrated experience shipping iOS apps or SDKs through App Store review. * Familiarity with Apple's current privacy requirements: App Tracking Transparency (ATT), Privacy Manifests (PrivacyInfo.xcprivacy), and App Store Review Guidelines §5.1. * Experience resolving App Store rejections related to privacy, tracking, or fingerprinting. * Comfortable reading Objective-C codebases. * Ability to clearly communicate findings in writing. 4. Issues Identified — To Be Validated by Contractor Below is our internal audit. For each item, the contractor should confirm whether it is a valid App Store rejection risk, update the description if needed, and note the recommended fix at a high level. 4.1 Device Fingerprinting Description: The SDK collects device model, OS version, screen resolution, language, carrier name, and device identifiers (IDFV/IDFA), bundles them into a "mobile context" JSON blob, and transmits them to our servers. Apple considers this combination of signals "device fingerprinting" and prohibits it. Files: SnowplowUtils.m → SnowplowTracker.m → SnowplowEmitter.m Destination: matheranalytics.com Contractor action: Confirm or update. Recommend which signals to remove vs. retain, and how to restructure the payload to avoid fingerprinting classification. 4.2 IDFA Access Without ATT Check Description: The SDK reads the advertising identifier (IDFA) without verifying ATT authorization status. It uses the deprecated isAdvertisingTrackingEnabled check (pre-iOS 14.5). As an SDK, we should never show the ATT prompt — but we must check ATT status before accessing IDFA. File: SnowplowUtils.m → getAppleIdfa method Contractor action: Confirm or update. Specify the correct ATT status check to implement and behavior when permission is not granted. 4.3 Missing Privacy Manifest (PrivacyInfo.xcprivacy) Description: Since May 2024, Apple requires every SDK to include a PrivacyInfo.xcprivacy file declaring collected data types, restricted API usage, and tracking domains. Our SDK has no such file. App Store Connect automatically rejects submissions that include SDKs using restricted APIs (e.g., NSUserDefaults, IDFA) without a privacy manifest. This is a hard block. File: Does not exist — must be created and added to the Pod. Contractor action: Confirm. Draft the required manifest entries based on the SDK's actual data collection after remediation. 4.4 Data Collection Without Consent Description: The moment a host app initializes MListener, the SDK immediately begins collecting device data and transmitting it. There is no consent check, opt-in flag, or delay. File: MListener.m → init: method → SnowplowTracker Contractor action: Confirm or update. Recommend the consent-gating pattern (e.g., explicit start method, configuration flag, deferred initialization). 4.5 Deprecated Carrier Name Collection (CTCarrier) Description: Uses CTCarrier API deprecated since iOS 16. Returns empty data on modern iPhones. Also contributes to the fingerprinting signal bundle. Contractor action: Confirm removal is appropriate. Flag if any replacement is needed or if it should simply be deleted. 4.6 Cross-App Shared Storage (App Group) Description: The SDK stores tracking data in a shared group.mather app group, allowing data to be read across different apps by the same vendor. Apple may flag this as a cross-app tracking mechanism. Contractor action: Confirm whether this is a rejection risk under current guidelines. Recommend whether to remove, scope down, or declare in the privacy manifest. 4.7 Cookie-Based Device ID Description: The SDK reads HTTP cookies from matheranalytics.com to persist a device identifier across sessions. This is restricted under modern iOS privacy controls (ITP, cookie partitioning). Contractor action: Confirm whether this triggers rejection or is simply non-functional. Recommend removal or replacement. 4.8 Deprecated System APIs Description: Two legacy Apple functions are still in use — CFURLCreateStringByAddingPercentEscapes (deprecated since iOS 9) and Gestalt() (1990s macOS-era API). Contractor action: Confirm these should be replaced. Note modern equivalents. 4.9 Other Issues (Contractor to Identify) The contractor should review the full codebase for any additional App Store compliance risks not listed above. This includes but is not limited to: undeclared API usage, missing entitlements, non-compliant networking patterns, or any other signals that could trigger automated or manual rejection. 5. Deliverables At the end of this engagement, the contractor will deliver: * Issue Validation Report * For each issue in Section 4: * Status: Confirmed / Updated / Not Applicable * Updated description (if changed) * Recommended fix * Severity: Blocking (will cause rejection) / High Risk / Low Risk / Cleanup * New Issues List — Any additional compliance risks found during review, with the same detail as above. * Part B Scope of Work Draft — A structured task list for the implementation phase, organized by priority, with estimated complexity (small / medium / large) for each task. This becomes the basis for the Part B contract. 6. What We Will Provide * Full SDK source code (private repository access or zip) * The internal audit document (included above as context) * Access to a team member for questions during the review 7. Timeline & Budget Estimated effort: 8 hours. Expected turnaround: 3–5 business days from code access. 8. How to Apply In your proposal, please include: * Relevant iOS SDK or app development experience, especially related to App Store privacy compliance. * Examples of resolving App Store rejections (if applicable). * Your availability and estimated turnaround time. * Hourly rate or fixed-price quote for Part A. * Whether you would also be interested in Part B (implementation), and a rough estimate if so. 9. Important Notes * This is Part A only. Part B (implementation) will be scoped based on the deliverables from this engagement. * The SDK is written in Objective-C and distributed via CocoaPods. * We are not looking for a rewrite — we need targeted, minimal changes that bring the SDK into compliance. * All work product becomes the property of Mather Economics. * An NDA will be required before code access is granted.