Branch links, and where they stop

For a Branch link, check the app configuration, fallback destination and reporting separately. Then test the route on a device.

19 October 2026 · PAD team

What Branch handles

Link creation at scale, deferred deep linking through its SDK, custom link domains, a debugger for inspecting how a specific link resolves, and reasonably good analytics on top.

The custom domain part matters more than it sounds. Links on your own domain avoid the reputational baggage that generic shorteners carry with spam filters and social platforms.

The blind spot

A Branch link tapped inside Instagram or Facebook resolves in that app's WebView. Branch's routing logic runs, decides the visitor should go to the App Store, and sends them to apps.apple.com. Apple answers with the itms-appss:// redirect, and the WebView cannot follow it.

Branch recorded everything correctly. The visitor is looking at a white page.

Why this is not a Branch bug

No attribution product can fix this from the outside, because the constraint is in the browser rather than in the link. The only way out is to leave the WebView before the store redirect fires, and that requires a page running code in the visitor's browser, not a server-side redirect.

Combining them

The setup that works: your routing link escapes the in-app browser, then hands the visitor to your Branch link in the real browser, where Branch does its normal job. Nothing changes in your app, your SDK integration or your reports.

If you are choosing

• You need the exact screen after install: Branch, AppsFlyer or Adjust, no way around an SDK
• You need taps to reach the store from social apps: routing, no SDK required
• You need both: routing in front, tracker behind