Optimizing Your iOS SDK for Safari's ITP & Tracking Prevention

Embrace First-Party ContextSafari's ITP heavily restricts third-party cookies. Design your iOS SDK to operate within a first-party context whenever possible, leveraging server-side solutions or direct integration.

Prioritize Privacy-Preserving IdentifiersMove away from persistent, cross-site identifiers. Focus on ephemeral or user-consented identifiers, respecting user privacy settings and Apple's App Tracking Transparency framework.

Implement Robust FallbacksAnticipate that some data points or tracking mechanisms might be blocked. Build your SDK with graceful degradation and fallback strategies to maintain core functionality even when ITP is active.

Stay Updated with Apple's PoliciesITP and privacy policies are dynamic. Regularly review Apple's developer documentation and privacy updates to ensure your SDK remains compliant and effective.

Safari's Intelligent Tracking Prevention (ITP) has fundamentally reshaped the landscape of web tracking, particularly for developers relying on third-party cookies and persistent identifiers. For iOS SDKs, this presents a unique set of challenges, especially when integrating with web views or handling cross-domain communication. Apple's continuous commitment to user privacy, reinforced by features like App Tracking Transparency (ATT) and stricter policies on data collection, means that SDK developers must proactively adapt their strategies to ensure functionality, maintain data integrity, and respect user consent.

This blog post delves into the intricacies of ITP and similar privacy mechanisms within Safari on iOS, offering actionable insights and practical examples to optimize your SDK. Our goal is to help you build resilient, privacy-preserving SDKs that not only function reliably but also foster user trust in an increasingly privacy-conscious digital world.

Understanding Safari's ITP and its Impact on iOS SDKs

Intelligent Tracking Prevention (ITP) is a set of privacy-enhancing technologies built into Safari (and WebKit). Its primary function is to limit cross-site tracking by restricting the use of cookies and other forms of website data by third parties. Over the years, ITP has evolved through several iterations, each introducing stricter controls:

• Blocking Third-Party Cookies: The most significant aspect. ITP aggressively partitions or blocks third-party cookies, making it difficult for advertisers and analytics providers to track users across different websites.
• Storage Access API: Introduced as a privacy-preserving way for embedded content to request access to its first-party storage when a user interacts with it.
• Link Decoration Protections: ITP can also remove tracking parameters from URLs to prevent tracking through link decoration.
• Referrer Policy: Safari often sends a more restrictive referrer policy (e.g., strict-origin-when-cross-origin), limiting the amount of information passed to third-party sites.
• Ephemeral Bounce Tracking Prevention: Identifies and mitigates techniques where trackers redirect users through their site to set first-party cookies.

For iOS SDKs, especially those that interact with web content (e.g., in-app browsers, authentication flows, payment gateways, or embedded analytics), ITP's impact can be profound. If your SDK relies on setting or reading cookies from a third-party domain within a WKWebView, or if it expects certain referrer information to be passed, ITP can break these mechanisms, leading to:

• Failed authentication or payment processes.
• Inaccurate attribution or analytics data.
• Broken user experiences due to missing state or session information.

Strategies for ITP-Proof iOS SDK Development

Adapting to ITP requires a shift in mindset from traditional tracking to privacy-centric data handling. Here are key strategies:

1. Prioritize First-Party Context and Server-Side Solutions

The most effective way to circumvent ITP's restrictions on third-party cookies is to operate within a first-party context. This means that the domain setting the cookie or accessing storage is the same as the domain the user is currently visiting.

Practical Example: Server-Side Tracking for Analytics

Instead of relying on a third-party analytics script embedded in your WKWebView that tries to set its own cookies, consider a server-side approach:

1. SDK Collects Data: Your iOS app (or the web content within your WKWebView) collects relevant user interaction data (e.g., product viewed, button clicked).
2. Send Data to Your Backend: This data is sent directly to your own backend server.
3. Backend Forwards to Analytics Provider: Your backend then forwards this data to your analytics provider's API. Since this communication happens server-to-server, it bypasses ITP restrictions on client-side cookies.

This approach gives you full control over the data, ensures it's sent reliably, and is not subject to browser-side tracking prevention.

2. Leverage the Storage Access API for Cross-Site Needs

When you absolutely need access to cross-site cookies within an embedded WKWebView (e.g., for single sign-on with an identity provider), the Storage Access API is the approved, privacy-preserving method. This API allows third-party content to request explicit permission from the user to access its first-party storage.

Practical Example: Seamless SSO in WKWebView

Imagine your SDK embeds a WKWebView for an authentication flow that needs to access cookies from your identity provider (IDP) to achieve SSO. Without the Storage Access API, Safari would block these cookies.

Client-side (within your embedded web content):

document.requestStorageAccess().then(function() {
    // Storage access granted, now you can make requests that use cookies
    // e.g., load the SSO iframe or make an XHR request to the IDP
}).catch(function() {
    // Storage access denied or user interaction required
    // Handle gracefully, maybe fall back to a full redirect login
});

iOS SDK (WKUIDelegate and WKNavigationDelegate):

You'll need to handle the user prompt that Safari presents. The WKUIDelegate method webView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler: (or similar permission requests) might be invoked, but for storage access, the prompt is usually handled by Safari itself. Ensure your WKWebViewConfiguration is set up correctly, particularly websiteDataStore.

3. Adopt Privacy-Preserving Identifiers and User Consent

With App Tracking Transparency (ATT), Apple requires explicit user consent for tracking across apps and websites owned by other companies. Your SDK should respect this. Move away from relying on persistent device identifiers for tracking purposes without consent.

Practical Example: Handling ATT and IDFA

If your SDK previously relied on the Identifier for Advertisers (IDFA) for attribution or targeting:

1. Request ATT Authorization: Use AppTrackingTransparency.framework to request user authorization before accessing IDFA.
2. Conditional IDFA Usage: Only retrieve and use IDFA if the user grants permission.
3. Alternative Identifiers: If denied, rely on context-specific, ephemeral identifiers (e.g., a session ID) or server-generated, non-persistent IDs that are not used for cross-site tracking.

Swift Example:

import AppTrackingTransparency
import AdSupport

func requestTrackingAuthorization() {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
                print("IDFA: \(idfa)")
                // Use IDFA for consented tracking
            case .denied, .notDetermined, .restricted:
                print("ATT authorization denied or not determined.")
                // Rely on other privacy-preserving methods
            @unknown default:
                break
            }
        }
    } else {
        // Fallback for iOS versions prior to 14
        // Check if tracking is enabled via ASIdentifierManager.shared().isAdvertisingTrackingEnabled
    }
}

How Didit Helps

Didit, as an all-in-one identity platform, inherently aligns with a privacy-first approach, making it robust against ITP and similar tracking prevention mechanisms. Our core focus is on verifying real humans securely, not on cross-site tracking. Didit's architecture is designed to handle identity verification, biometrics, fraud detection, and authentication within a single, controlled system, minimizing reliance on third-party tracking cookies. We achieve this by:

• First-Party Integration: Didit's SDKs and APIs are designed for direct, first-party integration into your application, ensuring that identity verification processes occur within your app's context, largely bypassing ITP concerns related to cross-site tracking.
• Server-Side Processing: Many of Didit's robust capabilities, such as AML screening and fraud signal analysis, operate server-to-server. This means sensitive data processing and identity checks happen securely on our backend, eliminating client-side tracking vulnerabilities.
• Ephemeral Biometrics: Didit processes biometric data in memory and deletes it, only returning boolean results to your application. This "privacy by design" approach means we don't store persistent biometric identifiers for tracking, aligning perfectly with ITP's goals.
• Secure Authentication Flows: Our authentication methods, including biometric re-authentication, are built to be secure and private, using challenge-response mechanisms that don't rely on cross-site cookies for state management.
• Compliance and Trust: Being SOC 2 Type II, ISO 27001, and GDPR compliant, Didit is built on a foundation of data privacy and security, which naturally makes our platform resilient to changes in tracking prevention technologies.

Ready to Get Started?

Adapting your iOS SDK for Safari's ITP and the broader privacy landscape is not just about compliance; it's about building trust with your users and ensuring the longevity of your product. By embracing first-party contexts, leveraging appropriate APIs like Storage Access, prioritizing user consent, and staying informed about Apple's evolving policies, you can create a robust and privacy-respecting SDK.

Explore how Didit's privacy-first identity platform can simplify your compliance and enhance user experience. Visit our website, check out our technical documentation, or request a demo to see Didit in action.