Key Takeaways

• 76% of Google Play apps don't have app-ads.txt. Six years after the specification launched, adoption is still a minority sport outside the top publisher tier.
• The problem is structural, not just educational. Apps are built by developers, not ad operations specialists. The people coding the app often have no idea that a text file on a separate website affects their ad revenue.
• The multi-system setup is a barrier. Unlike ads.txt (one file on one domain), app-ads.txt requires coordination between the app store, a developer website, and multiple ad network dashboards. Each handoff is a failure point.
• Mediation complexity multiplies the problem. An app using AdMob Mediation with 8 ad networks needs 8+ entries. Most developers only add the AdMob entry and miss the rest.
• The absence of visible consequences delays action. There's no error message, no dashboard alert, no app store warning when app-ads.txt is missing. Revenue just silently underperforms.

---

Why Many Apps Still Get app-ads.txt Wrong

The IAB Tech Lab released the app-ads.txt specification in March 2019.

Six years later, approximately 76% of Google Play apps still don't have it. Among the top 1,000 apps, adoption reaches 66%. But once you move outside the top tier, the numbers drop sharply.

This isn't a case of publishers being lazy. The low adoption rate reveals structural problems in how app monetization works, who's responsible for it, and how feedback loops (or their absence) shape behavior.

The Developer-Ad Ops Gap

The most fundamental reason apps get app-ads.txt wrong: the people building apps and the people managing ad monetization are rarely the same person. And for indie developers, there often is no ad ops person at all.

A mobile game developer's workflow is: code the game, integrate an ad SDK (usually through a mediation platform), configure ad placements, submit to the app store, and monitor revenue in a dashboard.

At no point in this workflow does anyone mention a text file that needs to be hosted on a separate website.

The ad SDK integration documentation mentions app-ads.txt, usually in a footnote or an "optional but recommended" section. The developer skips it because it seems peripheral to getting ads working. And ads do work without it. The developer sees impressions and revenue. They have no baseline to know what they're missing.

This gap exists because app-ads.txt lives at the intersection of web hosting, app store configuration, and ad operations. Developers handle the code. Hosting people handle the website. Ad ops handles monetization. Nobody owns the intersection.

The Multi-System Coordination Problem

Setting up ads.txt for a website is one operation: put a file on your domain. Done.

Setting up app-ads.txt requires three systems working together:

1. App store metadata (Google Play Console or App Store Connect) must include the correct developer website URL
2. A developer website must exist, be accessible over HTTPS, and host the file at the root path
3. Ad network dashboards must be consulted for the correct entries, publisher IDs, and relationship types

Each system is managed by different tools, sometimes by different people, with different update cadences. The coordination overhead isn't enormous, but it's enough to prevent action. Especially for a developer who sees "set up app-ads.txt" as one item on a 50-item launch checklist.

Mediation Makes It Worse

Modern mobile ad monetization typically uses mediation: a platform like AdMob Mediation, AppLovin MAX, or ironSource LevelPlay that manages multiple ad networks in a waterfall or bidding setup.

A typical mediation configuration might include:

• Google AdMob (primary)
• AppLovin
• Unity Ads
• InMobi
• Meta Audience Network
• Chartboost
• Vungle (Liftoff)
• ironSource

That's 8 networks. Each of these networks issues bid requests for your app inventory. Each one needs an entry in your app-ads.txt file. That's 8+ entries, each requiring you to log into a separate dashboard, find the correct publisher ID, determine the relationship type, and copy the formatted line.

What actually happens: the developer adds the AdMob entry (because Google's documentation is the most prominent) and calls it done.

The other 7 networks run unverified. Those networks show "poor performance" in the mediation dashboard. The developer blames the networks, removes some of them, and concludes that their mediation setup needs fewer partners. The real problem was never the networks.

No Visible Error Messages

When your Android app crashes, you get a stack trace. When your build fails, you get a compiler error.

When your app-ads.txt is missing or broken, you get nothing.

No app store warning. No ad network alert (until Google's 2025 requirement). No DSP notification. No dashboard flag. Revenue just underperforms relative to what it could be.

This absence of feedback is devastating for behavior change. Developers respond to explicit errors. They don't respond to invisible opportunity costs. An app that earns $8,000/month without app-ads.txt could earn $10,000/month with it, but the developer has no way to see the missing $2,000. They just see $8,000 and think "that's what my app earns."

Google's 2025 requirement changes this for AdMob by making verification mandatory. When ads stop serving, that's an explicit error. But for non-Google demand, the silent underperformance continues.

The "It's Working Without It" Trap

Ads serve without app-ads.txt. Revenue appears in the dashboard. This creates a dangerous illusion that the file is unnecessary.

What the developer doesn't see:

• DSPs that refused to bid because inventory was unverified
• Brand campaigns that excluded their app from consideration
• Quality score reductions from ad networks due to missing verification
• The CPM premium they would receive from verified demand

The gap between "ads are working" and "ads are working at maximum potential" is invisible without A/B testing or industry benchmarking. Most developers lack both.

Hosting Is Not Natural for App Developers

App developers build for app stores, not the web.

Many indie developers and small studios don't have a website at all. Creating a website specifically to host a text file feels like overhead with unclear benefit.

Even developers who have a website may not control it directly. The marketing team manages the website. The developer manages the app. Getting a single text file deployed to the website root requires cross-team coordination that's disproportionate to the perceived value of the task.

Firebase Hosting and similar free options lower this barrier, but they still require the developer to create an account, configure hosting, deploy a file, and link the URL in the app store. For a developer focused on shipping features, this is a distraction.

The Ongoing Maintenance Burden

Setup is one barrier. Maintenance is another.

app-ads.txt needs to be updated whenever:

• A new ad network is added to mediation
• An existing network is removed
• An ad network changes its exchange domain or account ID structure
• The developer changes their website URL

Each of these changes requires remembering that app-ads.txt exists and needs updating. For teams without ad operations specialists, this maintenance doesn't happen. The file decays. New networks run unverified. Old networks clutter the file. The gap between the file and reality widens with every mediation change.

What Is Changing

Several forces are pushing toward higher adoption:

Google's 2025 mandate. Requiring app-ads.txt for AdMob is the biggest forcing function. Developers who want Google ad revenue must comply. This alone will push adoption numbers up.

Mediation platform integration. Some mediation platforms are beginning to auto-generate app-ads.txt entries or flag missing ones in their dashboards. This reduces the cross-system coordination burden.

Ad revenue optimization tools. Tools that analyze ad monetization performance are increasingly flagging app-ads.txt issues as revenue improvement opportunities.

Industry education. As SPO becomes standard practice among buyers and more ad spend flows to verified-only inventory, the business case for app-ads.txt becomes clearer and more urgent.

What Developers Should Do

If you've made it this far, here's the minimum viable action:

1. Check if you have app-ads.txt. Visit your app store listing, click the developer website link, append /app-ads.txt. If you get a 404, you don't have it.
2. If you don't have a developer website, create one. Firebase Hosting, Netlify, or any free static host. 15 minutes.
3. Collect entries from every ad network in your mediation. Not just AdMob. All of them.
4. Host the file and verify the chain. App store listing > developer URL > file accessibility.
5. Set a quarterly reminder to review. Mediation changes, network changes, seller.json changes. The file needs attention.

The 30 minutes you spend on this is the highest-ROI time investment in your entire ad monetization stack.

Frequently Asked Questions

Will Google require app-ads.txt for all apps eventually?

All indications point to yes. The January 2025 requirement covers new apps. Google is rolling out the requirement to existing apps throughout 2025. The end state is likely universal mandatory verification for all AdMob-monetized apps.

Why did it take so long for app-ads.txt adoption to grow?

Three factors: the developer-ad ops gap (builders don't know about it), the absence of visible consequences (no errors when missing), and the multi-system coordination requirement (harder to set up than ads.txt). Google's mandate is the forcing function that was missing.

Is 24% adoption across all apps a real problem?

For the ecosystem, yes. Low adoption means DSPs can't fully verify mobile inventory, which reduces buyer trust in the entire mobile programmatic channel. For individual developers, it's actually an opportunity: setting up app-ads.txt when most competitors haven't gives you a verification advantage.

How do I know if my app-ads.txt is actually working?

Check your ad network dashboards for verification status. AdMob shows this explicitly. For broader verification, use BeamFlow's scanner to validate your entries against sellers.json data across all your ad networks.