app-ads.txt: Mobile App Publisher Authorization

The success of ads.txt on the web exposed a critical gap: mobile apps have no domain root on which to host a text file. In-app advertising, which accounts for the majority of mobile programmatic spend, lacked a standardized publisher authorization mechanism. The IAB Tech Lab introduced app-ads.txt in late 2018 to close this gap, extending the same trust framework to mobile applications through app store integration.

Why app-ads.txt Exists

In the web ecosystem, ads.txt works because every domain has a canonical root where a file can be placed and verified. Mobile apps have no equivalent concept. An app identified by its bundle ID (com.example.game) or App Store ID has no inherent web presence that buyers can crawl.

This structural difference created massive fraud opportunities. Malicious actors could submit bid requests claiming to sell inventory from popular apps they had no relationship with, and buyers had no automated way to verify these claims. The scale of in-app programmatic advertising—representing tens of billions of dollars annually—made this an urgent problem.

The app-ads.txt Solution

app-ads.txt introduces a bridge between the app store listing and a web-hosted authorization file. The publisher provides a developer URL in their app store listing, and the app-ads.txt file is expected to be hosted at that URL. Buyers look up the app store listing to find the developer URL, then crawl that domain for the app-ads.txt file.

Key Differences from Web ads.txt

The file format itself is identical to ads.txt. Each record contains the advertising system domain, account ID, relationship type (DIRECT or RESELLER), and certification authority ID. The fundamental difference is in how buyers discover and validate the file.

How App Store Validation Works

The discovery and verification flow for app-ads.txt involves three parties: the app developer, the app store, and the buyer.

Discovery Flow

1. The app developer sets a Developer Website URL (Google Play) or Marketing URL (Apple App Store) in their app listing.
2. The buyer identifies a bid request claiming to represent a specific app by its bundle ID (e.g., com.example.game).
3. The buyer queries the app store API or scrapes the app listing to retrieve the developer website URL.
4. The buyer crawls https://developer-website.com/app-ads.txt to retrieve the authorized seller list.
5. The buyer checks whether the seller identified in the bid request is listed in the app-ads.txt file.

The critical trust anchor is the app store listing. By controlling the developer URL field in their store listing, the app developer establishes the connection between their app identity and their web domain. This is why app store account security is essential for preventing unauthorized modification of the developer URL.

Google Play vs. Apple App Store

Google Play

Google Play provides a website field in the app listing metadata, accessible via the Google Play Store API or by parsing the listing page. The field maps to the developer's declared website URL. Google also integrates app-ads.txt verification into its own advertising systems, including AdMob and Ad Manager.

Apple App Store

Apple provides a sellerUrl field in the App Store listing, which corresponds to the Marketing URL that developers configure in App Store Connect. This URL is accessible through the iTunes Lookup API. One challenge with the Apple ecosystem is that not all developers populate this field, which can prevent buyers from discovering the app-ads.txt file.

# iTunes Lookup API example
GET https://itunes.apple.com/lookup?id=APP_STORE_ID

# Response includes:
{
  "results": [{
    "sellerUrl": "https://developer-website.com",
    "bundleId": "com.example.game",
    "trackName": "Example Game"
  }]
}

# The buyer then crawls:
# https://developer-website.com/app-ads.txt

Implementation Guide for Android

Step 1: Set Your Developer Website URL

In the Google Play Console, navigate to your app's store listing and ensure the Website field is populated with the domain where you will host your app-ads.txt file. This must be the apex domain or a subdomain you control.

Step 2: Create the app-ads.txt File

Create a text file following the standard ads.txt format. Include all authorized ad networks and exchanges:

# app-ads.txt for com.example.game
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
admob.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
unity3d.com, 12345, RESELLER, a]b8c4d2e6f
ironsrc.com, 67890, RESELLER, 3f4g5h6i7j8k
applovin.com, 11111, RESELLER, 9d8403355cc26a78
mopub.com, 22222, RESELLER, a3f5b8c1d2e4f6g7

Step 3: Host the File

Upload the file to the root of the domain specified in your Google Play listing. The file must be accessible at https://yourdomain.com/app-ads.txt and return a 200 HTTP response with text/plain content type.

Step 4: Verify and Monitor

After publishing, use verification tools (such as Google's app-ads.txt checker in AdMob) to confirm the file is discoverable. Monitor your fill rates and eCPMs for changes that might indicate buyers are not finding or correctly parsing your file.

Implementation Guide for iOS

Step 1: Configure Your Marketing URL

In App Store Connect, go to your app's information page and set the Marketing URL to the domain where your app-ads.txt file will be hosted. Note that Apple requires this URL for app review in some regions.

Step 2: Create and Host the File

The process is identical to Android. The file format and hosting requirements are the same. The key difference is that buyers discover the file through the iTunes Lookup API's sellerUrl field rather than Google Play metadata.

Step 3: Handle Multiple Apps

If you have multiple apps sharing a developer website, you have two options:

• Host a single app-ads.txt at the shared domain that includes entries for all apps and ad networks
• Use separate domains or subdomains for each app with individual app-ads.txt files

The IAB specification supports a single app-ads.txt file serving multiple apps, as long as the developer URL in each app store listing points to the same domain.

Adoption Rates and Market Impact

Since its introduction, app-ads.txt adoption has grown steadily but has not reached the same saturation levels as web ads.txt:

• Google Play adoption: Approximately 65-70% of top monetized apps have a discoverable app-ads.txt file, with higher rates among top-grossing titles.
• Apple App Store adoption: Roughly 50-60% of top apps have app-ads.txt configured, though the sellerUrl field is not always populated even when the file exists.
• Exchange enforcement: Major exchanges like Google AdMob, Meta Audience Network, Unity Ads, and AppLovin have implemented app-ads.txt verification and may reduce fill rates for non-compliant apps.

Enforcement and Compliance

Exchange-Level Enforcement

Leading mobile ad networks and mediation platforms have adopted varying enforcement policies:

• Google AdMob/Ad Manager: Provides warnings in the AdMob UI when app-ads.txt is missing or misconfigured. Does not block serving but prioritizes verified inventory.
• Meta Audience Network: Requires app-ads.txt for Audience Network monetization. Apps without a valid file may see reduced fill.
• Unity Ads: Supports app-ads.txt verification and provides compliance status in the Unity dashboard.
• DSP enforcement: Major DSPs like NexBids enforce app-ads.txt checks during bid evaluation, filtering out unauthorized sellers.

Common Compliance Issues

• Missing developer URL: The app store listing has no developer website configured, making discovery impossible.
• URL mismatch: The developer URL points to a different domain than where app-ads.txt is hosted.
• Incorrect file name: Hosting the file as ads.txt instead of app-ads.txt (buyers specifically look for the app- prefix).
• Stale content: Not updating the file when adding or removing ad network partners.
• HTTPS requirement: The file must be served over HTTPS. HTTP-only hosting may cause crawlers to skip the file.

Challenges and Future Directions

Despite its effectiveness, app-ads.txt faces several ongoing challenges:

• Discovery latency: Crawling app store listings and then developer websites introduces significant latency in the verification process. Buyers must cache app store metadata to perform real-time verification.
• App store dependency: The system relies on app stores maintaining accurate and accessible listing data. Any changes to store APIs or listing formats can break the verification chain.
• No enforcement mandate: The IAB specification is voluntary. There is no industry mandate requiring all apps or exchanges to adopt app-ads.txt.
• Bundle ID spoofing: While app-ads.txt helps verify the seller, it does not prevent sophisticated fraudsters from spoofing bundle IDs in bid requests to exchanges that don't perform adequate verification.

Future improvements may include deeper integration with the OpenRTB SupplyChain object for in-app inventory, enhanced app store APIs for real-time developer URL verification, and industry-wide enforcement mandates from major programmatic platforms.