How to Send iPhone and Android Users to Different Pages From One Link

A poster goes up with one QR code on it. Someone scans it on an iPhone. Someone else scans it on Android. They need to land in two different app stores.

A device targeting link reads the user-agent your browser sends, then picks a page from it. One short URL can send iPhone visitors one way, Android visitors another, and everyone else to your website.

Setting one up takes a few minutes. The part worth reading is where it breaks.

What does the server see when you tap a link?

Your browser sends a line of text with every request. It is called the user-agent. It names the browser and the platform it runs on.

A short link is a redirect. The server reads that line, picks a page, and sends you there. Nothing runs on your phone. There is no app and no script.

So the whole choice rests on one string of text. That is not much to go on. It is enough for a rough split, and no more than that.

Where should each device go?

App store links are the obvious case. They are also the least interesting one.

Here is where a split link earns its keep.

The shape is the same every time. One link goes out into the world. Three pages sit behind it.

That last point matters most for print. A QR code on a poster cannot be edited. The pages behind it can.

Two other channels are worth a note. Text messages charge you by length, so a short link in an SMS buys back room for words. WhatsApp reports no taps on a link you send. That is why tracking a WhatsApp link needs a redirect in the middle.

There is a quieter win here too. Each destination gets its own page, so you can see which platform your audience really uses. One number per device, from one link.

Where does a device targeting link go wrong?

This is the half most guides skip. Device detection is weaker than people assume. Three failures are worth knowing by name.

iPads look like Macs

Apple changed this in 2019. In its post on new WebKit features in Safari 13, Apple's WebKit team wrote this:

"With the exception of iPad mini, Safari on iPad will now send a user-agent string that is identical to Safari on macOS."

Read that twice. An iPad looks like a desktop to your link. Apple's advice in the same post is to build one responsive site instead of splitting by user-agent.

So treat "desktop" as "desktop plus most iPads" and the surprise goes away. Send desktop traffic to a page that works with a finger, not only a mouse.

You can see Android, not which Android

Chrome froze the Android part of the user-agent. Chromium's own page on user-agent reduction dates the change to Chrome 110, on 7 February 2023.

Since then every Android device reports the same thing: Android 10; K. Not the real version. Not the phone model.

You can still tell Android from iOS. You cannot tell a five-year-old budget phone from this year's flagship. Any guide that routes by Android version is out of date.

Client hints do not work on iPhones

A common piece of advice is to stop reading the user-agent and read Sec-CH-UA-Platform instead. That header belongs to a newer feature called User-Agent Client Hints.

It is missing on the platform you most want to spot. Checked on caniuse on 19 September 2026, Safari does not support it in any version. Firefox does not either. Support is limited to Chromium browsers such as Chrome and Edge.

An iPhone on Safari sends no client hints at all. So the modern replacement cannot see iOS, and the old user-agent string is still what does the work.

What happened to Firebase Dynamic Links?

Search this topic and you will still find advice pointing at Firebase Dynamic Links. It was Google's own product for one link that routed by device. It is gone.

Firebase Dynamic Links shut down on 25 August 2025. Google's Firebase Dynamic Links FAQ warned that every clicked link would return a 404, and that link data would be deleted.

Live checks on 19 September 2026 match that. Addresses on firebase.page.link and app.goo.gl return 404.

One trap for readers. That FAQ page still says the product "will shut down", in the future tense. The date passed over a year ago. The wording simply was not updated.

Google shipped no replacement. It points to Universal Links and App Links for plain deep linking. For anything more, it names outside vendors: Adjust, Airbridge, AppsFlyer, Bitly, Branch, Kochava and Singular.

That split is the useful bit. Opening your app from your own web address is now an operating-system job, not a Google product. Choosing which page a visitor sees is a link job. They are two separate problems, and one tool rarely does both well.

Deep link, Universal Link, App Link: what is the difference?

People use these three as synonyms. They are not the same thing.

• Deep link is the umbrella term. Any link that opens a set place inside an app.
• Universal Link is Apple's name for a normal https:// link that iOS has verified as yours. Tapping it opens your app.
• App Link is Google's name for the same idea on Android. It has been there since Android 6.0.
• A custom URL scheme like example://products/123 is the older style. It is not a web address at all.

The question people ask is what happens when the app is missing. Each platform words the answer differently, so here is each one as written.

Apple, in its guide to linking to your content:

"If the person hasn't installed your app, the system opens the URL in their default web browser, allowing your website to handle it."

Google frames it around domain approval rather than install state, in its Android deep linking guide:

"If your app isn't approved for the domain, the web intent resolves to the user's default browser app instead."

Either way the visitor lands on a web page, not an error. That is the whole reason these are ordinary https:// links. A custom scheme has no website behind it, so it has nothing to fall back to.

How do you set one up?

The steps are much the same in any tool that supports this.

1. Pick the default page. Desktop visitors and anything unknown will land here.
2. Add the iOS page. For an app, use your App Store listing address.
3. Add the Android page. For an app, use your Google Play listing.
4. Test on a real iPhone and a real Android phone. A browser's device emulator is not proof.
5. Open the default page on an iPad, because iPads will get it.

No app? The same idea still pays. Point iPhone and Android at a page sized for a thumb, and desktop at the full version. A help article is the classic case, because the steps differ by platform anyway.

clik.so does this as a rule on the link itself. You get iOS, Android and desktop as the three choices, and there is no SDK to install.

One honest limit, worth saying out loud. Routing like this works at the operating-system level and no deeper. It cannot read an Android version, and it counts iPads as desktop.

Common questions

Want to try this yourself?

clik.so's free plan includes one custom domain and tracks 2,000 clicks a month, with no card needed. Device targeting sits on the Pro plan, next to country-level geo-targeting and A/B testing. The device targeting page shows the setup screen and what each rule does.