Compliance

app-ads.txt for Mobile Apps: The Complete Developer Guide

What app-ads.txt is, why every ad-supported mobile app needs one, where the IAB spec says to host it, and how to publish yours correctly in 2026.

8 min read

app-ads.txt for Mobile Apps: The Complete Developer Guide

Your app monetizes through AdMob, AppLovin, or Meta Audience Network. Fill rates looked solid at launch, then a quiet drop. Dashboards say everything is configured, but eCPMs keep slipping. Somewhere in the supply chain, a demand-side platform decided it could not verify your impressions were yours to sell, so it stopped bidding. The fix is a four-field plain text file most indie developers never hear about until their inventory starts getting filtered out. That file is app-ads.txt, and the IAB Tech Lab spec says it must live at a very specific URL derived from your store listing.

TL;DR

  • app-ads.txt declares which ad networks are authorized to sell your app's inventory. IAB Tech Lab published it in 2019 as the mobile extension of the 2017 ads.txt standard.
  • It must be hosted at the root of your developer website URL on the App Store or Google Play — discovery is deterministic.
  • Each line is DOMAIN, PUB_ID, RELATIONSHIP, CERT_ID. AdMob, Meta, AppLovin, and Unity publish the lines they expect.
  • Common failures: wrong host, stale entries, typoed IDs, missing resellers.
  • You can self-host on Netlify, but AppLander serves app-ads.txt from each app's public subdomain alongside the rest of your compliance assets.

Table of Contents

What the IAB Spec Actually Demands

The IAB Tech Lab published app-ads.txt in March 2019 as an extension of ads.txt, the 2017 website standard. The goal is the same: cut off inventory spoofing, where a fraudulent seller claims to offer ad slots from a publisher they have no relationship with.

The file is a newline-separated list of records with up to four comma-separated fields:

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

Field by field:

  1. Domain — the root domain of the ad system, e.g. google.com.
  2. Publisher account ID — the ID the ad system issued for you.
  3. Relationship — DIRECT if you contract with the ad system yourself, RESELLER if a third party sells on your behalf.
  4. Certification authority ID — an optional TAG identifier for cross-referencing against a trust registry.

The discovery rule is the part most developers miss. The file is not served from your app binary — it is served from the developer website URL on your store record. When a buyer sees a bid tagged with your app's bundle ID, their SSP fetches your store listing, reads the developer URL, appends /app-ads.txt, and checks whether the seller matches a line in that file. No match, no bid.

Why This Is Harder Than It Looks

The file itself is trivial. The context around it is not. Your developer URL is sticky — it is the marketing website you entered during App Store Connect or Play Console setup. If that URL points to an abandoned WordPress site or a Linktree bio page, you cannot publish /app-ads.txt on something you do not control.

Every mediation partner adds lines. You start with AdMob, add AppLovin MAX, drop in Unity, then test Meta Audience Network. Each partner publishes its own entries, sometimes with multiple RESELLER lines. Forget one and the lost revenue is silent — no 4xx, no warning email.

The file is crawler-cached: buyers crawl on a schedule, so a fix you push today may take a day or more to propagate.

Three Ways to Host the File

Self-host on a static site (Netlify, Cloudflare Pages, GitHub Pages)

Drop one app-ads.txt file at the root of a static site, point your developer URL at that domain.

Pros.

  • Free, stable, and gives you full control over the URL.
  • Deploys instantly on edit — no third-party delay.
  • Works for multiple apps under one developer root.

Cons.

  • No validation — invalid lines fail silently.
  • You must remember to update the file when mediation partners change.
  • If you do not already run a marketing site, you are standing up infrastructure for one text file.

Best for. Developers who already run a static marketing site and are comfortable editing a text file in a Git repo.

A no-code site builder (Carrd, Squarespace, Framer)

Point your developer URL at a drag-and-drop builder and upload the file through its asset tools.

Pros.

  • No DevOps beyond initial DNS setup.
  • You get a marketing page for the app as a bonus.
  • Subscription price is small.

Cons.

  • Not every builder exposes a raw /app-ads.txt endpoint cleanly.
  • Vendor lock-in on both the marketing page and the compliance file.
  • Updating requires logging into the builder rather than a scripted deploy.

Best for. Solo developers who want one vendor for both the marketing page and the file.

Dedicated app-ads.txt validators and hosts

A handful of niche services generate, validate, and sometimes host app-ads.txt specifically.

Pros.

  • Built-in syntax validation catches malformed lines before they go live.
  • Some services suggest missing lines based on the ad networks you use.
  • Narrow scope keeps the tool simple to learn.

Cons.

  • The hosted path relies on a small vendor staying online for years.
  • Does not solve the rest of your compliance stack.
  • Limited track record compared with general static hosting.

Best for. Developers who want a validator as a checkpoint before pushing the file to their own host.

How AppLander Hosts app-ads.txt

AppLander ships app-ads.txt hosting as part of each app's public subdomain. Each app gets a stable HTTPS URL at yourapp.applander.io (or a custom domain), and /app-ads.txt serves automatically from an editable list in the dashboard.

You manage the resellers list as a structured form rather than raw text, which catches format mistakes — missing commas, the wrong relationship keyword, extra whitespace before an ID. When you add a new ad network through the SDK picker, the dashboard prompts you to add its required lines.

Because the file lives on the same per-app subdomain as your privacy policy, terms, support page, FAQ, account deletion page, and landing page, one login updates everything buyers and reviewers cross-check. The landing page is also what you point your store Marketing URL at, so one subdomain satisfies both the discovery rule and the store developer URL requirement.

Honest limitations. If your store developer URL points to a custom marketing domain you already own, buyers fetch yourgame.com/app-ads.txt and AppLander cannot host a file there — you can still manage and export the contents, but hosting stays on your domain. And if app-ads.txt is the only compliance asset you need, a static host is simpler.

Decision Table

Approach Discovery URL Validation Updates on SDK change Other compliance assets
Self-host (Netlify, Pages) Your domain, manual None Manual No
No-code builder Your domain, manual None Manual Marketing page only
Dedicated validator host Provider domain, manual Built-in Manual No
AppLander Per-app subdomain, automatic Built-in form SDK picker prompts Policy, terms, FAQ, support, deletion, landing, changelog, status

Pick a static host when app-ads.txt is the only file you need; pick AppLander when you are already juggling several compliance assets per app.

Step-by-Step Walkthrough

  1. Find your developer URL in App Store Connect (App Information → Marketing URL) and Play Console (Store settings → Website). They can differ.
  2. Pull the required lines from every ad partner. AdMob, AppLovin, Meta, Unity, ironSource, Pangle, and Liftoff publish their exact expected entries. Copy, do not retype.
  3. Assemble one file, one record per line, no blank lines at the top.
  4. Upload to the root of each developer URL so https://yourdomain.com/app-ads.txt returns with content-type text/plain.
  5. Validate externally with the IAB Tech Lab reference validator or AdMob's built-in checker.
  6. Re-check a week later. Buyers crawl on a schedule, so fill-rate effects are delayed.

Frequently Asked Questions

Does app-ads.txt apply if I only use one ad network?

Yes. Most major ad networks will warn you or suppress eligible demand if the file is missing. One-line files are valid.

Can I put app-ads.txt on a subdomain like apps.mydomain.com?

Only if apps.mydomain.com is the exact URL in your store developer URL field. Discovery is string-deterministic: buyers fetch the URL you registered plus /app-ads.txt.

What goes in the CERT_ID field?

The TAG certification authority ID issued for the seller. It is optional in the spec. Leave it out if your ad network does not give you one.

Do I need both ads.txt and app-ads.txt?

Only if you also serve ads on a website. If you only ship a mobile app, app-ads.txt on your developer URL is the one file you need. See the mobile app launch compliance checklist for the rest of the submission prerequisites.

How often should I update the file?

Every time you add, remove, or swap a mediation partner, plus a quarterly sanity check. Stale files do not throw errors; they silently cut fill rate.

Conclusion

app-ads.txt is a small file with an outsized effect on ad revenue. The spec is straightforward; the operational reality is that most developers forget it exists until an SSP stops bidding. Host it anywhere that serves plain text from your store developer URL — a static site, a builder page, or AppLander, where it lives alongside the rest of the compliance assets every mobile submission now requires.

Sources

Ship your app faster with AppLander

The all-in-one compliance and landing-page platform for mobile app developers.

Start Free