App-ads.txt borrows a website's trust to vouch for an app

The revenue mechanism

The ads.txt specification worked because a website and its authorized-sellers file live at the same domain, so control of the file proves control of the content. A mobile app has no domain of its own to host such a file, which left in-app inventory exposed to the same counterfeit-seller problem ads.txt had just fixed on the web. IAB Tech Lab closed that gap with app-ads.txt. Its own explainer states that "on March 13th we released the final version of app-ads.txt," describing it, in the post published 20 June 2019, as "the mobile and native app follow-up to ads.txt." The mechanism a publisher's app-based revenue now runs through is indirect: an app has no ads.txt of its own, so authorization is instead declared on the app developer's website, linked to the app through a "developer URL" field that app stores already display.

What the documents show

The explainer describes the chain precisely: an ad platform reads an app's platform and store ID, looks up the app's listing, retrieves the developer URL the store lists for it (a field only the app's own developer can set), and then checks for an authorized-sellers file at that URL's domain, at the standard app-ads.txt path. The companion FAQ, dated 4 March 2019, confirms this requires a buyer to "crawl app listing pages in app stores" to obtain that metadata in the first place, rather than fetching a single well-known file directly as with web ads.txt.

The assumptions exposed

App-ads.txt assumes the app store itself accurately displays a developer URL, and that the URL points to a domain the developer genuinely controls, since both the explainer and FAQ describe the trust anchor as "only the owner of the app on that app store can set the developer URL." If a store does not support that metadata field consistently, or a developer leaves it blank or wrong, the whole lookup chain breaks before a buyer ever reaches an app-ads.txt file. This is a meaningfully weaker anchor than web ads.txt's direct domain control, and a publisher assuming app-ads.txt gives identical protection to its app inventory as to its website is over-reading the mechanism.

What to check before you rely on it

This is an editorial checklist. A publisher monetizing an app should verify the developer URL field is set correctly in every store listing before assuming buyers can find its app-ads.txt file at all.

• Is the developer URL field populated correctly in each app store listing for every publishing account?
• Does the linked domain actually host a current app-ads.txt file at the standard location?
• Do your programmatic buyers confirm they crawl store metadata for app-ads.txt, or only support the web version?

App-ads.txt extended a working web standard into an environment that was not built to support it, and the documents are candid that the extension depends on app-store cooperation the specification itself cannot enforce.