A link that opens
the exact screen, not the app's front door
A shared link that opens the app but drops the user at the home screen wastes most of its own value. They still have to go find the thing you shared. Deep links send a URL, a notification tap, or a search result straight to the exact screen it refers to. That's inside the app if it's installed, or through the right app store if it's not.
What a deep link actually does
A deep link is a URL that opens a specific screen inside an app, a product page, a profile, a particular workout. It doesn’t just launch the app to its default home screen. Universal Links on iOS and App Links on Android are the reliable way to do this today. Both use real https:// addresses. The operating system hands the address to the app if it’s installed. Otherwise it routes to a web page or the app store listing.
When this earns its cost (and when it doesn’t)
It pays for itself 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 notification that should open the exact thing it mentions, all need this. TaskWall uses deep links so a shared task list opens directly to that list, not the app’s home screen. A fitness app’s shared workouts and referral links work the same way, landing a new user exactly where the link implied they’d land.
It’s the wrong tool, or simply not needed, for an app with no sharing. No marketing links to specific content. No notifications pointing at a particular screen. If every way into the app is really just “open the app,” there’s nothing for deep linking to route. We check for this before recommending the work.
How we set it up
We build Universal Links on iOS and App Links on Android. Both require a signed file hosted on your own domain that proves your app is allowed to handle that domain’s links. That’s more reliable than the older custom URL scheme. The old scheme fails in exactly the places sharing happens: messages, social apps, email clients. Many of them block or strip custom schemes for security.
Routing logic inside the app maps every link pattern to its actual screen. We build this alongside the app’s real navigation, not as a bolted-on side system. That way, a new screen added later gets its route defined as part of building the screen. For users without the app yet, the link falls back gracefully to a web page with the same content, or to the right app store listing. With deferred deep linking, we remember the destination through the install so the app opens straight to it the first time it launches.
Where it’s relevant, we also set up app indexing. That lets Google surface specific app screens in search results for people who already have the app installed, reusing most of the same link-to-screen map. Attribution tracking sits on top of all of this, so you can see which campaign, share, or notification actually drove a given open, not just that opens happened.
What can quietly break
The domain association file that proves ownership for Universal Links and App Links has to stay correctly configured and reachable. A broken or missing file silently falls back to the unreliable custom-scheme behavior, with no obvious error anywhere. We check it as part of every deploy that touches domain configuration.
Deferred deep linking through an app store install usually adds a third-party attribution service to your stack. That’s one more dependency, and sometimes a privacy question worth thinking through, so we only add it where the deferred case genuinely matters to the product. Link routing also needs upkeep as your screens change. A route pointing at a screen that got renamed or removed needs a deliberate redirect. We’d rather fix that than have a confused user find a broken link first.
What it costs and how long it takes
| 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.
What this pairs with
This pairs with push notifications infrastructure, so a notification opens the exact screen it refers to. It also pairs with in-app subscriptions (App Store, Google Play), for linking straight to an upgrade screen from a campaign. See the development service page for our full build process. For real examples, look at 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’ll 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, routed to your core screens, in 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 scheme like myapp:// only works if the app is already installed and the context around it recognizes that scheme. Otherwise it fails silently. Universal Links on iOS and App Links on Android use real https:// addresses instead. Those work whether the app is installed or not, and from almost any context, including messages and social apps that block custom schemes for safety.
What happens if the app is not installed yet?
The link falls back to a normal web page, or to the right app store listing. With deferred deep linking, it also remembers where the user was headed. The app opens straight to that screen the first time it launches, instead of dropping them at the home screen with no context.
Does this help with app store discovery too?
App indexing lets Google surface specific screens inside your app when someone searches for something your app covers. It's a separate mechanism from a shared link opening the app, but a related one. We set up both together, since they reuse most of the same routing logic.
Who owns this setup?
You do. The domain association files, the app's routing logic and the attribution configuration all live in your own infrastructure and repository.