Device-targeting redirects: one link for the App Store, Google Play and the web

A device targeting redirect is a short link that reads the User-Agent header on each click and answers with a 302 that sends iPhones to the App Store, Android phones to Google Play and desktops to a web page.

Set one destination per device class plus a default. The header separates phones from computers reliably.

It can't tell whether the app is installed, and it misreads spoofed strings and iPads, which have sent a Macintosh string by default since Safari 13 in 2019.

This guide shows 7 User-Agent strings with a rule for each, the 4 redirect status codes, the 2 association files that open an installed app and a test routine, citing MDN Web Docs, Apple, Google and MaxMind.

How do device targeting redirects work?

A device targeting redirect is a 3-step process. First, the browser's GET request carries a User-Agent header. Second, the server sorts the header into a device class.

Third, the server replies with a 302 and a Location header, so the visitor sees one hop. MDN Web Docs prefers feature detection and Client Hints such as Sec-CH-UA-Mobile, but a redirect has no page to run feature detection in.

The MDN Web Docs shortcut for phones is to look for Mobi anywhere in the string and treat the rest as desktop. The table lists 7 strings from the MDN reference (October 2025) with a rule for each.

For example, Microsoft Edge 141 on Android still carries the Mobile token, so Edge phones follow the same Google Play rule as Google Chrome 143.

How do Universal Links and App Links open an installed app?

Opening an installed app is the job of Universal Links on iOS and Android App Links on Android 6 (API level 23) and later, both straight from the tap.

Apple Developer Documentation says the system skips the browser and your website.

The Android App Links guide adds that verified links skip the disambiguation dialog, and Dynamic App Links on Android 15 (API level 35) change the rules without an app release.

An app opened from the tap sends your server 0 requests, so the log shows 0 clicks unless the app reports the open.

Both files in the table must sit on a domain you control, so a shared shortener cannot open your app and a custom tracking domain can.

A visitor who installs first gets help from Android's Play Install Referrer API, which gives the app referral data for 90 days, and the deep linking guide covers the rest.

Can one QR code send every phone to the right store?

A QR code that points at a device-targeting redirect is the simplest way to serve both stores, and the destinations can change after the print run, as dynamic versus static QR codes explains.

Generate the code from the short link, not the destination, so 1 code survives every rule change and never needs a reprint.

We built the free QR code generator, which recommends printing at least 2 cm (0.8 in) wide with a 4-module margin. For example, a conference poster with one code can serve iPhone, Android and laptop visitors.

In practice, scan the final artwork with the camera app before printing, since a scanner inside another app can open an in-app browser.

What changed in device detection after Safari 13 and Chrome 110?

Two vendor changes shaped current device rules. On September 19, 2019, Safari 13 with iOS 13 made Safari for iPad show desktop websites, which Apple's release notes describe as the same sites as Safari for macOS.

An iPad on default settings therefore takes the desktop rule, and a Mac string reporting more than 1 from navigator.maxTouchPoints is almost always an iPad. Google Chrome then reduced the User-Agent string in steps.

Chrome 101 zeroed the minor version, so Chrome/101.3.2.1 became Chrome/101.0.0.0. Chrome 107 fixed the desktop version and CPU, such as Windows NT 10.0; Win64; x64.

Chrome 110, in February 2023, fixed the Android version and model, so Android 13; Pixel 7 became Android 10; K, per the Privacy Sandbox blog.

After Google Chrome 110, model rules stop working, while the Android and Mobile tokens still match and desktops stay desktops.

How do in-app browsers and link previews behave?

In-app browsers are the web views inside 3 apps: Instagram, Facebook and LinkedIn. They send tokens such as Instagram, FBAN, FBAV, MetaIAB, LinkedIn or LinkedInApp, listed in the Matomo Device Detector.

The mobile rule still fires, but each app decides whether a Universal Link or App Link opens your app. Link previews come from bots.

The Slack fetcher sends Slackbot-LinkExpanding 1.0 and reads oEmbed, Twitter Card and Open Graph tags with HTTP Range headers.

The Meta crawler sends facebookexternalhit/1.1, reads Open Graph properties in the first 1 MB and needs an answer within a few seconds. Preview fetchers take the desktop or default branch, so put Open Graph tags on that page.

The post on bot traffic filtering explains why we built TrackRev to flag those clicks and still redirect them, and link tracking not working on mobile covers the rest.

Should a device rule use a 301 or a 302?

A device rule should use a 302 (Found), as defined in RFC 9110, or a 307 (Temporary Redirect), because both are temporary, while a 301 (Moved Permanently) and a 308 (Permanent Redirect) are meant to last forever.

The 307 also keeps the request method unchanged. A permanent redirect kept by a browser or CDN pins the first device's answer for everyone behind it, and MDN's redirection guide says crawlers replace the original URL after one.

Google Search Central names Vary: user-agent for URLs that differ by device, so key any CDN cache the same way or skip caching.

For example, an iPhone click cached behind a CDN with a 301 sends the next Android visitor to the App Store.

Can you route by country as well?

Country routing resolves the click's IP address to a country and picks the destination mapped to the ISO 3166 country code.

MaxMind's accuracy page estimates 99.8% for country, about 80% for a US state or region and 66% for a US city within 50 km, so route on country and nothing finer.

A country is safe for a storefront, currency or legal page, and a United States state works only as a soft preference.

A VPN user appears at the VPN's server, so write a default for every unmatched country, route price by country and language by the Accept-Language header, and keep legal restrictions in the destination.

For example, a SaaS with euro and dollar pricing can send visitors from Germany and France to the Euro Pricing page.

How do you set up device rules in TrackRev?

TrackRev is SaaS affiliate software with link tracking built in, and we built its link form to route by device only.

The Add device targeting option takes a mobile destination and a desktop destination, and a blank field falls back to the main URL.

Phones share the mobile field, tablets take the main URL and an iPad in default mode takes the desktop field.

The trade-off is one mobile field, which means one phone destination, so split iPhone from Android with a page on your own domain, as the route handler below does, or use one link per store.

Every click row keeps the device class, operating system, browser and country, so counts split by iPhone, Android and desktop on the free plan, which costs $0.

To open an installed app, enter the identifiers under domain settings and TrackRev serves both association files on your verified custom domain. TrackRev is not a mobile measurement partner, so in-app event attribution needs AppsFlyer or Adjust.

Indie is $29 a month and Growth is $299 a year (pricing, November 2026).

1import { NextRequest, NextResponse } from "next/server";2 3const IOS = "https://apps.apple.com/app/id0000000000"; // your App Store listing4const ANDROID = "https://play.google.com/store/apps/details?id=com.example.app";5const WEB = "https://example.com/signup";6 7export function GET(req: NextRequest) {8  const ua = req.headers.get("user-agent") ?? "";9  if (/iPhone|iPod/.test(ua)) return NextResponse.redirect(IOS, 302);10  if (/Android/.test(ua) && /Mobi/.test(ua)) return NextResponse.redirect(ANDROID, 302);11  return NextResponse.redirect(WEB, 302);12}

How do you test a device rule before you publish or print?

Testing a device rule means opening the link on real hardware, on at least 4 devices, before anyone else does.

Open the link on 4 devices, an iPhone, an Android phone, a laptop and an iPad, from Apple Safari, Google Chrome, Instagram and the Camera app. The table lists where each of the 5 test cases should land.

Running curl with the iPhone string from the User-Agent table prints the 302 status line and the Location header, so the rule can be confirmed before picking up a phone.

First, check the status and Location with the iPhone string from Safari 26. Second, repeat with the Google Chrome 143 Android string. Third, paste the link into Slack and confirm the card shows your Open Graph title and image.

Repeat each test from Instagram, LinkedIn and Apple Mail, where an in-app browser may land on the store, the app or a blank page.