One Link for App Store and Google Play — How It Works

The two-link problem

Every app developer hits the same friction point. You're writing a tweet, recording a YouTube video, or adding a link to your bio — and you have two store URLs. One for the App Store, one for Google Play.

You either pick one and ignore half your audience, or you paste both and hope people tap the right one. Neither option is good. You lose installs either way.

This is a solved problem. A single link can detect the user's device and redirect them to the correct store automatically. No extra taps. No confusion. Every click tracked. It's one of the core building blocks covered in the broader guide on tracking app installs with links.

Here's exactly how it works.

How device detection works

When someone taps a link, their browser sends a request to the server. That request includes a User-Agent header — a string that identifies the device, operating system, and browser.

Here's what a typical User-Agent looks like on iOS:

Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1

And on Android:

Mozilla/5.0 (Linux; Android 15; Pixel 9) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Mobile Safari/537.36

The server parses this string. If it contains iPhone or iPad, redirect to the App Store. If it contains Android, redirect to Google Play. If it's a desktop browser, show a branded download page with both options.

This all happens in milliseconds. The user taps a link and lands in the right store. No JavaScript detection, no client-side redirect delays.

The redirect flow

Here's the full journey from tap to store:

Step	What happens	Time
1	User taps your link (e.g. instally.io/l/abc123)	0ms
2	Our redirect service receives the request and logs the click	~10ms
3	The service determines the user's platform	~1ms
4	The user is redirected to the correct store URL	~1ms
5	User's browser follows the redirect to App Store or Google Play	~200ms
6	Store page loads	Varies

Total added latency: roughly 50-100ms. Users don't notice it.

What happens on desktop?

Desktop visitors can't install a mobile app directly. Redirecting them to a store page is a dead end — the App Store link opens iTunes (if they even have it), and Google Play just shows a web listing.

The better solution: show a branded download page.

When a desktop user clicks your tracking link, they see a clean page at instally.io/yourapp with your app icon, a short description, and download buttons for both stores. They can scan a QR code to open the link on their phone, or click the store button directly.

Every visit to this page is tracked. You know exactly how many desktop visitors came from each link, even if they don't install immediately.

This page also works perfectly as a link-in-bio for your app. One URL that looks professional and tracks everything.

Server-side vs client-side detection

There are two ways to detect the user's device: server-side (parsing the User-Agent on the server before responding) and client-side (loading a page, running JavaScript to detect the device, then redirecting).

Approach	Speed	Reliability	Tracking
Server-side (User-Agent parsing)	Fast (~50ms total)	Very reliable	Click logged before redirect
Client-side (JavaScript detection)	Slow (500ms-2s)	Breaks with JS disabled	Click may not log if redirect is too fast

Server-side detection is the right choice. It's faster, more reliable, and guarantees the click is logged before the user leaves. Instally uses server-side detection for all tracking links.

Client-side detection has one additional problem: some in-app browsers (Instagram, TikTok, Twitter) restrict JavaScript execution or override navigator.userAgent. Server-side parsing avoids this entirely because the User-Agent header is sent with every HTTP request regardless of the browser's JavaScript capabilities.

Setting up a single tracking link

In Instally, you register your app once with both store URLs:

Field	Example
App name	Workout Timer Pro
App Store URL	https://apps.apple.com/app/id123456789
Google Play URL	https://play.google.com/store/apps/details?id=com.example.timer
Subdomain	instally.io/workout-timer

Then you create tracking links. Each link gets a unique identifier and a name:

Link name	URL	Use case
YouTube - April review	instally.io/l/yt-april	Video description
Twitter bio	instally.io/l/twitter	Profile link
Reddit r/fitness	instally.io/l/reddit-fitness	Post or comment
Creator - @fitjess	instally.io/l/fitjess	Creator's unique link

Every link works on iOS, Android, and desktop. Every click is tracked. You see which links drive installs and revenue in your dashboard.

Handling edge cases

In-app browsers

Social media apps (Instagram, TikTok, Twitter/X, Facebook) open links in their own in-app browser. These browsers sometimes modify the User-Agent string, but they still identify the underlying OS.

For example, the Instagram in-app browser on iOS still sends a User-Agent containing iPhone. Server-side detection handles this correctly.

iPadOS

iPadOS Safari can request desktop websites by default, which means the User-Agent sometimes reads as Macintosh rather than iPad. Instally handles this by also checking for iPad keywords and the Mobile suffix that iPadOS still includes in most contexts.

Rare or unknown devices

If the User-Agent can't be confidently parsed (Linux desktop with a mobile-like string, obscure devices), the fallback is to show the branded download page with both store buttons. Better to give users a choice than to guess wrong.

Why this matters for marketing

Having a single link simplifies everything downstream.

One link per campaign. You create one tracking link for your YouTube video, not two. Your call-to-action is "download the app" with one link, not "download on iOS here and Android here." Cleaner analytics. All clicks and installs from a single campaign funnel into one link. You don't need to manually combine iOS and Android data to understand total performance. Higher conversion. Every extra tap or decision point is a place where users drop off. Removing the "which store?" step increases the percentage of people who actually reach the store page. Works everywhere. Bio links, email signatures, QR codes, blog posts, social media posts, podcast show notes. One link handles all of them.

Code: reading the User-Agent yourself

If you're curious how this works under the hood, here's a simplified version of the detection logic.

Node.js example:

function detectPlatform(userAgent) {
  const ua = userAgent.toLowerCase();

  if (ua.includes('iphone') || ua.includes('ipad') || ua.includes('ipod')) {
    return 'ios';
  }

  if (ua.includes('android')) {
    return 'android';
  }

  return 'desktop';
}

This is a simplified version of the detection logic. A production implementation also needs to handle edge cases (iPadOS desktop mode, Kindle Fire, HarmonyOS) and log the click before redirecting.

Instally handles all of this for you. You create a link, share it, and the platform takes care of detection, redirect, click logging, and install matching.

How it connects to install tracking

Click tracking is the first half of the picture. The second half is install tracking — matching each install back to the link that drove it.

When someone taps your link and installs your app, the Instally SDK (added to your app with a few lines of code) reports the install back to Instally's servers, where it's matched to the original click. No IDFA required, no ATT prompt needed.

The result: you see exactly which link drove each install. Combined with revenue tracking (via RevenueCat, Stripe, Superwall, or Adapty), you can see the full picture — clicks, installs, and revenue, all per link.

FAQ

Does this work with App Clips or Instant Apps?

Not currently. Tracking links redirect to the full App Store or Google Play listing. App Clips and Instant Apps use different URL schemes and aren't supported yet.

What if someone shares my tracking link and it gets opened on a platform I didn't intend?

The link still works. It detects the device and redirects correctly regardless of where it's shared. The click is logged under the original tracking link, so you'll see the traffic in your dashboard. This is a feature, not a bug — it means your links are inherently shareable.

Can I use a custom domain instead of instally.io?

Custom domains are on the roadmap. For now, all tracking links use the instally.io domain.

How is this different from a URL shortener like Bitly?

URL shorteners redirect everyone to the same destination. A tracking link detects the platform and redirects to the correct store. Tracking links also log installs and revenue, not just clicks. Bitly tells you how many people clicked. Instally tells you how many people clicked, installed, and paid — per link.

Do tracking links work in QR codes?

Yes. QR codes are just URLs. Generate a QR code for your tracking link and it works exactly the same way: the device scans the code, opens the link, and gets redirected to the correct store. The click is tracked.

What happens if my app is only on one platform?

If you only have an iOS app, Android users who click your link will see the branded download page explaining that the app is available on iOS. The same applies in reverse. The click is still tracked either way.