Teams that know web advertising well often assume apps work the same way with a smaller screen. They don’t. Without a browser, there are no page tags, no domains and no cookies, so almost everything that identifies inventory, users and ad quality works differently. This post walks through the practical differences so app developers and monetization managers can avoid the most common surprises.
SDKs replace the ad tag
On the web, an ad slot is usually a snippet of JavaScript on the page that calls out to an ad server or auction. In an app, that job is done by an SDK (software development kit): a library the developer compiles into the app that requests ads, renders them and reports events such as impressions and clicks.
This has real consequences:
- Changes need a release. Updating an SDK means shipping a new app version and waiting for users to install it. Old versions stay in circulation for a long time.
- App size and stability matter. Every SDK adds weight and potential crash points, so each one should justify its place.
- Mediation is common. Many apps use a mediation layer, a single SDK that decides which of several demand sources gets each impression. That makes the choice and configuration of that layer one of the most important monetization decisions an app team makes.
Some demand also runs through server-side integrations, where the app’s SDK sends one request and the auction happens on a server. That reduces the number of SDKs in the app, but it depends on the app passing good signals to that server.
Bundle IDs replace domains
A website is identified by its domain. An app is identified by its bundle ID in bid requests: on Android this is the package name (for example, com.example.news), while on iOS buyers typically see the numeric App Store ID. The app’s store URL is usually passed as well.
Buyers rely on these identifiers to decide what they’re bidding on, apply brand safety rules and build allow lists. If they’re missing or inconsistent, demand drops. A few habits help:
- Make sure every SDK and server integration passes the same, correct bundle ID and store URL.
- Keep separate IDs for iOS and Android versions of the same app, and don’t mix them in reporting.
- Watch for unfamiliar sellers claiming to sell your bundle ID, which can be a sign of spoofing.
app-ads.txt is how buyers verify you
The IAB Tech Lab created ads.txt so websites could publicly list who is authorized to sell their inventory, then extended the idea to apps with app-ads.txt. Because an app has no domain of its own, the file lives on the developer website listed in the app’s store page. Buyers crawl that site, find the file and check whether the seller in a bid request is on it.
Two practical points trip up app teams. First, the developer URL in the store listing must be correct and must point to the domain where the file is hosted. Second, the file has to be updated whenever a demand partner is added or removed, or legitimate demand may stop bidding. The file syntax and seller relationship types are worth learning in detail, and they deserve a guide of their own.
Device IDs and privacy prompts
With no cookies, apps have historically relied on device advertising IDs: the IDFA on iOS and the Android advertising ID on Android. These let buyers cap frequency, measure conversions and target audiences across apps.
Access to those IDs is now much more restricted, and the rules differ by platform:
- iOS. Apple’s App Tracking Transparency framework requires apps to ask users for permission before accessing the IDFA for tracking. Users who decline, or who never see the prompt, don’t share it. Apple’s SKAdNetwork provides privacy-preserving install attribution without user-level IDs.
- Android. Users can reset or delete their advertising ID in device settings, and apps must follow Google Play’s policies on how the ID may be used.
- Regional consent. In Europe, apps generally need consent under GDPR, and many use the IAB TCF (Transparency and Consent Framework) to collect and pass consent signals to ad partners. US state privacy laws add their own opt-out requirements.
The practical takeaway is that a large share of in-app traffic reaches buyers without a usable device ID. Apps that pass clean contextual signals (app category, content type, placement, device and connection details) and consent strings correctly give buyers something to bid on even without one. Timing and wording of the tracking prompt also deserve testing, since a prompt shown with no context tends to get dismissed.
Formats built for apps
App screens and sessions shape which ad formats work. The main ones are:
- Banners, small persistent units that are easy to add but easy to ignore.
- Interstitials, full-screen ads shown at natural breaks such as between levels or articles.
- Rewarded ads, where users choose to watch in exchange for something of value in the app.
- Native ads, styled to match the app’s own content and layout.
- In-stream and vertical video, which suit feed-based and content apps.
The format decision is really a product decision. Placement, frequency and how each format affects retention matter as much as the price it earns, and that topic needs a deeper look than fits here.
Store policies are part of your ad stack
On the web, a publisher answers mainly to its own policies and its partners. In apps, Apple and Google also have a say. Both app stores publish rules that cover ads, and violations can mean a rejected update or removal from the store.
Areas to review before launch and after any monetization change:
- Disruptive ads. Google Play restricts ads that appear unexpectedly, block app use or are hard to close.
- Children and families. Apps aimed at children face strict limits on ad content, data collection and which ad SDKs they may use.
- Privacy disclosures. Apple’s privacy labels and Google Play’s Data safety section must accurately describe the data your ad SDKs collect.
- Accidental clicks. Placing ads next to buttons or navigation invites misclicks, which store reviewers and buyers both treat as a quality problem.
Treat every new SDK as something that changes your disclosures, not just your revenue.
Key takeaways
- In apps, SDKs replace ad tags, so changes need releases and each SDK should earn its place.
- Bundle IDs and store URLs identify your inventory, and they must be consistent across every integration.
- app-ads.txt lives on the developer website in your store listing and must stay current.
- Device IDs are often unavailable, so clean contextual signals and consent strings matter.
- App store policies on ads, children and privacy disclosures are part of your monetization setup.
Growing in-app, alongside web and CTV, is one of the directions Vortex is focused on. If you manage monetization for an app, see how Vortex works with publishers.
