When Meta rejects your App Store URL
A rule that seems arbitrary until you see what it pushes advertisers into, which is the arrangement where taps quietly die.
6 August 2026 by PAD team
The rule
Traffic objectives on Meta expect a web destination. Point one at apps.apple.com and it is refused at the ad level, with a message about using the app promotion objective instead.
The logic is defensible: traffic campaigns optimise for landing page views, and a store URL is not a landing page Meta can measure.
The three workarounds
| Approach | What it costs you |
|---|---|
| Switch to app install objective | different optimisation and often different economics |
| Send to a landing page with a Download button | one extra step, and the store link problem moves to the end |
| Send to a tracker link | accepted as a web URL, same problem one hop later |
Where each one bites
The install objective genuinely avoids the browser, because Meta opens the store natively from the Install button. If your economics work on that objective, take it and stop reading.
The other two put a web page in front of the store, which means the final tap happens inside Meta's in-app browser. That is where store links fail, so the workaround for the ad policy creates the conversion problem.
Making the landing page route work
If you need a landing page, whether for a quiz, a paywall preview or a policy reason, the Download button at the end has to escape the in-app browser rather than link straight to apps.apple.com. That is a change to one link, not to the funnel.
The mechanism, with code, is in the main write-up.
A note on what gets rejected
Rejections also happen for URLs Meta considers redirect chains, cloaking or mismatched with the ad content. If your routing link is refused, check that the visible destination in the ad matches where the visitor actually lands, since that is the rule being enforced.
A routing link is accepted as a web destination and gets the final tap out of the in-app browser.