> ## Documentation Index
> Fetch the complete documentation index at: https://help.qrtub.com/llms.txt
> Use this file to discover all available pages before exploring further.

# App Links & Fallback URLs

> Use deep links to open mobile apps directly, with automatic fallback when the app isn't installed

QRtub Destinations support app deep links — special URLs that open a mobile app directly to a specific screen. When someone scans and the app isn't installed, QRtub automatically falls back to a URL you specify, keeping the experience useful rather than dead.

## What Are App Links?

App links are URLs that use a custom scheme instead of `https://`. When a device recognizes the scheme, it opens the corresponding app.

**Examples:**

* `iauditor://template/new_audit/<template_id>` — opens Mitti (formerly SafetyCulture) to a specific template
* `myapp://asset/EXC-203` — opens a custom app to an asset record
* `spotify://track/3n3Ppam7vgaVa1iaRUIOKE` — opens Spotify to a track

These work great when the app is installed. The problem is when it isn't.

## The Problem: App Not Installed

When someone scans a QR code and taps a Destination with an app link:

* **App installed** — the device opens the app directly
* **App not installed** — nothing happens, or the user sees an error

Without a fallback, a scan that ends in a blank screen is a failed interaction. This is especially common during rollouts, when not everyone has the app yet, or when contractors scan equipment they don't normally manage.

## How QRtub Handles App Links

QRtub detects when a Destination URL is an app link (any non-`https://` scheme). At scan time:

1. QRtub attempts to open the app link
2. A 2.5-second timer starts
3. **If the app opens** — the timer is canceled, the user is in their app
4. **If the page is still visible after 2.5 seconds** — the app wasn't installed, QRtub navigates to your Fallback URL

If no Fallback URL is set, QRtub shows a message instead — either your custom Fallback Message, or a default "App not available" notice.

## Setting a Fallback URL

When you add or edit a Destination with an app link URL, QRtub automatically shows a fallback configuration panel.

**In the Destination editor:**

1. Enter your app link URL (e.g. `iauditor://template/new_audit/template_abc123`)
2. An amber notice appears: "This is an app link — set a fallback for users without the app installed"
3. Enter a **Fallback URL** — the web page to open if the app isn't available

**Example (Mitti):**

* App link: `iauditor://template/new_audit/template_fcbc86fd41a74180921347e4be53bdf2`
* Fallback URL: `https://app.mitti.com/inspection/new?templateId=template_fcbc86fd41a74180921347e4be53bdf2`

Users with Mitti installed go straight to the app. Users without it land on the web version — same form, different delivery.

## Setting a Custom Fallback Message

If there's no web equivalent to fall back to, set a **Fallback Message** instead of a URL.

**Example:**

* App link: `myapp://asset/{{item.assetID}}`
* Fallback Message: `"Please install the Asset Manager app from the App Store to access this equipment record."`

When someone without the app scans, they see your message rather than a confusing blank screen.

If neither Fallback URL nor Fallback Message is set, QRtub shows a default "App not available" notice.

## Using Bindings in Fallback URLs

Fallback URLs support `{{item.field}}` bindings — the same way Destination URLs can include Item data automatically.

**Example:**

App link:

```
iauditor://template/new_audit/template_abc123?8f2f287e={{item.assetID}}
```

Fallback URL:

```
https://app.mitti.com/inspection/new?templateId=template_abc123&asset={{item.assetID}}
```

Configure both once. Deploy to 500 items. Each scan routes to the right app screen (or web equivalent) for that specific item — no per-item configuration.

## Where Fallback Settings Live

Fallback URL and Fallback Message can be set at three levels:

| Level           | Where to set it                     | When it applies                          |
| --------------- | ----------------------------------- | ---------------------------------------- |
| **Destination** | In the Destination editor, per-rule | Most specific — overrides everything     |
| **Link**        | In the Link settings                | Applies to all Destinations on this Link |
| **Item**        | In the Item editor                  | Applies across all Links for this Item   |

The most specific setting wins. Destination-level fallback takes priority over Link-level, which takes priority over Item-level.

## Common Examples

### Mitti (iAuditor)

**App link:** `iauditor://template/new_audit/{{item.templateID}}`
**Fallback URL:** `https://app.mitti.com/inspection/new?templateId={{item.templateID}}`

See the [Mitti Integration guide](/integrations/safetyculture) for full setup instructions.

### Generic Enterprise App

**App link:** `mycompanyapp://workorder/create?asset={{item.assetID}}`
**Fallback URL:** `https://app.mycompany.com/workorders/new?asset={{item.assetID}}`
**Fallback Message:** `"Open the MyCompany app to create a work order."`

Set both Fallback URL and Fallback Message — QRtub uses the URL if set, otherwise shows the message.

### App Download Link (No Web Version)

**App link:** `myapp://asset/{{item.assetID}}`
**Fallback URL:** `https://apps.apple.com/app/myapp` *(or Google Play)*
**Fallback Message:** `"This feature requires the MyApp mobile app."`

Alternatively, combine with [Device Detection](/destinations/device-detection) to route iOS users to the App Store and Android users to Google Play.

## App Links vs Device Detection

These two features are complementary, not alternatives:

| Problem                                       | Solution                                                   |
| --------------------------------------------- | ---------------------------------------------------------- |
| App not installed                             | Fallback URL (this page)                                   |
| Wrong browser on iOS (app links blocked)      | [Device Detection routing](/destinations/device-detection) |
| Different platforms need different app stores | [Device Detection routing](/destinations/device-detection) |

For Mitti specifically: iOS Safari works with `iauditor://` deep links, but Chrome on iOS blocks them. If your team uses mixed browsers, consider combining both approaches — device routing to serve the web link on iOS Chrome, and fallback URL to catch anyone without the app installed on other devices.

## Related

* [Mitti Integration](/integrations/safetyculture) — full deep link and fallback setup for iAuditor
* [Device Detection](/destinations/device-detection) — route users based on device, OS, and browser
* [Conditional Visibility](/destinations/conditional-visibility) — show Destinations to specific audiences
* [Pages Overview](/pages/pages-overview) — setting up multi-Destination Pages