Skip to main content
QRtub reads the device from the User-Agent on every scan, so a condition can show one Destination on a phone and a different one on a desktop.
These are conditions on the device, not on the person. Someone in the field on a laptop gets the desktop branch; someone at a desk on their phone gets the mobile one. If the distinction you need is about who is scanning, see Conditional Visibility for what a condition can actually read.

​
What you can read

When the device cannot be detected, QRtub assumes desktop, unknown, unknown. So a desktop-conditioned Destination is what an unrecognised device falls into — worth knowing when you choose which branch carries the fallback.

​
The two cases worth using it for

The right app store. One Destination at apps.apple.com/... with device.isIOS, another at play.google.com/... with device.isAndroid. iOS deep links outside Safari. An app scheme like iauditor:// only opens from Safari on iOS, so an iPhone user in Chrome needs the web URL instead:
This is narrower than it looks. If your worry is just “what if the app is not installed?”, that is already handled — see App Links & Fallback URLs, no device condition needed. Device routing is for the case where the app is installed but the browser blocks the scheme.

​
Combining with Item data

Device conditions and Item fields go in the same expression:

​
Where it is the wrong tool

  • Never for access control. User-Agent is self-reported, users can change it, and privacy browsers mask it. Use authentication.
  • Not to force a choice. If showing both options is simpler, show both.
  • Not as a stand-in for identity. See the note at the top.
Always leave one Destination with no device condition, so an unrecognised device still has somewhere to go.