If you want one link that sends iPhone users to the App Store and Android users to Google Play, what you need is a store-routing link, and it is the simplest of the three things people call a “universal link”. It reads the device that tapped it, picks the matching store, and sends a desktop visitor somewhere useful instead. It does not open your app on a specific screen, and it does not tell you which campaign produced an install. Those are separate jobs, built differently and sold separately.
Knowing which of the three you need is most of the decision. Buy the wrong one and you either pay for machinery you never use or discover, after the posters are printed, that the link cannot do what you assumed.
Three things that get called a universal link
Store routing. A short link checks the device that opened it and redirects to the right store listing: the App Store on an iPhone, Google Play on an Android phone, a web page on a laptop. It works the day you create it, with no change to the app itself, because it does its job before the app is involved at all.
Apple Universal Links and Android App Links. These are operating-system features, not products. When someone already has your app installed, an ordinary web address on your own domain opens the app instead of the browser, on the matching screen. To make that work, your developer builds support into the app, and your website hosts a small verification file that proves the app and the domain belong together: apple-app-site-association for Apple and assetlinks.json for Android, both under the /.well-known/ folder. When the app is not installed, the link simply opens the web page. These links decide whether an installed app opens. They do not decide where someone without the app ends up.
Deferred deep linking and attribution. This is the heavy end. A deferred deep link remembers what a visitor tapped before they installed, carries it through the store, and opens that exact content the first time the app launches. Attribution credits each install to the campaign, ad or partner that produced it. Both need a software development kit (SDK) inside your app, and they are the core business of mobile measurement platforms such as Branch, AppsFlyer and Adjust.
Which one you actually need
Start from what you are trying to do, not from the feature list.
If you are trying to get downloads from posters, packaging, trade show signage, social media bios, email signatures or a website button, you need store routing. Your audience does not have the app yet, and your job is to get each person to the right store with as little friction as possible.
If most of your audience already has the app and you want links in emails, texts or your website to open the right screen inside it, you need Universal Links and App Links. That is development work on your app and your domain, and once it is done it costs nothing to run.
If you buy installs through paid media and need a cost per install for each campaign, or your onboarding depends on content the visitor chose before installing — a referral code, a product they were looking at, an invitation — you need a mobile measurement platform.
Many businesses need the first and assume they need the third. The difference matters. The third involves an SDK, a privacy review of what it collects, and usually a sales conversation. The first is a link.
What a good store-routing link should do
Not all store-routing links are equal, and the differences show up after you have published them, which is the expensive time to find out.
Cover every store you publish on. Most tools route iOS and Android and send everything else to a web page. If your app or game is also on the Mac App Store, the Microsoft Store or the Amazon Appstore, check that each one is a real destination rather than a fallback.
Send desktop visitors somewhere useful. A laptop cannot install a phone app. The best destination is a page that shows both store badges, or the desktop version of your app if you have one, not a store page the visitor cannot use.
Come with a dynamic QR code. Print is permanent. A QR code on packaging should point to your link, not straight to a store address, so the destination can change without a reprint. That also matters for safety: a code you can repoint and monitor is one you can fix if something goes wrong.
Let you change the destination after publishing. Store addresses change when an app is relisted, split by region or replaced by a new version. Check whether your plan limits how often you can edit a link. Bitly’s published plans, for example, cap how many links can be redirected to a new destination each month.
Report by platform. You should be able to see how many taps came from iPhone, Android and desktop, and from which link, without exporting anything. That is how you learn which placement works.
Need nothing installed in your app. Store routing happens before the app opens, so it does not need an SDK. If a vendor requires one for routing alone, ask what else it collects.
Ask what happens if the vendor goes away
Firebase Dynamic Links was a widely used tool for this job, and Google shut it down on 25 August 2025. Links that had been printed on packaging, posted in bios and embedded in emails for years stopped working.
Every link you publish depends on the service behind it staying alive. Before you commit, ask three questions. Whose domain does the link live on? Can you export every link and its destinations if you leave? How long has the service been running, and who runs it? A link on a domain you control survives a change of vendor. A link on a vendor’s domain survives as long as the vendor does, so the vendor’s track record is part of the price.
They work best together
The three jobs are not rivals. A common, sensible setup uses two of them: Universal Links and App Links on your own domain, so existing users land inside the app, and a store-routing link with a QR code for every place where you cannot know whether someone has the app yet, which is most of print and most of social media.
Add a measurement platform only when you are spending enough on paid installs that per-campaign attribution changes what you spend.
Where TAPQUAD fits
TAPQUAD’s 1Link® does the first job. One short link and its QR code route each visitor to the correct store across iOS, Android, macOS, Windows and Amazon Fire, with scans and clicks reported in real time, and nothing to add to your app or your website. It does not do deferred deep linking or install attribution. If you need those, a mobile measurement platform is the right category, and our Firebase Dynamic Links alternative page explains how to tell which of those jobs you are replacing.
Sources: Apple Developer documentation on supporting universal links; Android Developers documentation on Android App Links; Firebase Dynamic Links deprecation notice; and Bitly’s published pricing page, checked on 12 October 2026.