A link that opens
the exact screen, not the app's front door
A shared link that opens an app but drops the user at the home screen, leaving them to find the actual product or page themselves, loses most of the value of sharing it in the first place. Deep links route a URL, a push notification tap, or a search result straight to the specific screen it refers to, inside an already-installed app or through the right app store if it is not installed yet.
What it is
A deep link is a URL that, when opened, routes directly to a specific screen inside an app, a product page, a user’s profile, a specific workout, rather than just launching the app to its default home screen. Universal Links on iOS and App Links on Android are the modern, reliable mechanism for this: real https:// URLs that the operating system recognizes and hands to the app if it is installed, or falls back to a web page or app store listing if it is not.
When you need it (and when you do not)
It earns its cost the moment anything in your product gets shared or linked to from outside the app: a workout shared to a friend, a product linked from an ad, a push notification that should open the exact thing it is about. TaskWall uses deep links so a shared task list link opens directly to that list rather than the app’s home screen, and a fitness app’s shared workouts and referral links rely on the same mechanism to land a new user exactly where the context implies they should land.
It is the wrong tool, or simply unnecessary, for an app with no sharing, no marketing links pointing at specific content, and no push notifications that reference a particular screen; if every entry point into the app is genuinely just “open the app,” deep linking infrastructure has nothing to route. We check this before recommending the work.
How we build it
We set up Universal Links on iOS and App Links on Android, which require a signed association file hosted on your domain proving your app is allowed to handle that domain’s links, rather than relying on the older custom URL scheme approach, which fails in exactly the contexts, messages, social apps, email clients, where sharing actually happens, since many of them strip or refuse to open custom schemes for security reasons.
Routing logic inside the app maps every link pattern to the actual screen it represents, built alongside the app’s real navigation structure rather than as a separate afterthought system, so a new screen added later gets its deep link route defined as part of adding the screen, not bolted on in a separate pass. For users who do not have the app installed yet, the link falls back gracefully: a web page showing the same content, or a redirect to the correct app store listing, and with deferred deep linking, the destination is remembered through the install process so the app opens directly to it the first time it launches.
Where it is relevant, we set up app indexing so Google can surface specific screens inside your app in search results for users who already have it installed, reusing much of the same link-to-screen mapping. Attribution tracking is layered on top so you can see which campaign, share, or notification actually drove a given app open, not just that opens happened.
What to watch
The association file that proves domain ownership for Universal Links and App Links needs to stay correctly configured and accessible; a broken or missing file silently degrades deep links back to the unreliable custom-scheme fallback without any obvious error, so we verify it as part of every deploy that touches the domain configuration. Deferred deep linking through an app store install adds a third-party attribution service to the stack in most implementations, which is a dependency and occasionally a privacy consideration worth being deliberate about, we use it only where the deferred case genuinely matters to the product. And link routing needs to be maintained as the app’s screens change, a route pointing at a screen that got renamed or removed needs a deliberate redirect, not a broken link discovered by a confused user.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Core deep linking | from $1,200 | Universal Links, App Links, routing to core screens | 1 to 2 weeks |
| Full system with attribution | from $3,000 | Deferred deep linking through install, attribution tracking, app indexing | 2 to 3 weeks |
Running cost is close to zero for the core setup; a deferred linking and attribution service typically runs $0 to $100 a month depending on volume.
Related
This pairs with push notifications infrastructure so a notification opens the exact screen it refers to, and with in-app subscriptions (App Store, Google Play) for linking directly to an upgrade screen from a marketing campaign. See the development service page for our full build process. For real examples, see TaskWall’s shared task list links and the fitness app’s shared workouts and referral links.
Sharing links that drop people at your app’s home screen instead of the actual content? Get in touch and we will set up routing that actually gets them there.
FAQ
How much does deep link setup cost?
From $1,200 for Universal Links and App Links across iOS and Android with routing to your core screens, 1 to 3 weeks. Adding deferred deep linking through install and full attribution tracking runs $2,500 to $4,500.
What is the difference between a custom URL scheme and Universal Links?
A custom URL scheme (like myapp://) only works if the app is already installed and the user is already inside a context that recognizes it; it fails silently or opens nothing useful otherwise. Universal Links on iOS and App Links on Android use real https:// URLs that work whether the app is installed, not installed, or the link is clicked from any context, including messages and social apps that strip custom schemes for safety.
What happens if the app is not installed yet?
The link falls back to a normal web page, or redirects to the right app store listing, and with deferred deep linking, remembers where the user was trying to go so the app opens directly to that screen the first time it launches after install, instead of dropping them back at the home screen having lost the context entirely.
Does this help with app store discovery too?
App indexing lets Google surface specific screens inside your app in search results when a user searches for something your app covers, which is a separate but related mechanism from deep linking a shared link; we set up both together since they reuse much of the same routing logic.
Who owns this setup?
You. The associated domain files, the app's routing logic and the attribution configuration live in your own infrastructure and repository.