Device-Based Redirects for App Install Campaigns
An honest look at SMLLR's device-based redirects for app-install campaigns — sending iOS and Android users to the right store from one QR code or link — versus true native deep linking, which SMLLR doesn't provide.
Set Expectations First: This Is Device Detection, Not Native Deep Linking
If you're looking for iOS Universal Links / Android App Links infrastructure — hosting an apple-app-site-association file, verifying Digital Asset Links, or deferred deep linking that hands intent data to your app on first open — SMLLR doesn't provide any of that. There's no SDK, no AASA or assetlinks.json hosting, and no API for passing click intent into your app after install. What SMLLR does provide is simpler and solves a different, common problem: one QR code or link that detects whether the scanner is on iOS or Android and redirects each to the correct destination automatically.
What Device-Based Redirects Actually Do
A single dynamic QR code or smart link (Basic plan and above) can carry a device-based routing rule: iOS users get redirected to your App Store listing, Android users to your Google Play listing, and everyone else to a fallback page of your choice. This solves the classic problem of a single printed QR code needing to work for both platforms without a 'choose your device' interstitial page slowing the user down.
- One QR code or link works for both iOS and Android audiences
- Detection happens at the redirect layer based on the scanning device's user agent
- A configurable fallback destination covers desktop or unrecognized devices
- No app-side code, SDK, or entitlement configuration required
What This Doesn't Cover
To be direct: this is destination routing before the app is opened, not deep linking within an already-installed app. If your team needs a scanned link to open directly to a specific in-app screen for a user who already has the app installed, or needs deferred deep linking (passing along what a user clicked before they installed, so the app can show a tailored first-run experience), that's native mobile infrastructure your own team builds — SMLLR's redirect layer isn't a substitute for it.
A Realistic App-Install Campaign
A D2C brand running a national print or outdoor campaign wants a single QR code on every poster and package that gets each viewer to the right app store, regardless of the device they're holding. Device-based redirects (Basic plan and above) cover exactly this, and because the underlying QR code is dynamic, the App Store and Google Play destination URLs can be updated anytime — for a new app version's listing, an A/B test between two store listing pages, or a temporary redirect to a waitlist page before the app has actually launched.
Related Reading
Frequently Asked Questions
Does SMLLR support iOS Universal Links or Android App Links?
No. SMLLR doesn't host an apple-app-site-association file, doesn't verify Digital Asset Links, and has no SDK for native deep linking. What it offers is device-based redirects — routing iOS and Android scanners to different URLs, typically App Store and Google Play listings.
Can one QR code send iOS and Android users to different app stores?
Yes. That's exactly what Device-Based Redirects (Basic plan and above) do — detect the scanning device and route iOS to the App Store, Android to Google Play, and everything else to a fallback URL.
Does SMLLR provide deferred deep linking, so a new install opens to a specific screen?
No. There's no API or SDK for passing click intent into your app after install. This has to be built with your own mobile deep-linking infrastructure if it's a requirement.
Do I need any code in my app for device-based redirects to work?
No. Detection and routing happen entirely at the QR code or link's redirect layer — nothing needs to be added to your iOS or Android app itself.
Can I change the App Store or Google Play destination later?
Yes. Since the QR code is dynamic, update either destination anytime from your dashboard without reprinting the code.
What happens if someone scans the code on a desktop computer?
They land on a configurable fallback destination — typically your website or a QR-code landing page — rather than an app store link that wouldn't make sense on desktop.