Mobile Destinations

When someone taps your link on a phone, one of two things happens, and only the second involves Tolinku at all.

If they have your app and the path is registered, the operating system opens the app directly. Nothing reaches our servers, so no Tolinku setting affects it. This is Universal Links on iOS and App Links on Android.

If they do not have your app, the tap opens a browser, which reaches us, and the settings below decide where they go next.

Tip

A useful consequence: if a visitor is seeing anything Tolinku serves, the app did not open. That is why there is no “open the app if installed” setting. There is nothing to configure, and if the app is not opening when it should, the cause is in Universal Links rather than in your route.

Choosing what they see

The landing page mode on the route decides this:

Mode	A visitor without your app gets
Generic	Your branded page, with buttons for the app store and your website
Custom	The landing page you designed
None	An immediate redirect, no page to tap through

Generic and Custom let the visitor choose. None decides for them, which is faster but gives up the chance to explain anything.

Where “None” sends them

By default, the app store. Turn on Prefer Fallback URL over the app store on the route and they go to your Fallback URL instead.

The setting belongs to this template. It is read only when the Landing Page Template is None, and the route form disables it otherwise, because Generic and Custom already put both choices in front of the visitor.

Which is better depends on what the link is for:

• The app store suits a link whose value is the app itself, an invite or a referral.
• Your website suits a link to something viewable on the web. Someone who tapped a product link wants the product, and an install page is a poor substitute.

If the setting is on but no Fallback URL is configured, the store is used anyway, so enabling it cannot leave a link with nowhere to go.

Overriding it for one link

The setting is the route’s default. A single link can override it in either direction:

https://links.yourapp.com/promo?prefer_fallback=web     # your Fallback URL
https://links.yourapp.com/promo?prefer_fallback=store   # the app store

This lets one route serve campaigns with different intents. An ad aimed at installs and an email aimed at browsing can share a route, rather than duplicating it to flip one checkbox.

A link without the parameter behaves exactly as the route setting says, so this changes nothing for links you already have. true and 1 also mean the Fallback URL, false and 0 the store, matching the checkbox it overrides. An unrecognised value is ignored and the route setting applies, so a typo in a campaign link degrades rather than breaks.

Like the setting, it is read only when the Landing Page Template is None.

The parameter chooses between the two destinations already configured on the route. It cannot name a new one, which is why it carries no restrictions of its own, unlike deep_link_value below.

When they come back from the store

A visitor who taps a link without your app installed goes to the app store through a hand-off page. When they come back to the browser afterwards, that page is still sitting there saying it is opening a store they have already seen.

Return to Fallback URL after the store sends them to your Fallback URL instead. It is on by default, and applies whether or not they went through with the install.

It runs when they return, so it covers both routes back:

• They tapped through to the store, then pressed back or switched apps to return.
• They already had the app, it opened, and they later came back to the browser.

Nothing happens while they are away, and nothing happens if they never come back.

The setting sits on the route, next to Prefer Fallback URL over the app store, and needs the same two things to do anything:

Requirement	Why
Landing Page Template is None	Other templates show a page with its own links, so there is no hand-off page to return to
A Fallback URL, on the route or the Appspace	There is nowhere to send them without one

The route form disables the toggle when either is missing, and says which.

Note

How a visitor gets back differs by platform, so the behaviour is not identical on both.

On Android the store opens through market://, which leaves the page in the browser untouched. Switching back to the browser is enough.

On iOS the tab navigates to apps.apple.com and the App Store opens over it, so the page is reached again by going back, which restores it from the browser’s cache. Simply switching back to Safari lands on the App Store page rather than on ours.

A visitor who closes the tab is not sent anywhere on either platform, which is the correct outcome: they have left.

To turn it off, open the route and switch Return to Fallback URL after the store off. The hand-off page then stays as it is when they return, which is the behaviour before this setting existed.

Passing a destination on the link

A link can carry its own destination in a deep_link_value parameter:

https://links.yourapp.com/promo?deep_link_value=https://yourapp.com/products/42

A visitor without your app goes to that URL instead of the fallback or the store. This lets one route serve many destinations, so you do not need a route per campaign or a redirect page of your own.

Like the setting above, the automatic redirect applies to routes whose Landing Page Template is None. On a Generic or Custom route the visitor sees the page, and the value becomes the destination its web button points at rather than an immediate redirect.

Caution

The destination has to be a host you control: one of your Appspace’s domains or subdomains, or the host of a Fallback URL you have configured, plus any subdomain of those. A www host and its apex count as the same site, so a fallback on www.example.com also permits example.com and shop.example.com. A value pointing anywhere else is ignored and the link behaves normally.

This is deliberate. A link that redirects anywhere its query string says would let anyone send people to a site of their choosing with your domain in front of it, which is a phishing tool built out of your own links. Constraining it to your hosts keeps the feature useful for you and useless to everyone else.

Visitors who do have your app are unaffected: the operating system opens the app with the full URL, parameter included, and your app decides what to do with it.

To pass parameters through to your Fallback URL rather than replacing it, use query parameter forwarding instead.