On iOS, a tap that ends on apps.apple.com inside an app's own
browser can end on an empty screen. Not your creative, not your landing page:
Apple hands the store off through a scheme that browser cannot open. An
attribution link does not save you. It only measures the loss.
Traffic and conversion ads · W2A funnels and quizzes · bio, Stories and DMs · influencer posts · OneLink, Branch, Adjust, Singular and Kochava, attribution intact
Paste the link you use in your bio, ads or funnel. We request it exactly as an iPhone would and show you what comes back. No account needed.
Works with store links, tracker links and your own landing pages.
The rule is short. If the tap runs inside an app's own browser and the chain ends on the App Store, it can die there, no matter how it started, how many redirects sit in the middle or who measures them. An organic tap costs you a person. A paid one costs you a person and the money you spent on them.
| Where the tap comes from | On iOS | Why |
|---|---|---|
| App install campaign, Advantage+ App | Arrives | Meta opens the store natively from the Install button, with no browser in between |
| Traffic, engagement, conversion ads | Dies | The tap opens in the same in-app browser as any other link |
| W2A funnel: ad → landing → store | Dies | The ad and the landing page are fine. The Download button at the end is what breaks |
| Attribution link anywhere in that chain | Dies | OneLink, Branch, Adjust and the rest end on the store URL themselves |
| Bio link, Linktree, Stories, DMs | Dies | Same WebView, no ad spend attached, so you only lose the person |
| Influencer and UGC posts | Dies | You pay per post and never learn how many taps ended on an empty screen |
| Telegram, WhatsApp, Snapchat, X, LinkedIn | Dies | Every one of them ships its own in-app browser |
| Email or push opened inside an app | Dies | The link inherits whatever browser the app happens to embed |
| QR code, typed URL, normal browser | Arrives | Safari and Chrome hand the store scheme off the way Apple intended |
There is a second trap in the paid setup. Meta refuses a raw App Store URL in a traffic campaign and tells you app URLs belong to the app install objective, so you put an attribution link or a landing page in the ad instead. The chain gets longer. The last step is unchanged.
W2A is the setup most app teams run now: the ad points at a landing page or a quiz, the page warms the person up, and a Download button sends them to the store. Everything up to that button works: the page renders inside the in-app browser like any web page. The button is the step that fails, and it fails after you have already paid for the click and earned the intent.
The ad, the landing page, the quiz, the paywall and your analytics do not change. You swap the address behind the Download button, nothing else.
If the button already points at a OneLink or a Branch link, that link becomes the destination and keeps measuring the tap the way it does today.
Give each placement or creative its own link under the same app. The dashboard splits taps by platform and by source app, so you can see which placement bleeds.
Ads, funnel buttons, bio links: count every tap that starts inside an app. Put in your own numbers: the math runs on what you type, not on our averages.
The failure share moves with whichever iOS and Instagram build your audience happens to be on, so start with an estimate. Once your links are live you stop guessing: each one reports when every route out was blocked, and the dashboard turns that into a delivery rate.
You publish yourapp.gotoapp.store instead of the raw store URL.
It reads where the tap came from and picks the route that survives there. If
the platform blocks that route, it tries two more before giving up.
| Where the tap comes from | What the link does |
|---|---|
| Instagram and Threads, iOS | Hands off to the external browser, then straight into the App Store |
| TikTok and Facebook, iOS | Tries Safari via x-safari-https://, which those apps increasingly intercept, then drops to the route below |
| iOS, handoff blocked | Falls back to itms-appss://, the store's own scheme |
| iOS, everything blocked | Shows a single visible button, so the tap is never a dead end |
| Android in-app browsers | intent:// handoff to Chrome, with Play as the fallback |
| Destination is an attribution link | We only get the tap out of the WebView; your tracker does the routing and the attribution from there |
| Destination is your own page | Your W2A funnel opens in the real browser, where payments, cookies and analytics behave normally. Verify the domain once |
| App already installed | Opens the app through your deep link instead of the store, with the store as the fallback |
| Normal browser | Goes to the store directly, with no interstitial in between |
| Desktop | Your website |
The handoff happens on its own. The button shows up only when every route is blocked, so most people never see it.
Nothing to add to your app or your site. You swap one URL in your bio, Stories and DMs.
Instagram's external-browser route is undocumented and Meta can change it. All the routing logic sits in one file. When Meta changes something, we fix it there and every client's links keep working.
Every tap is logged by platform and source app, and the link reports back when every route out was blocked. So the dashboard shows a delivery rate, not just clicks. It is the number nobody else can hand you.
A Bitly link or an ordinary server redirect to apps.apple.com
still lands inside the same in-app browser and hits the same wall. It adds a
hop without escaping the WebView. The tap has to leave the in-app browser
first, and each source app needs its own route out.
An attribution link behaves the same way, and this one surprises people.
OneLink, Branch, Adjust, Singular and Kochava measure the tap. They do not change
where it runs. Whatever the tracker does in the middle, its last step
is apps.apple.com, Apple answers with a redirect to
itms-appss://, and the WebView still cannot open it. You end up
with precise measurement of a tap that never arrived.
This is what makes attribution links deceptive rather than merely useless here. A raw store link that dies leaves an obvious gap between clicks and installs. A tracker that dies reports the click as normal, so the loss reads like a weak creative or a bad audience.
Paste your OneLink, Branch, Adjust, Singular or Kochava URL as the destination instead of the store address. We accept it as a destination the same way we accept a store link.
We get the tap out of the in-app browser and hand it to your tracker, which does its own routing from there. We do not rewrite your parameters and we do not clip anything onto them.
An attribution link already splits iOS and Android on its own, so you fill one field and both platforms route through it.
We will not promise permanent compatibility, because nobody honestly can: the Instagram route is undocumented. We do commit to keeping it current and to shipping fallbacks, so a blocked route ends on a visible button instead of a blank screen.
The routing, the fallbacks and the stats are the same on both plans. Pro buys you the subdomain, so the link reads as your app instead of ours.
Up to 3 apps, unlimited links under each of them, full routing with every fallback, clicks by platform and source app, daily chart.
Up to 25 apps, each on its own subdomain. Shorter in a bio, cleaner in a Story, and it keeps working if you later move the name to your own domain.
Your app name is reserved the moment you sign up, on either plan. Upgrading switches the format and leaves everything you already published on the free address working.
Instagram opens links in its own in-app browser instead of Safari. Apple
redirects apps.apple.com to the itms-appss:// scheme,
and the in-app browser cannot hand that scheme off to the App Store, so the
page ends up empty.
The tap has to leave the in-app browser before Apple's redirect fires. GoToApp does that automatically: it detects Instagram, hands the visitor to the external browser and lands them in the App Store, with two fallbacks if the platform blocks the first route.
No. A short link or an ordinary server redirect still resolves inside the same in-app browser and hits the same wall. It adds a hop without escaping the WebView.
It affects paid traffic too. App install campaigns are safe: Meta opens the store natively from the Install button, with no browser in between. Traffic, engagement and conversion campaigns send the tap into the same in-app browser as a bio link, so the store link dies the same way, except the click is already paid for when it does.
No. An attribution link measures the tap, it does not change where the tap
runs. Whatever the tracker does in the middle, its last step is
apps.apple.com, and Apple answers that with a redirect to the
itms-appss:// scheme the in-app browser cannot open. The tracker
adds a hop inside the same WebView.
Yes. Paste your attribution link as the destination instead of the store URL. We get the tap out of the in-app browser and hand it to your tracker, which does its own routing and attribution from there. We do not rewrite your parameters, and one attribution link covers both iOS and Android.
Only on the last step, which is what makes it easy to miss. The ad, the landing page and the quiz all render inside the in-app browser like any web page. The Download button at the end points at the App Store, and that is where the chain dies, after you have paid for the click and earned the intent. Point that button at a GoToApp link and the rest of the funnel stays exactly as it is.
Anything that opens a link in the in-app browser: traffic, engagement, conversion and lead campaigns, plus every W2A funnel behind them. App install campaigns are not affected, because Meta opens the store natively from the Install button. Meta also refuses raw App Store URLs in traffic campaigns, which is why so many setups route through a landing page or a tracker in the first place.
Every app that ships its own in-app browser: Instagram, Facebook, Threads, TikTok, Snapchat, X, LinkedIn, Pinterest, Telegram and WhatsApp, as well as email and push links opened inside them. QR codes, typed URLs and normal browsers are fine, because Safari and Chrome hand the store scheme off the way Apple intended.
Yes, once you verify the domain. You upload one static file to prove the domain is yours, and after that your own page can be the destination. That matters for W2A funnels: a page opened in the real browser has working payments, cookies and analytics, which an in-app browser often breaks. Without verification we only accept store and attribution links. Otherwise the service would be an open redirector and would be abused for phishing within a day.
Yes. Keep the base attribution link in the dashboard and pass the personal
part in the address: we take the parameters off your address, put them on the
base link and hand the result to the browser. A Smart Script link with a
per-user deep_link_value works that way in one line on your
landing page. The destination domain stays the one you saved, so nothing
turns into an open redirect. Turn it on with one checkbox, and the dashboard
then shows the exact snippet for your link.
Add a deep link and the tap opens the app itself instead of its store page. We try the deep link first and fall back to the normal routing if nothing happens, so people without the app still reach the store. Your app scheme works out of the box; a universal link needs the domain verified.
The link reports back when every route out was blocked and the visitor saw the fallback button. Your dashboard turns that into a delivery rate: how many taps left the in-app browser and how many got stuck. It is the one number an ordinary click counter cannot give you, because a dead tap still counts as a click everywhere else.
Yes. On Android in-app browsers the link hands off to Chrome through an
intent:// URL, with Google Play as the fallback. Desktop visitors
go to your website.
No. You replace the store URL in your bio, Stories and DMs with one link. You add nothing to the app or to your website.
The external-browser route is undocumented and Meta can change it. We keep all the routing in one file and update it for every link at once, and a blocked route falls back to a visible button instead of a blank screen.
Sign up, pick your app name, paste your store URLs, or your OneLink, Branch
or Adjust link, if that is what your ads run on. You get
yourapp.gotoapp.store and as many links under it as you need, one
per campaign, per placement or per Download button in your W2A funnel, each
with its own click stats by platform and source app.
Leave your contact and we'll set the first link up with you.
What we learn from routing taps out of in-app browsers. Failure rates come from our own traffic.
Apple's redirect into itms-appss://, why a WebView cannot follow
it, and the four escape routes with code.
Which objectives lose taps, why Facebook is the hardest platform to escape, and what a fifth of a budget looks like.
TikTokTwo complaints with opposite causes, and the ten-second test that tells them apart.
CodeMarkers for ten apps, a detection function, and what changed in iOS 26 when Facebook stopped identifying itself.
Universal linksThe apple-app-site-association checklist in the order things
break, and the cases iOS refuses on purpose.
We run paid traffic for mobile apps, so we hit this bug on our own campaigns before we built a product around it.
Mobile marketing agency: user acquisition, ASO and in-app advertising for apps in the App Store and Google Play.
pad.team →A service for building sales funnels in Facebook Messenger, Instagram and WhatsApp. The conversation stays connected from the first message to the payment, and you see where each user stopped.
leonfunnels.com →An advertising platform for buying placements with Telegram channels, influencers and viral content.
audiencemart.com →