When ads.txt launched in 2017, it addressed a specific, structural problem: buyers had no reliable way to confirm who was authorized to sell a given domain’s inventory.
The solution was elegant: a text file at the root domain, crawlable by anyone, that listed authorized sellers. It worked because the web is built around domains, and domains are owned by identifiable entities. Buyer sees domain, buyer checks root, buyer confirms authorization. Simple.
App environments don’t work the same way. And that difference explains why, in the years since IAB Tech Lab published detailed app identification guidelines, and an app-ads.txt spec in 2019, to help buyers confirm who they’re actually funding.
What the web gets right
Ads.txt works because the infrastructure it relies on is stable and accessible. A domain has a single root. The owner controls what sits at that root. When a buyer crawls an ads.txt file, they’re reading something the domain owner deliberately placed there. Ownership is implicit in the act of publishing.
App environments require an additional layer. An app has a store listing, a developer URL, a bundle ID, and a series of metadata fields that are supposed to connect it to the developer behind it. Whether those fields are present (and whether they resolve to something meaningful) depends entirely on what the platform chooses to expose.
That platform dependency is where the verification chain breaks down. But it does so a bit differently on every platform.
What the app environments actually provide
Across six major platforms, we audited nine verification signals, including the ones that IAB Tech Lab specified in 2019 as necessary for connecting an impression to a verifiable developer.
Google Play provides all nine. A buyer can confirm developer identity, check category placement, access the privacy policy URL, and verify the bundle ID without leaving the store listing. That’s should be the standard.
Apple’s App Store- the largest platform we analyzed at roughly 1.37 million apps- does not expose the developer URL or bundle ID meta-tags the standard requires. Those are the two fields verification systems use to connect a bid request to a developer-controlled domain. Without them, buyers infer developer identity rather than confirm it, on the world’s largest app store.
Among CTV-native platforms, Roku performs reasonably well, providing most of the signals buyers need to evaluate inventory. The picture changes quickly on smart TV platforms. Samsung Smart TV is missing five of the nine signals, including rating counts, age advisories, and privacy policy coverage. Samsung and LG Smart TV apps have no privacy policy coverage at all across every app we analyzed.
Why ads.txt can’t close this gap
Compliance rates on most platforms are low: 14.1% on Roku, 8.7% on LG. But the more significant issue is what’s behind the apps that do declare compliance.
Among Google Play apps that list a privacy policy, 38.9% point to free hosting infrastructure: Blogspot subdomains, Google Docs, spoofed ads.txt domains. We found 82,966 apps pointing to ads.txt hosting services (some well-known, others not so much) as their declared developer URL, the field verification that systems use to locate ads.txt files in the first place. An app routing its declared developer identity through anads.txt service isn’t failing to comply, but it also isn’t doing much to inspire buyer confidence that this is an accountable developer.
This is the mechanism that the web’s ads.txt model can’t solve. For a domain, the root is either controlled by the publisher or it isn’t. In app environments, the declared developer URL can point anywhere, as well as whether that destination reflects genuine developer accountability, are questions that store listings alone can’t answer.
The declaration gap makes this concrete in a different way. On Amazon, more than one in three apps that explicitly declare they run advertising have no app-ads.txt file. On Roku, nearly one in three. These aren’t apps that slipped through without declaring; they passed the self-declaration test and still can’t demonstrate authorized supply. On Apple, only 3.1% of App Store apps declare containing ads at the store level at all, all because no requirement exists.
The ads.txt model works because it leverages infrastructure that’s consistently structured across domains. App stores are not consistently structured. What a buyer can verify on Google Play, they cannot verify on Samsung.
The IAB identified this in 2019 and specified exactly what needed to change. What it couldn’t do was mandate implementation. That gap is now five years wide, and widest in the CTV environments where programmatic spend is growing fastest.
In our new report The App Environment Verification Blind Spot, we look at the fuller picture of these dynamics, including platform-by-platform signal availability, the infrastructure quality behind declared compliance, and the risk categories that operate where verification breaks down. Download it below.
DeepSee.io also now surfaces app-level compliance signals for mobile and CTV apps, including ads.txt status, developer URL trust, and privacy policy infrastructure, using the same signal structure applied on the web. Read more about how it works in the portal.
