Developers

How to automatically redirect users to the right app store by device

Detect iOS vs Android and send each visitor to the correct store — without writing or hosting detection code.

Sending users to the right store means reading the device from the request and redirecting accordingly. You can hand-roll this with User-Agent sniffing on your own server, but UA strings drift, in-app browsers behave oddly, and you now own a redirect endpoint forever. This guide explains how device-based store redirection works and how to get it without maintaining any of that code.

Create a free link in 5 seconds or sign in →

The problem

User-Agent strings are inconsistent and change over time, so DIY detection rots.
In-app browsers (TikTok, Instagram, Facebook) break naive store redirects.
Hosting your own redirect means an endpoint, TLS, and uptime you have to maintain.
Edge cases — desktop, tablets, unknown devices — each need their own fallback.

With onestore.link

onestore.link reads the device server-side and 302-redirects iOS to the App Store, Android to Google Play.
In-app browsers get a dedicated bridge page with a reliable "Open in Store" button instead of a failing redirect.
Desktop and unknown devices fall back to a both-buttons landing page.
It runs on Cloudflare's edge, so redirects are sub-millisecond and you maintain nothing.

How to do it

No SDK, no rebuild. Just a URL.

1
Create a link with both store URLs
Add your App Store and Google Play URLs to a onestore.link slug — these are the redirect targets.
2
Use the link as your destination
Point your button, ad, or QR code at the onestore.link URL instead of a hardcoded store link.
3
Let the edge handle detection
Each request is classified (iOS / Android / in-app / desktop) and routed to the right store or bridge page automatically.

Frequently asked questions

How does the device detection actually work?

onestore.link inspects the request's User-Agent server-side to classify the platform, then issues a 302 redirect to the matching store. In-app browsers and desktops get tailored fallbacks instead of a raw redirect.

Do query parameters and UTM tags survive the redirect?

Yes. UTM and arbitrary query parameters are preserved through the redirect, so your downstream analytics still attribute the click.

Can I do this without it being a third-party dependency on the hot path?

The redirect is served from Cloudflare's edge KV with sub-millisecond reads, so it adds negligible latency. If you'd rather self-host, see the comparison with Firebase Dynamic Links for the trade-offs.