How to stop apps from tracking you — iPhone and Android, step by step

The short version: toggling "Ask App Not to Track" on iPhone or deleting your advertising ID on Android stops one tracking vector — the platform ad identifier. The tracking industry has moved past that single identifier. Modern app tracking uses a layered architecture: SDKs embedded in the app's binary, device fingerprinting, hashed personal identifiers (email, phone number), probabilistic matching, and server-side event forwarding. Stopping app tracking in 2026 requires addressing each layer separately. Below: what each layer is, which apps use it, and the specific steps to shut each one down.

What app tracking actually means in 2026

When people say "apps are tracking me," they usually mean targeted ads that follow them across apps and websites. That's the visible symptom. The underlying mechanism is a network of tracking SDKs — software libraries that app developers embed in their apps during development. These SDKs run silently inside the app, collecting data about your behavior and sending it to external servers operated by advertising and analytics companies.

The most common tracking SDKs are: Facebook SDK (Meta), Google Firebase Analytics, Google AdMob, AppsFlyer, Adjust, Branch, Mixpanel, Amplitude, Segment, and Braze. A typical free app contains between 5 and 15 of these SDKs. Each one collects overlapping but distinct data, and each one sends that data to its own backend infrastructure. When you open an app, these SDKs activate immediately — often before you interact with any content — and begin collecting device information, usage patterns, and behavioral signals.

The critical thing to understand: App Tracking Transparency (ATT) on iOS only blocks access to the IDFA — Apple's Identifier for Advertisers. It doesn't block the SDKs from running, doesn't prevent them from collecting other data, and doesn't stop them from transmitting that data to their servers. When you tap "Ask App Not to Track," the app loses access to one identifier. The Facebook SDK, Google Analytics, AppsFlyer, and every other SDK in that app continue operating normally using other signals. This is why you still see eerily relevant ads after enabling ATT on every app.

What tracking SDKs actually collect

The pattern is clear: ATT removes one data point (the IDFA) from each SDK's payload. DNS-level blocking prevents the entire payload from reaching the SDK's servers. That's the fundamental difference — and why DNS blocking is the most effective single tool for stopping app tracking on both iOS and Android.

What Apple's App Tracking Transparency actually does (and doesn't)

Apple introduced ATT in iOS 14.5 (April 2021) with a clear promise: apps must ask your permission before tracking you across other companies' apps and websites. When you see the "Allow [App] to track your activity across other companies' apps and websites?" prompt and tap "Ask App Not to Track," the app loses access to the IDFA — a unique identifier that Apple assigns to each device for advertising purposes. Without the IDFA, ad networks can't deterministically link your activity in one app to your identity in another app.

That's what ATT does. Here's what it doesn't do:

• Doesn't block fingerprinting. Despite Apple's App Store policy prohibiting device fingerprinting, enforcement is inconsistent. SDKs collect device model, screen resolution, timezone, language, carrier, available storage, battery level, font list, and other signals that combine into a probabilistic device fingerprint. This fingerprint persists across ATT opt-outs because it doesn't use the IDFA.
• Doesn't block hashed identifiers. When you log into an app with your email address, the app (and its SDKs) can hash that email and send the hash to ad networks. Meta, Google, and other ad platforms maintain identity graphs that map hashed emails to ad profiles. Your hashed email becomes a cross-app identifier that works regardless of ATT status. This is now the primary mechanism for cross-app identity resolution in the post-ATT landscape.
• Doesn't block SDK data collection. ATT doesn't disable the Facebook SDK, Firebase, AppsFlyer, or any other SDK. Those SDKs continue collecting behavioral data (what screens you view, what you tap, how long you spend, what you purchase) and sending it to their servers. The data just arrives without the IDFA attached — the SDK still runs, still collects, still transmits.
• Doesn't block server-side event forwarding. Many apps now use Meta's Conversions API, Google's server-side tagging, or similar server-to-server integrations to send purchase and conversion data directly from their backend to the ad platform. This data never touches your device, so ATT has no visibility into it.
• Doesn't block Apple's own advertising. Apple's ad platform (Apple Search Ads, App Store ads) operates outside of ATT. Apple collects data about your App Store behavior, Apple News reading habits, and Stocks app usage for its own ad targeting, and this isn't subject to the ATT prompt.

We covered this gap comprehensively in our post on what iOS App Tracking Transparency doesn't stop. The short summary: ATT was a meaningful step that disrupted the easiest form of cross-app tracking. But the ad industry adapted within months. If you rely on ATT alone, the majority of app tracking continues unimpeded.

What Android's privacy controls do (and don't)

Android's approach to tracking control has evolved but remains structurally weaker than iOS in its default state. Here's what Android offers and where the gaps are.

Ad ID deletion (Android 12+): starting with Android 12, you can delete your advertising ID entirely (Settings > Privacy > Ads > "Delete advertising ID"). This is functionally equivalent to ATT's "Ask App Not to Track" — apps that request the ad ID get a zeroed-out value. The same limitations apply: SDKs continue running, fingerprinting continues, hashed identifiers still work, and server-side tracking is unaffected. Before Android 12, you could only "Reset" the ad ID (which generated a new random one) or "Opt out of Ads Personalization" (which asked ad networks to not use the ID for targeting — an honor-system request with no enforcement).

Per-app permissions: Android's per-app permission model lets you control access to location, camera, microphone, contacts, and other sensitive data. Android 13 added notification permissions. Android 14 added partial photo access (similar to iOS's limited photo selection). These are meaningful controls — an app can't access your location without permission. But they don't address tracking SDKs, which collect behavioral data that doesn't require sensitive permissions. An SDK doesn't need location permission to track which products you view, which screens you navigate to, or how much time you spend in the app.

Privacy Dashboard (Android 12+): the Privacy Dashboard shows which apps accessed location, camera, and microphone over the past 24 hours. It's useful for catching apps that access sensitive permissions unexpectedly, but it doesn't show SDK network activity, data exfiltration, or fingerprinting — the primary vectors for app tracking.

The default-state problem: Android's defaults are less privacy-protective than iOS's. Android doesn't have an equivalent to ATT's universal prompt — there's no system-level prompt asking "Allow this app to track you?" that appears on every app's first launch. The ad ID opt-out is buried in settings. Permissions default to asking on first use but many users grant them reflexively. Google Play Protect focuses on malware, not tracking. The result: on a default-configured Android phone, tracking SDKs have broader access to more data than on a default-configured iPhone, even though Android technically offers all the controls needed to restrict them. The controls exist — they just require more deliberate user action to activate.

For a complete walkthrough of Android-specific privacy controls, see our Android privacy guide for 2026.

Step 1: OS-level controls — the foundation

Start here. These settings don't stop all tracking but they remove the easiest identifiers and restrict the data that apps can access. Think of this as closing the front door — it won't stop someone from climbing through a window, but you should still close it.

iPhone (iOS 17+)

1. Disable IDFA for all apps: Settings > Privacy & Security > Tracking > toggle off "Allow Apps to Request to Track." This preemptively denies all future ATT requests and revokes existing permissions. Every app gets a zeroed IDFA.
2. Audit existing app permissions: Settings > Privacy & Security. Review each category — Location Services, Contacts, Photos, Microphone, Camera. For each, set apps to "Never" or "While Using" rather than "Always." Pay special attention to Location: most apps don't need it, and the ones that do (Maps, ride-sharing) should be set to "While Using the App."
3. Disable location-based suggestions: Settings > Privacy & Security > Location Services > System Services > toggle off "Location-Based Suggestions," "Location-Based Apple Ads," and "Significant Locations."
4. Limit Apple's own tracking: Settings > Privacy & Security > Apple Advertising > toggle off "Personalized Ads." Settings > Privacy & Security > Analytics & Improvements > toggle off "Share iPhone Analytics," "Improve Siri & Dictation," and "Share with App Developers."
5. Enable Mail Privacy Protection: Settings > Mail > Privacy Protection > toggle on "Protect Mail Activity." This prevents email tracking pixels from detecting when you open emails and hides your IP address from senders.

Android (Android 13+)

1. Delete your advertising ID: Settings > Privacy > Ads > "Delete advertising ID." This is a one-way action — you can re-create it later if needed, but deleting it immediately stops ad networks from receiving a device-level identifier.
2. Audit app permissions: Settings > Privacy > Permission manager. Review Location, Camera, Microphone, Contacts, Files and media. For Location specifically, set all apps to "Ask every time" or "Don't allow" unless they have a clear need for ongoing location access.
3. Disable usage and diagnostics sharing: Settings > Privacy > Usage & diagnostics > toggle off. This prevents your device from sending usage data to Google.
4. Review Google account activity controls: myaccount.google.com > Data & privacy > pause "Web & App Activity," "Location History," and "YouTube History." These controls affect data collection across all Google services, not just your phone.
5. Disable personalized ads in Google: Settings > Google > Ads > toggle off "Opt out of Ads Personalization" (or delete the ad ID as noted above). Also visit adssettings.google.com to manage Google's ad profile for your account.

What this accomplishes: removes platform ad identifiers, restricts app access to sensitive device features, and limits first-party data sharing with Apple and Google. What it doesn't accomplish: SDKs inside apps still collect behavioral data, fingerprinting still works, hashed email identifiers still resolve, and all network-level tracking continues. You need the next steps to address those layers.

Step 2: App hygiene — reduce your tracking surface area

Every app on your phone is a potential tracking vector. Each app contains its own set of SDKs, each SDK maintains its own connection to its backend, and each connection transmits behavioral data. The most effective way to reduce tracking is to reduce the number of apps that have the opportunity to track you.

Delete apps you don't use. The average smartphone has 80+ installed apps, but most people regularly use fewer than 30. Every unused app sitting on your phone may still be running background processes, refreshing content, and phoning home to its SDK backends. Go through your app list and delete anything you haven't opened in the past month. If you need it later, you can re-download it — the few seconds of re-installation are worth the months of unnecessary tracking you avoid.

Disable background app refresh. On iPhone: Settings > General > Background App Refresh. Disable it globally or per-app. On Android: Settings > Apps > [app name] > Battery > set to "Restricted." Background app refresh lets apps wake up periodically, fetch new data, and — crucially — send analytics events to their SDKs even when you're not using the app. Disabling it means SDKs can only collect and transmit data while you're actively using the app.

Review per-app permissions quarterly. Apps accumulate permissions over time. An app you granted location access to a year ago may no longer need it. Both iOS and Android now remind you periodically about apps with ongoing location access, but other permissions (contacts, photos, health data) don't get the same scrutiny. Set a quarterly reminder to go through Settings > Privacy and review each permission category.

Use the web version instead of the app when possible. Many services (Amazon, Reddit, YouTube, Twitter/X, LinkedIn) have fully functional mobile websites. The web version typically contains fewer tracking SDKs than the native app because web tracking is subject to browser protections (Safari's ITP, content blockers, DNS filtering). The Instagram app contains the Facebook SDK, Meta's attribution SDK, and several third-party analytics SDKs. Instagram's mobile website runs in your browser, where your content blocker and DNS filter can intercept those same trackers. This is one of the highest-leverage privacy decisions you can make: use the browser.

Step 3: Network-level blocking — catch tracker SDKs before data leaves your device

This is the step that makes the biggest difference. Network-level blocking intercepts the DNS requests that tracking SDKs make to reach their servers. When the Facebook SDK inside the Spotify app tries to resolve graph.facebook.com, a DNS filter blocks the resolution — the SDK's data never leaves your device. This works across every app on your phone, requires no per-app configuration, and catches trackers that OS-level settings don't touch.

There are four main approaches to DNS-based tracker blocking on mobile. Here's an honest comparison:

NextDNS

What it is: a cloud DNS resolver with configurable blocklists. You route your device's DNS through NextDNS's servers, which apply your chosen blocklists and return NXDOMAIN for blocked domains. Strengths: extremely granular configuration — you can enable/disable individual blocklists, whitelist specific domains, view detailed query logs, and create per-device profiles. The CNAME uncloaking feature catches some cloaked trackers that other DNS filters miss. The free tier covers 300,000 queries/month (enough for light use). Limitations: requires manual configuration and ongoing management. The query log shows every DNS request your device makes, which is a privacy consideration — NextDNS sees your entire browsing history. Performance depends on your proximity to their edge servers. Best for: technically proficient users who want full control over their blocklists and don't mind managing configuration.

Pi-hole

What it is: a self-hosted DNS sinkhole that runs on your home network (typically on a Raspberry Pi or similar device). All devices on your network route DNS through the Pi-hole, which blocks queries to known tracker and ad domains. Strengths: completely self-hosted — your DNS queries never leave your network. Highly customizable with community-maintained blocklists. No subscription cost. Limitations: only works on your home network — when you leave your house, your phone uses your carrier's DNS and tracking resumes. Setting up remote access (via WireGuard or similar VPN) is possible but adds complexity. Requires hardware, initial setup, and ongoing maintenance (blocklist updates, troubleshooting). Best for: users comfortable with self-hosting who primarily want whole-home tracker blocking and are willing to set up VPN access for mobile use.

AdGuard

What it is: a family of products including AdGuard DNS (cloud resolver), AdGuard for iOS (VPN-based filter), and AdGuard for Android (local VPN filter). Strengths: the mobile apps provide both DNS filtering and some content filtering (AdGuard for Android can filter HTTPS traffic if you install their certificate). AdGuard DNS offers a simple no-configuration option that works across platforms. Limitations: the full mobile apps use the VPN slot, so you can't run them alongside a traditional VPN. HTTPS filtering on Android requires installing a custom certificate authority, which introduces its own security implications. Best for: users who want broader filtering than DNS-only (including some content filtering) and don't need to run a separate VPN.

Casper's Cloak

What it is: a VPN-based DNS filter with threat intelligence integration, covering approximately 50,000 tracker endpoints plus ML-based detection for emerging tracker domains. Strengths: one-tap setup on both iOS and Android — no configuration required. The blocklists are curated and updated automatically. ML-based domain classification catches new tracker domains that haven't been added to static blocklists yet. Multi-device support (one account covers all your devices). Limitations: uses the VPN slot (same limitation as AdGuard). Doesn't provide the granular per-blocklist configuration that NextDNS offers. You're trusting Casper's infrastructure with your DNS queries (same trade-off as any cloud DNS provider). Best for: users who want effective tracker blocking without configuration overhead and value the ML-based threat detection for catching emerging trackers. Full details on Casper's tracker blocking.

The honest bottom line on DNS-based blocking: all four approaches block the same core set of tracker domains. The differences are in configuration complexity, portability (home-only vs. everywhere), trust model (self-hosted vs. cloud), and coverage of edge cases (CNAME cloaking, emerging domains). Any of them is a massive improvement over running no DNS filter at all. If you're choosing between them: NextDNS for granular control, Pi-hole for self-hosting, AdGuard for broader-than-DNS filtering, Casper's Cloak for zero-configuration setup with ML-based detection.

Step 4: App alternatives — replace the worst offenders

Some apps are structurally incompatible with privacy. Their business model depends on collecting and monetizing your behavioral data — no amount of OS settings or DNS filtering changes that fundamental incentive. For these apps, the most effective strategy is switching to alternatives that are either privacy-first by design or whose business model doesn't depend on tracking.

The realistic approach: you don't have to switch everything at once, and some switches aren't practical for everyone (WhatsApp is the default messaging app in many countries — switching to Signal only works if your contacts switch too). Start with the highest-leverage changes: browser (affects all web tracking), search engine (affects the single largest tracker), and keyboard (has full access to everything you type). These three switches meaningfully reduce tracking without requiring anyone else to change their behavior.

What you still can't stop

Even after applying every step above, some tracking continues. Being honest about these limits is important — it prevents a false sense of security and helps you make informed decisions about which services you use.

First-party analytics. When you use the Instagram app, Instagram itself (Meta) collects data about which posts you view, how long you spend on each, what you search for, and what you tap. This data collection happens inside the app and is sent to Instagram's own servers (instagram.com, not a third-party tracker domain). DNS filters can't block it without breaking the app entirely — the analytics endpoints share infrastructure with the content delivery endpoints. The only way to avoid first-party analytics is to not use the service.

Server-side event processing. When you buy something from an online store that uses Meta's Conversions API, the store's server sends your purchase data (amount, product, hashed email) directly to Meta's server. Your device is not involved in this transaction — two servers talk to each other. No client-side tool (VPN, DNS filter, content blocker) can intercept server-to-server communication. This is the structural ceiling of all device-level privacy tools, and it's the primary direction the tracking industry is moving.

Apple's own data collection. Apple collects data about your App Store browsing, Apple News reading, Stocks app usage, Siri interactions, and device diagnostics. While you can disable some of these (as noted in Step 1), Apple's core services generate behavioral data that feeds Apple's ad targeting and product recommendations. Apple positions itself as a privacy company, and its data collection is significantly less extensive than Google's — but it's not zero.

Google's platform-level collection on Android. On Android, Google Play Services runs as a system-level process with broad permissions. It collects device state, app usage, location data (if location permissions are granted to Google apps), and connectivity information. Some of this collection continues even with the privacy settings above configured. The only way to fully avoid Google's platform-level collection on Android is to use a degoogled Android distribution like GrapheneOS — which is excellent but requires a Pixel phone and more technical effort to set up and maintain.

Network metadata. Even with DNS filtering, your carrier and ISP can see which IP addresses your device connects to, when, and how much data is transferred. A VPN encrypts the content and hides destination IPs from your ISP, but the VPN provider then has that metadata instead. This is a fundamental property of how networking works — someone in the chain always sees the routing information.

Putting it all together

Stopping apps from tracking you is not a single toggle — it's a layered defense that addresses different tracking mechanisms at different levels. Here's the priority order, from highest impact to lowest effort:

1. Set up DNS-level blocking (5 minutes, biggest single impact). This catches the majority of third-party tracking SDKs across every app on your phone. Casper's Cloak, NextDNS, Pi-hole, or AdGuard — any of them works.
2. Configure OS-level privacy settings (10 minutes). Disable IDFA/ad ID, restrict app permissions, turn off analytics sharing. Removes the easy identifiers.
3. Delete unused apps and disable background refresh (10 minutes). Reduces your tracking surface area immediately.
4. Switch your browser, search engine, and keyboard (5 minutes). The three highest-leverage app switches.
5. Use web versions instead of native apps (ongoing behavior change). Especially for social media and shopping — the web version is subject to your browser's protections.

Total setup time: roughly 30 minutes. The result: the overwhelming majority of third-party app tracking is blocked, your device's advertising identifiers are disabled, your app permissions are locked down, and you've eliminated the apps and default settings that contribute the most tracking data. The tracking that remains — first-party analytics, server-side event processing, and platform-level collection by Apple/Google — represents the structural ceiling of what device-level tools can address. Addressing those requires service-level choices (which platforms you use) rather than device-level configuration.

Bottom line

The apps on your phone contain tracking SDKs that collect behavioral data and transmit it to advertising and analytics companies. Apple's ATT and Android's privacy controls address one vector (the platform ad identifier) but leave the rest intact — fingerprinting, hashed identifiers, SDK data collection, and server-side event forwarding all continue after you tap "Ask App Not to Track." Stopping app tracking requires a layered approach: OS settings to remove easy identifiers, app hygiene to reduce your surface area, DNS-level blocking to intercept SDK network requests, and strategic app switches to eliminate the worst offenders. No combination of tools stops 100% of tracking — first-party analytics and server-side processing represent a structural limit. But the layered approach above stops the vast majority of third-party tracking, and it takes about 30 minutes to set up across all your devices.