app-ads.txt: The 2026 Mobile App Developer Setup Guide

app-ads.txt is the mobile-app version of ads.txt. It is a plain-text file that app developers host at the root of their public developer website, listing every advertising seller authorized to monetize their apps. The IAB Tech Lab launched the spec in March 2019 to close the mobile equivalent of domain spoofing, and adoption among the top 1,000 mobile apps now exceeds 90% according to Pixalate’s 2025 mobile ads.txt scorecard. ^[1]

This guide covers the anchoring mechanism that ties a file on your website to bids for your apps, the exact field paths in Google Play Console, App Store Connect, and Amazon Appstore, common setup errors, and how app-ads.txt fits into the broader mobile fraud defense stack alongside click fraud protection and SDK spoofing detection.

What is app-ads.txt and why was it created?

After web ads.txt stabilized in 2018, programmatic fraud migrated to mobile. Counterfeit apps spoofed premium game bundle IDs in bid requests, and second-tier SSPs without supply path verification passed the bids through to DSPs. The IAB Tech Lab released app-ads.txt in March 2019 as the mobile extension of the ads.txt framework, using the same file syntax and the same DSP verification flow. ^[2]

The core fraud vector was straightforward. A fraud operator would build a low-quality app, then send bid requests labeled as com.king.candycrushsaga or another premium bundle. DSPs paid premium CPMs for traffic that never touched the real app. Pixalate’s mobile invalid traffic reports from 2018 to 2019 found that mobile-app domain spoofing represented one of the fastest-growing programmatic fraud categories, with some inventory pools showing 20 to 30% spoofed traffic before the spec rolled out. ^[1]

The IAB Tech Lab faced a design constraint web ads.txt did not have: apps do not have URLs. You cannot host a file at the root of an app. The spec solved this with indirect anchoring, which makes app-ads.txt setup fundamentally different from web ads.txt despite the identical file format.

How does app-ads.txt anchoring work?

The anchoring chain has four steps, and a break at any step prevents SSP crawlers from associating your file with your apps:

1. Developer publishes apps to Google Play, App Store, Amazon Appstore, or another store
2. Each app store listing includes a developer website URL field — already mandatory in major stores for support and contact purposes
3. Developer hosts app-ads.txt at the root of that website domain
4. SSPs and DSPs resolve a bid by fetching the app’s public store listing, extracting the developer URL, then fetching /app-ads.txt at that domain root

The crawler does not communicate with the app itself. It uses the app bundle ID or store ID in the bid request to look up the public store listing, parses the developer URL from the HTML, and then runs the same plain-text fetch and validation as web ads.txt.

This indirection has two practical consequences:

• One developer domain can host one file that authorizes sellers for hundreds of apps, as long as every app’s store listing points to that domain
• A single broken store-listing field breaks app-ads.txt for that app, even if the file itself is perfect

When SSPs report that your app is “not authorized” despite a valid file, the failure is almost always at step 2, not step 3.

Format and syntax (same as ads.txt)

The file format is byte-for-byte identical to web ads.txt. Each line has four comma-separated fields:

<seller_domain>, <publisher_account_id>, <account_type>, <TAG_certification_ID>

For the complete field-by-field breakdown, including DIRECT, RESELLER, and BOTH values, comments, control variables, and encoding rules, see our ads.txt explained guide. The relevant constraints repeated here:

• File must be served with Content-Type: text/plain
• UTF-8 encoding, no byte-order mark (BOM)
• HTTP 200 response, no authentication, no CAPTCHA, no IP-based blocks for crawler user agents
• Comma separators only, no tabs
• Comments start with #
• Two control variables permitted: contact= and subdomain=

The only practical difference at the file level is typical content. Web ads.txt files reference web-focused SSPs (Magnite, PubMatic, OpenX, Index Exchange, Google AdX). app-ads.txt files reference mobile-focused SDK networks (AdMob, AppLovin, Unity Ads, ironSource, Vungle, Chartboost, Mintegral, Liftoff) alongside the generic exchanges that handle both.

Annotated app-ads.txt example

Here is a typical app-ads.txt for a mid-sized mobile game studio:

# app-ads.txt for ExampleGameStudio
# Developer site: examplegamestudio.com
# Apps covered: com.examplegamestudio.puzzlequest (iOS + Android),
#               com.examplegamestudio.runnergame (iOS + Android),
#               com.examplegamestudio.match3 (Android)
# Last updated: 2026-05-01
# Contact: adops@examplegamestudio.com

contact=adops@examplegamestudio.com

# Google ad stack (AdMob + AdX, same publisher account)
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
admob.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

# Major SDK networks
applovin.com, abc123def456ghi789, DIRECT
unityads.unity3d.com, 1234567, DIRECT
ironsourceads.com, 7654321, DIRECT
vungle.com, 5d1234567890abcdef, DIRECT
chartboost.com, 5e9876543210fedcba, DIRECT

# Exchanges that bid on mobile inventory
pubmatic.com, 159753, DIRECT, 5d62403b186f2ace
openx.com, 540123456, DIRECT, 6a698e2ec38604c6

# Reseller paths (mediated through certified partners)
applovin.com, abc123def456ghi789, RESELLER
pubmatic.com, 246810, RESELLER, 5d62403b186f2ace

Reading the line applovin.com, abc123def456ghi789, DIRECT:

• AppLovin is an authorized seller for every app whose store listing points to examplegamestudio.com
• The studio’s AppLovin publisher account ID is abc123def456ghi789
• It is a DIRECT relationship, meaning AppLovin pays the studio directly

When a DSP receives a bid request for bundle ID com.examplegamestudio.puzzlequest routed through AppLovin with seller_id abc123def456ghi789, the DSP performs this chain:

1. Look up com.examplegamestudio.puzzlequest in the store listing
2. Extract the developer URL: https://examplegamestudio.com
3. Fetch https://examplegamestudio.com/app-ads.txt
4. Find the line where seller_domain is applovin.com and account ID is abc123def456ghi789
5. Confirm the relationship type is DIRECT
6. Cross-check AppLovin’s sellers.json to confirm the account maps back to ExampleGameStudio

If any step fails, the bid is rejected.

How do I set up app-ads.txt for each app store?

The store-listing setup is what trips up most developers. The file itself is trivial once the developer URL is correct.

Google Play Console

The developer website URL field path in Google Play Console:

Play Console → Your app → Grow → Store presence → Main store listing → Store listing contact details → Website

Specific requirements that match the IAB Tech Lab crawler expectations:

• Must be a fully qualified URL with https:// protocol
• Must point to a domain you control and can host static files on
• Cannot be a tracking link, deep link, redirect-shortener, or marketing campaign URL
• Cannot 301-redirect to a different domain (the crawler follows redirects but each hop is a failure point)
• The same URL is reused for every app under your Play developer account by default, but can be overridden per-app

Beyond setting the field, Google Play’s automated app-ads.txt validator runs continuously. Find the status at Play Console → Monetize → Monetisation setup → App-ads.txt (the exact path has shifted over Play Console redesigns). The status panel reports the last crawl time and any parse errors. ^[3]

Apple App Store Connect

App Store Connect uses two URL fields, and SSP crawlers behave inconsistently between them. The safest practice is to set both:

App Store Connect → My Apps → Your app → App Information → General Information → Marketing URL

App Store Connect → My Apps → Your app → App Information → General Information → Support URL

The Marketing URL is the field most major SSPs prefer, but some fall back to Support URL. Both should point to the same developer domain root where you host app-ads.txt. Specific gotchas:

• Apple does not validate that these URLs are reachable at submission time
• The Marketing URL is optional in App Store Connect but required for app-ads.txt anchoring
• The Privacy Policy URL is a separate field and is not used for app-ads.txt resolution by most crawlers
• Changes to these URLs propagate to the public App Store listing within a few hours, and crawlers typically re-check within 24 to 72 hours

Apple does not publish a built-in app-ads.txt status panel. Validation has to come from third-party tools or each SSP’s dashboard. ^[4]

Amazon Appstore

Amazon’s developer portal field path:

Amazon Developer Console → Apps & Services → Your app → App File(s) → Browse → Website (in the General Information block)

The Amazon Appstore footprint is smaller than Google Play or App Store, but for developers targeting Fire TV, Fire tablets, and Alexa devices the same anchoring rules apply. Amazon’s crawler tolerates minor formatting issues that Google Play’s validator rejects, so an app-ads.txt that validates clean for Play will validate clean for Amazon by default.

Other stores

For Huawei AppGallery, Samsung Galaxy Store, Microsoft Store, and similar second-tier app stores, the developer URL field typically lives under app metadata or company information. The exact path varies, but the IAB Tech Lab spec is store-agnostic: any store that exposes a public developer URL in the app listing can be used as an anchor.

Common validation errors (mobile-specific)

Many setup errors are inherited from web ads.txt (MIME type, BOM, tab separators). The mobile-specific failures are nearly all in the anchoring layer:

Error	Cause	Fix
No developer URL in store listing	Field left blank during app submission	Set the developer website URL in each store’s app metadata
Developer URL points to wrong domain	Marketing URL set to a campaign landing page or tracking link	Change the field to your canonical developer domain root
Tracking parameters in URL	URL like https://yoursite.com/?utm_source=appstore	Strip query string; SSPs may not follow parameterized URLs
Redirect from declared URL to actual host	App store URL 301-redirects to a different domain	Host app-ads.txt at the exact domain declared, no redirects
Bundle ID mismatch	Bid request bundle ID does not match store listing	Audit each SSP SDK config to ensure the bundle ID sent in bid requests matches the public store ID exactly
Different URL per store	iOS listing points to one domain, Android to another	Either consolidate to one domain, or host app-ads.txt at both
CDN blocks crawler UA	Cloudflare or other CDN treats SSP crawler as bot	Allowlist IAB Tech Lab, Pixalate, DoubleVerify, IAS, and major SSP crawler user agents
File served from www. only	Apex domain does not serve app-ads.txt	Serve at both apex and www. or 301 apex to www. consistently
Subdomain anchoring	Developer URL is apps.yoursite.com but file is at apex	Host app-ads.txt at the exact domain in the developer URL, including subdomain
Wrong publisher_account_id format	Account ID copied with extra prefix or URL	Use only the SSP-provided account string, contiguous, no spaces

When the file is clean but bids still get rejected

Three things to verify if your app-ads.txt validates green but SSPs still report your app as unauthorized:

1. Bundle ID consistency. The bundle ID in your SDK config, your store listing, and the bid request must match exactly. iOS apps occasionally send the build identifier instead of the store bundle, and Android apps occasionally send a debug-build suffix.
2. The SSP’s own sellers.json. Fetch the SSP’s sellers.json and confirm your publisher account ID is listed with a domain or app ID that matches your store listing. If sellers.json is out of date, open a ticket with the SSP.
3. Store listing crawl freshness. SSPs typically cache the developer URL for 24 to 72 hours after first resolving a bundle ID. If you just changed the URL in App Store Connect, the SSP may still be using the cached value.

How does app-ads.txt prevent mobile app fraud?

app-ads.txt closes the same fraud vector as web ads.txt, but the mobile attack surface has unique shapes. The framework is most effective against counterfeit-app spoofing and bundle ID spoofing, where a fraud operator labels worthless inventory with a premium bundle ID to attract premium CPMs.

Without app-ads.txt, a DSP receiving a bid for com.king.candycrushsaga from a no-name SSP has no programmatic way to verify King authorized that SSP. With app-ads.txt, the DSP fetches king.com/app-ads.txt, sees the SSP is not listed, and rejects the bid. The IAB Tech Lab’s 2023 effectiveness review estimated that bundle ID spoofing on top-1,000 apps dropped by over 70% in the two years following widespread app-ads.txt adoption. ^[2]

What app-ads.txt does not catch:

• SDK spoofing — the fraud technique where a malicious SDK fabricates ad impressions and click events that look legitimate but never rendered. See our SDK spoofing detection guide for the signals that catch this layer.
• Click injection and click flooding — install-attribution fraud where a malicious app claims credit for organic installs. Covered in click injection vs click flooding.
• Bot traffic to legitimately authorized inventory, where the bid path is clean but the user is automated
• In-app click fraud on rendered ads, where the impression is real but the click is generated by a click farm or emulator

In mobile programmatic, app-ads.txt is necessary but not sufficient. It belongs in the same defensive stack as MMP fraud filters, IVT scoring, SDK fingerprinting, and behavioral analytics. For the broader picture of how these layers interact, see our best click fraud protection software 2026 breakdown.

Adoption status in 2026

Mobile app-ads.txt adoption has historically lagged web ads.txt by 18 to 24 months. As of Q1 2026, Pixalate’s adoption tracker reports the following approximate breakdowns: ^[1]

• Top 1,000 mobile apps (combined iOS + Android): over 90% have a valid app-ads.txt
• Top 10,000 apps: roughly 75 to 80%
• Mid-tier apps (10k to 100k store rank): roughly 60 to 70%
• Long-tail and casual gaming: below 50% in many sub-genres
• CTV apps: climbing rapidly, but still under 75% across major TV platforms

The persistent gap concentrates in three areas:

1. Smaller indie and hobbyist developers without a dedicated developer website. The IAB Tech Lab spec assumes the developer owns a domain, which is not always true for solo or hobby publishers.
2. White-label and reskin gaming studios that publish many shell apps under different developer accounts but route revenue through one SSP relationship. The bookkeeping of keeping per-domain app-ads.txt files synced is operationally heavy.
3. CTV and connected-device apps where the developer infrastructure is newer and the store-listing fields are inconsistent across platforms (Roku, Samsung Tizen, LG webOS, Amazon Fire TV).

For media buyers, the practical implication is that buying mobile programmatic without app-ads.txt verification means accepting elevated spoofing risk on the long tail. The major DSPs in 2026 default to filtering bids from apps with no resolvable app-ads.txt, but smaller DSPs and direct-to-SSP buys often still buy unverified inventory.

Where Adsafee fits

Adsafee verifies app-ads.txt and sellers.json alignment as part of multi-signal mobile fraud protection. When a bid for one of your apps resolves through an SSP that is not in your app-ads.txt, or when the bundle ID in the bid request does not match the store listing’s anchored developer URL, we flag the impression and ship evidence-grade reports to the advertiser side. app-ads.txt is one signal in our scoring engine, paired with SDK fingerprinting, install-attribution analysis, and behavioral signals for the full mobile fraud picture.

If you run mobile UA campaigns and want to see how much of your spend touches inventory with broken app-ads.txt anchoring, start a free trial — the first mobile audit takes about 15 minutes.

---

Sources

1. Pixalate, “Mobile App ads.txt and app-ads.txt Adoption Trends” (2025 scorecards and Q1 2026 update) — adoption percentages by store rank and category. Visit: pixalate.com/research-reports. ↩

2. IAB Tech Lab, “app-ads.txt Specification”, released March 2019, plus the 2023 framework effectiveness review on bundle ID spoofing reduction. Visit: iabtechlab.com/ads-txt/. ↩

3. Google, “app-ads.txt guide for app developers” in Google Play Console help documentation — field paths, validator status, and crawl cadence. Visit: support.google.com/googleplay/android-developer. ↩

4. Apple, “App Store Connect Help — App Information”, including Marketing URL and Support URL field definitions used for app-ads.txt anchoring. Visit: developer.apple.com/help/app-store-connect. ↩