A deep link is supposed to save the user a few taps: open a push notification, land directly on the relevant order, skip the home screen entirely. Done well, it feels instant. Done poorly, it drops the user onto a screen with no back button that goes anywhere useful, no bottom navigation state that matches where they landed, and no way back to the app's normal flow except force-quitting and reopening it.
That second outcome is far more common than it should be, and it almost never comes from getting the link routing wrong. It comes from treating a deep link as "open this screen" instead of "recreate the navigation state a user would be in if they'd tapped their way here naturally."
Why Deep Links Break Navigation State So Often
Most app navigation is built around the assumption that a user arrived at any given screen by tapping through the screens before it. A product detail screen assumes there's a category listing behind it in the back stack. A comment thread assumes there's a post view behind it. That assumption holds for organic in-app navigation and breaks the instant a user lands directly on that screen from outside the app.
A deep link that only pushes the destination screen onto an otherwise empty stack technically shows the right content, but it silently violates every assumption the rest of the navigation was built on. The back button has nothing sensible to go back to. Tab state, if the app uses bottom tabs, may not reflect where the user actually is. The user experiences this as the app feeling broken, even though the specific screen they landed on rendered correctly.
Reconstructing the Back Stack, Not Just the Destination
The fix is deceptively simple to state and genuinely fiddly to implement well: when a deep link opens a screen, the app should synthesize the back stack that would exist if the user had navigated there normally, not just push the single destination screen. Landing on a product detail page from a notification should push a category or search results screen behind it, even though the user never actually visited that screen this session, so that pressing back takes them somewhere coherent instead of straight out of the app.
Apple's Human Interface Guidelines and Android's app architecture documentation both address this pattern, though from different framing angles, since the underlying navigation stack concept differs somewhat between iOS and Android. The principle carries across both platforms regardless of the specific APIs: the back stack a deep link produces should be indistinguishable, from the user's perspective, from one built through normal taps.
Photo by Ivan S on Pexels
Universal Links and App Links Add Their Own Wrinkle
Universal Links on iOS and App Links on Android let a regular web URL open directly in the app instead of a browser, which is the mechanism behind most modern deep linking. The wrinkle is that these links have to work in three distinct states: the app already running in the background, the app cold-started from a terminated state, and the app not installed at all, falling back to a web page or app store listing.
Each of these three paths needs its own navigation reconstruction logic, and it's common to see teams thoroughly test the "app already open" case, since it's the easiest to trigger during development, while the cold-start case gets far less attention and ships with subtly broken back-stack behavior that only shows up when a real user taps a link from a truly closed app.
Handling Android's Intent Filters and iOS's Universal Link Association Files
Both platforms require upfront configuration before a link can even reach the app's routing logic. Android relies on intent filters declared in the app manifest, matching specific URL patterns to the activity that should handle them, documented in Android's App Links guide. iOS requires a hosted apple-app-site-association file on the domain itself, verified against the app's associated domains entitlement, covered in Apple's Universal Links documentation.
Misconfiguring either of these doesn't produce a navigation bug, it produces a link that falls through to the browser entirely, silently, with no error surfaced anywhere obvious. This is a common early debugging trap: engineers spend time debugging in-app routing logic for a link that never actually reached the app in the first place because the association file wasn't correctly hosted or the intent filter didn't match the exact URL pattern being tested.
Handling Deep Links That Require Authentication
A deep link to a screen that requires the user to be logged in adds another layer: if the user isn't authenticated when the link opens, the app has to route through login first and then resume the original destination afterward, rather than either failing silently or dropping the user on a generic home screen after they authenticate. Losing the original destination after a login detour is one of the most common deep-linking complaints in app store reviews, and it's almost always a state-management gap rather than a routing bug, the destination was known at link-open time and simply wasn't carried through the login flow.
Deep Link Analytics Are Worth Building In From the Start
Tracking which deep links get tapped, and whether they successfully reach their intended destination versus falling back to a generic screen, closes the loop between "we implemented deep linking" and "deep linking actually works for real users." Without this, a broken link pattern can persist for months, quietly degrading a notification or marketing campaign's effectiveness, with nobody noticing because there's no error, just a slightly lower engagement number nobody traced back to the actual cause. Attribution and analytics SDKs like Branch and Firebase Dynamic Links' successor tooling build this tracking in alongside the linking mechanism itself, which is usually easier than instrumenting it entirely by hand after the fact.
Testing Deep Links Requires More Than Tapping a Link Once
A deep link that works when tapped from a notification while the app sits in the background can behave completely differently when the app is fully closed, or when the user is mid-session on an unrelated screen already several levels deep in their own navigation stack. A reasonable test matrix covers, at minimum: app closed, app backgrounded, app open on an unrelated screen, and app open on a screen that conflicts with the deep link's destination, like tapping a link to screen A while already mid-flow filling out a form on screen B.
Skipping any of these states in testing is exactly how a deep link ships working fine in the common case and breaking specifically for users who tap a notification while doing something else in the app, which is a meaningfully large share of real usage.
"The deep links that actually cause support tickets are never the ones that fail outright, they're the ones that open the wrong screen state quietly. Users don't file a bug report for 'the back button did something weird,' they just stop trusting the notification and stop tapping it next time." - Dennis Traina, founder of 137Foundry
Deferred Deep Linking for New Installs
A harder variant is deferred deep linking: a user without the app installed taps a link, gets routed to the app store, installs the app, and the app should still open to the originally intended destination on first launch rather than a generic home screen. This requires passing the intended destination through the install process itself, typically via a referrer parameter or an attribution SDK, since the app has no way to read the original URL once it's been replaced by an app store listing in the middle.
Getting this right matters disproportionately for marketing-driven traffic, a link shared in an email campaign or an ad, where the gap between "tap and land exactly where promised" and "tap and land on a generic home screen and have to search" is a real drop-off point in conversion.
What a Solid Deep Linking Setup Actually Looks Like
Pulling the above together, a deep linking implementation that holds up in production consistently does a few specific things: it resolves the destination screen and reconstructs a sensible back stack rather than just pushing one screen, it handles the cold-start and pre-authentication cases with the same care as the simple already-open case, and it preserves the intended destination through a login detour or a fresh install rather than dropping it once a required step interrupts the flow.
None of these are exotic engineering problems, but they're the kind of detail that's easy to skip under a deadline because the simple version, "make the notification open the right screen," appears to work in a quick demo. The gap only shows up once real users hit the edge cases a demo never covers.
Revisiting Deep Links After a Navigation Redesign
Navigation structures change as an app grows: tabs get reorganized, a flat list becomes a nested category tree, a single detail screen splits into a summary and a detail view. Every one of these changes can invalidate the back-stack reconstruction logic a deep link relies on, since that logic was written against the navigation structure that existed at the time. A deep link handler that hasn't been revisited since a major navigation change is a strong candidate for producing exactly the broken-back-button experience this whole approach was built to prevent, just for a different, newer reason than the original implementation had to handle.
Where This Fits Into a Broader App Development Effort
Deep linking is rarely the headline feature of a mobile app, which is exactly why it tends to get built once and left alone, quietly accumulating edge cases as the app's navigation structure grows around it. Revisiting it after a major navigation redesign, rather than assuming old deep link handlers still produce a coherent back stack, catches drift before it reaches users.
137Foundry's app development team builds and audits navigation and deep linking as part of broader mobile and web application work, treating it as core infrastructure rather than an afterthought bolted on after the main screens are built. For a broader look at how our team approaches building applications that hold up as they grow, visit 137Foundry's services page or learn more about our team.
