Why App Store links open a blank page in Instagram, and how to fix it
Someone taps your bio link on an iPhone and lands on a white screen instead of your app. Here is the exact mechanism, the routes out of it, and what our own traffic says about which route survives where.
Published 5 August 2026 by PAD team. Data covers 730 taps routed between 3 and 5 August 2026.
What actually happens
Instagram does not hand links to Safari. It opens them in a WebView it controls, which lets Meta keep the session and measure what you do. That WebView behaves like a browser until it meets something only a real browser can do.
An App Store URL is one of those things. When anything requests https://apps.apple.com/app/id123456789 on an iPhone, Apple's server answers with a redirect to a custom scheme:
GET https://apps.apple.com/us/app/example/id123456789
→ 302 Found
Location: itms-appss://apps.apple.com/us/app/example/id123456789
Safari knows what to do with itms-appss://. It closes the page and opens the native App Store. A WebView has no handler registered for that scheme and no permission to pass it to another application. The navigation simply stops.
Nothing on the page reports an error, because from the WebView's point of view nothing failed. The request was answered, the answer was a scheme it cannot follow, and it stopped there. Your visitor sees white.
Neither company considers this broken. Apple redirects to a custom scheme so the native store opens rather than a web page. Meta keeps visitors in its WebView so it can measure them. The blank page lives where those two decisions meet, and neither side has a reason to move.
Who this hits, measured
Below is every tap that passed through our routing between 3 and 5 August 2026. Small sample, real traffic, no modelling. We publish it because most writing on this problem quotes no numbers at all.
| Source | Platform | Taps | Share |
|---|---|---|---|
| iOS | 240 | 32.9% | |
| iOS | 159 | 21.8% | |
| Regular browser | other | 113 | 15.5% |
| Regular browser | desktop | 98 | 13.4% |
| Regular browser | iOS | 69 | 9.5% |
| Regular browser | Android | 26 | 3.6% |
| TikTok | iOS | 20 | 2.7% |
| Android | 3 | 0.4% | |
| Android | 2 | 0.3% |
Two things stand out.
The first: 424 of the 730 taps arrived from inside a social app, and 419 of those came from iOS. Android accounted for 5. This is an iPhone problem in practice, whatever the theory says, because Android WebViews can hand a Play Store URL to the Play app through an intent:// URL and iOS WebViews have no equivalent.
The second: Instagram alone carried a third of everything. If you sell an app and you advertise on Meta, roughly one tap in three is arriving through the one browser that cannot complete the journey on its own.
Things that look like fixes and are not
A short link
Bitly, TinyURL, your own /go/abc redirect. The short link resolves inside the same WebView, receives the same Apple redirect, and stops at the same place. You have added a hop.
A 301 or 302 on your own server
Same reasoning. The status code is irrelevant. What matters is which browser is holding the connection when the itms-appss:// redirect arrives, and a server-side redirect never changes that.
An attribution link from OneLink, Branch or Adjust
These are measurement products and they are good at measurement. The tap gets recorded, campaign parameters get carried, and the dashboard fills up. The final navigation still happens inside the WebView and still dies there. You end up with an accurate count of clicks that never reached the store.
Telling people to open it in Safari
It works, and almost nobody does it. Asking a visitor to find the three-dot menu, choose "Open in browser" and wait through a second page load is asking for effort at the exact moment they were ready to install.
The routes that work
All of them share one idea: get out of the WebView before Apple's redirect fires. Order matters, because each has a different failure mode.
1. instagram://extbrowser
Instagram registers a URL scheme that opens a link in the system default browser. It is not in any public documentation, but it has worked across app versions for years.
instagram://extbrowser/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fid123456789
The visitor leaves the WebView, lands in Safari or Chrome, and Apple's redirect resolves the way it was designed to. This is the cleanest route and the one that carries most of our Instagram traffic.
2. x-safari-https
An older iOS scheme that forces a URL into Safari specifically. Coverage across WebView builds is patchy now, so it belongs behind the first route rather than in front of it.
x-safari-https://apps.apple.com/app/id123456789
3. itms-appss, requested directly
Rather than waiting for Apple to redirect you to the scheme, navigate to it yourself. Some WebView builds refuse the https URL but pass the custom scheme through to the App Store.
itms-appss://apps.apple.com/app/id123456789
4. intent, on Android
Android has the mechanism iOS lacks. An intent:// URL names the target package and carries a fallback for the case where it is missing.
intent://details?id=com.example.app#Intent;scheme=market;
package=com.android.vending;
S.browser_fallback_url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.example.app;
end
Code you can paste
The whole thing is a page that decides where to send the visitor and then sends them, with timers to catch each route failing. Roughly:
var ua = navigator.userAgent;
var inInstagram = /Instagram/.test(ua);
var inFacebook = /FBAV|FBAN/.test(ua);
var isIOS = /iPhone|iPad|iPod/.test(ua);
var store = "https://apps.apple.com/app/id123456789";
function go(url) { window.location.href = url; }
if (isIOS && inInstagram) {
go("instagram://extbrowser/?url=" + encodeURIComponent(store));
// the hand-off either happens or it does not, so give it a moment
setTimeout(function () {
go("itms-appss://" + store.replace(/^https?:\/\//, ""));
}, 900);
setTimeout(showManualButton, 2200);
} else if (isIOS && inFacebook) {
go("itms-appss://" + store.replace(/^https?:\/\//, ""));
setTimeout(showManualButton, 1400);
} else {
go(store);
}
Two details decide whether this works in the field.
Fire the first route on page load rather than on a click. A tap that already happened is your permission to navigate; waiting for a second one loses people.
Keep the timers short. Under a second before the fallback, and around two seconds before you give up and show a button. Anything longer and the visitor has closed the page.
Keeping attribution intact
Escaping the WebView is worth nothing if the install lands in the wrong campaign. Both stores read campaign data from the URL, and both survive the hand-off.
On iOS, Apple reads the ct parameter and reports it as the campaign in App Store Connect:
https://apps.apple.com/app/id123456789?ct=summer_reels&pt=YOUR_PROVIDER_TOKEN
On Android, Play reads referrer, and the value should itself be a URL-encoded parameter string:
https://play.google.com/store/apps/details?id=com.example.app
&referrer=utm_source%3Dinstagram%26utm_campaign%3Dsummer_reels
If you already run OneLink, Branch or Adjust, point the escape at the attribution URL rather than at the raw store URL. The measurement product keeps doing its job, and the tap now actually arrives.
Where it still fails
No route is universal, and anyone claiming otherwise has not measured. Our own numbers, same sample:
| Source | Taps | Every route blocked | Rate |
|---|---|---|---|
| 242 | 3 | 1.2% | |
| TikTok | 20 | 3 | 15.0% |
| 162 | 35 | 21.6% | |
| Regular browser | 306 | 0 | 0% |
Instagram is close to solved: 3 taps in 242 reached the manual button. Facebook is a different story, with roughly one in five taps blocked on every automatic route. Facebook's WebView is stricter about scheme hand-offs, and there is no trick that gets past it today.
That is why the last step is a button rather than a spinner. When every route is blocked, the honest move is to tell the visitor plainly what to do and make the target large. About half the people who reach that button use it.
The short version
- Apple redirects store URLs to
itms-appss://, and in-app browsers cannot follow custom schemes - Short links, server redirects and attribution links all resolve inside the same WebView, so none of them help
- The fix is to leave the WebView first, through
instagram://extbrowseron iOS orintent://on Android - Campaign parameters survive the hand-off, so attribution stays intact
- Instagram is nearly always recoverable, Facebook is blocked about a fifth of the time, and a manual button is the only honest answer for the rest
We built the routing above into a link generator, because maintaining this by hand across app updates gets old. Paste your App Store or Google Play URL, get one link that handles every case, and see what came from where.