Nimriz
Mobile growth teams

Mobile deep links and app routing

A branded short link that opens your iOS or Android app when the platform routes it there, falls back to the App Store or Play Store when configured, and lands on a web destination as the final safety net. One link to share across ads, email, push, print, and partner placements.

  • iOS Universal Links and Android App Links on eligible verified branded domains
  • Deterministic three-tier fallback: app target, store fallback, web fallback
  • Routing preview, time-window control, and the same analytics as the rest of your links
Start for freeAll use cases
Deterministic three-tier fallback

One branded short link routes through app target, store fallback, or web fallback based on what is configured and eligible.

Configured branded domains only
1
App target
Nimriz chooses an app-eligible destination for the platform. The platform then decides whether to open the app.
2
Store fallback
When no app target is used, the link forwards to the App Store (iOS) or Google Play (Android) if configured.
3
Web fallback
When neither an app target nor a store destination applies, the visitor reaches the configured web destination.

A standard short link has one destination. Every visitor, on every device, gets the same URL. That is a problem for mobile apps: a user who already has your app installed lands on the mobile web instead of inside the app, breaking the experience and wasting the intent behind the click.

Mobile app deep linking solves this by configuring a branded short link with a mobile app destination. Nimriz generates and serves the platform association files (an apple-app-site-association file for iOS Universal Links and an assetlinks.json file for Android App Links) from your branded domain. These files tell iOS and Android to treat matching links as app-eligible, so the platform can open your app directly when it is available.

The routing decision itself is deterministic. Nimriz chooses an outcome in a fixed order: (1) the app target when configured and eligible for the requesting platform, (2) the store fallback when configured, (3) the web destination otherwise. The edge cannot know whether the app is installed on a specific device - that determination belongs to the platform. What Nimriz controls is which destination it offers and in what order.

The result is a single branded link that works sensibly across every visitor state: app users get the in-app experience, users without the app reach the correct store listing, and everyone else lands on the web. The same link can be placed in an email campaign, a QR code, a paid ad, or a push notification without any per-channel logic on your end. Where enabled for your workspace, on a configured branded domain, deep links are a destination option on any routing rule or experiment variant.

Who it is for

Mobile app growth and marketing

Send campaign links directly into the app for users who have it, drive installs for those who don't, and never strand a visitor on a broken web page.

Lifecycle and CRM teams

Send email and push links that open the right in-app screen rather than the mobile web, keeping re-engagement flows in the native experience.

Mobile engineers and platform teams

Configure domain association files once in domain settings, then let marketing teams manage individual link destinations without engineering involvement per campaign.

What you get

Universal Links and App Links

Nimriz generates and serves Apple Universal Link association files and Android App Link asset files from your branded domain. This is what allows the iOS and Android platforms to treat your short links as app-eligible HTTPS links rather than ordinary web URLs. Configuration is through your domain settings, not manual file uploads.

Deterministic app, store, web fallback

The fallback order is fixed: app target first when configured and eligible for the platform, store fallback next when configured, and the web destination as the final catch-all. Every visitor state has a clear answer, so no one reaches a dead screen. The sequence is the same for iOS and Android, and it applies regardless of which routing rule or experiment variant triggered the mobile app destination.

Verified branded domain required

Mobile app deep links work only on an account-exclusive, verified branded domain that is ready for traffic and fully configured for app association. Shared domains and Nimriz built-in domains are excluded because association files are host-wide and cannot safely represent multiple customers’ apps on the same hostname. Nimriz shows the deep-link readiness state of your domain in settings so you can confirm eligibility before publishing links.

Routing preview before launch

The routing simulator evaluates your current draft rules exactly as they would run in production and shows which destination Nimriz would choose for a given country, device OS, device type, and UTC time. For deep links, the preview shows which tier (app target, store fallback, or web fallback) would be selected. It cannot simulate whether the visitor's device has the app installed, because that decision belongs to the platform at click time.

How it works

One branded link for every visitor state

Configure app deep linking on a branded domain that is verified, traffic-ready, and fully set up for app association. Nimriz manages the association files and applies the deterministic fallback order at redirect time.

1
Plan

Verify a branded domain and configure it for deep linking by adding iOS app identifiers (Bundle ID and Team ID) and Android identifiers (package name and SHA-256 signing fingerprint) in domain settings. Wait for the readiness indicator to show Ready.

2
Publish

On a link's Routing tab, add a route or experiment variant with a mobile app destination, then set the store fallback URL (App Store or Play Store) and the web fallback URL so every state has a clear answer.

3
Measure

Use the routing preview to confirm which tier (app target, store fallback, or web fallback) Nimriz would choose for a given device OS and country before you publish the link.

  • Combine deep linking with country, device OS, and time-window routing rules when you need different app destinations by region or platform, or when a single fallback chain is not enough for a campaign.
  • Track clicks on the same short-link record as the rest of your links. Analytics records the outcome (app target, store fallback, or web fallback) so you can see how the three tiers performed.
Deep links and routingTrust and privacyFAQ
Example
Branded short link
go.brand.com/promo
iOS visitor - app target offered
Nimriz serves an app-eligible destination via Universal Link. The platform opens the app if it is installed.
Android visitor - store fallback
No app target is used for this visitor; Nimriz redirects to the Play Store listing.
Desktop visitor - web fallback
Neither app target nor store applies; visitor lands on brand.com/promo.

Setup

  1. 1
    Verify and configure a branded domain for app association
    Add a custom branded domain in Settings → Domains, complete DNS verification, and wait for the Ready status. Then open the domain's mobile app settings and enter your iOS app identifiers (App Bundle ID and Apple Team ID) and Android identifiers (package name and SHA-256 signing key fingerprint). Nimriz generates and serves the association files from the domain once configuration is complete and the readiness indicator shows Ready. Custom domain setup guide
  2. 2
    Confirm deep-link readiness and eligibility
    Deep links require plan access AND must be enabled for your workspace, AND the domain must be branded, verified, traffic-ready, and fully configured for app association. Check the deep-link readiness indicator in domain settings before creating links. A domain in an ineligible or unconfigured state will not serve association files or app-eligible destinations. Deep-link eligibility requirements
  3. 3
    Add a mobile app destination on a link
    Open a link's Routing tab, add a route (or experiment variant), and set the destination type to mobile app. Configure the app target URL (the deep link into your app), the store fallback URL for each platform (App Store for iOS, Google Play for Android), and the web fallback URL. The three-tier fallback order is fixed: app target, then store, then web.
  4. 4
    Preview, then publish
    Use the routing simulator to confirm the expected outcome for device OS combinations before the link goes live. The simulator shows which tier Nimriz would choose but cannot simulate whether the app is installed on a real device. Once preview looks correct, save the ruleset and publish the link. Test on a real iOS and Android device to verify the association files are being honoured by the platform.

What good looks like

Without mobile app deep linking

  • Every short link sends all visitors to one web URL.
  • App users land on the mobile web even when your app is installed, breaking the native experience.
  • No path to the App Store or Play Store for users who need to install first.
  • Teams create separate links per channel and maintain them manually.

With mobile app deep linking on a configured branded domain

  • App target: Nimriz offers an app-eligible destination and the platform opens the app when available.
  • Store fallback: users without the app reach your App Store or Play Store listing in one tap.
  • Web fallback: desktop visitors and edge cases still land on the correct web destination.
  • One branded link works across email, push, QR, ads, and partner placements without per-channel logic.

Where enabled for your workspace, on a configured branded domain: one link, three sensible outcomes, no dead screens.

Frequently asked questions

What happens if the user does not have the app installed?
When no app target is appropriate for the visitor, Nimriz moves to the store fallback tier. If you have configured an App Store URL (iOS) or Play Store URL (Android), the visitor is sent there. If no store URL is configured either, Nimriz falls back to the web destination. The three-tier order (app target, store fallback, web fallback) is deterministic and applies to every request.
Can Nimriz detect whether the app is installed on a device?
No. The edge cannot know whether the app is installed on a specific device. Nimriz chooses which destination to offer based on the configured fallback order and the requesting platform. The platform (iOS or Android) then decides, based on its own association file verification and app availability, whether to open the app or fall through to the next option. This is how Universal Links and App Links work by design.
How do iOS Universal Links and Android App Links differ?
Both mechanisms use platform association files served from your domain. For iOS, Nimriz serves an apple-app-site-association file at the root and under /.well-known/. You configure your iOS app's Bundle ID and Apple Team ID in domain settings. For Android, Nimriz serves an assetlinks.json file under /.well-known/. You configure your Android app's package name and SHA-256 signing key fingerprint. Both are required if you want deep linking to work on both platforms from the same branded domain.
Why do deep links require a branded verified domain? Can I use a Nimriz built-in domain?
Association files are host-wide. A single apple-app-site-association or assetlinks.json file on a domain can only represent one app identity. If Nimriz served association files from a shared or built-in domain, a single file would need to represent every customer's app at once, which is not supported by the platform specifications. Deep links therefore require a domain that is exclusive to one account, verified, ready for traffic, and fully configured for app association.
What are the setup requirements for deep links?
Four things must all be true before deep links will work: (1) your plan must include deep-link access, (2) deep links must be enabled for your workspace, (3) your domain must be a branded custom domain that is account-exclusive, verified, and ready for traffic, and (4) the domain must have valid app metadata configured (iOS and/or Android identifiers) so Nimriz can generate and serve the correct association files. Plan access alone is not enough - the domain configuration and workspace enablement gates must also pass.
Does deep linking work with routing rules and A/B experiments?
Yes. A mobile app destination is a destination type that can be assigned to any routing rule or experiment variant. For example, you can add an iOS rule (Device OS = ios) with a mobile app destination, a separate Android rule, and leave the default destination as a web URL for desktop visitors. You can also put a mobile app destination on an experiment variant to test app vs. web outcomes side by side. Learn about smart routing
Do deep links support deferred deep linking or post-install attribution?
No. Deferred deep linking (resuming a specific in-app destination after a first install), install-time attribution, and post-install resume behavior are outside the scope of what Nimriz provides. Nimriz handles the redirect decision and fallback chain at click time. For install attribution and deferred linking you would use a dedicated mobile measurement partner alongside Nimriz branded links.
The app is not opening even though it is installed. How do I troubleshoot?
Start with the domain readiness indicator in Settings → Domains - it must show Ready. Visit https://yourdomain.com/apple-app-site-association and https://yourdomain.com/.well-known/assetlinks.json and confirm they return valid JSON, not a 404. Check that your iOS app is configured to handle Universal Links for your domain, and that your Android app is configured for App Links with the correct package name and signing fingerprint. Apple and Android can cache association files longer than Nimriz's own headers suggest, so allow time for cache refresh after any configuration change. Test on a real device rather than an emulator.

Related use cases

Smart routing and experimentation
Pair geo, device OS, and A/B routing rules with deep links on the same link.
Campaign links
Run campaign link tracking across channels with deep links where applicable.
API and workflow automation
Create and manage deep-link enabled short links at scale via the API.

Deeper reading

Deep links and routing: feature overviewRouting rules and preview: setup guideCustom domain setup: verification and readinessGlossary: what is a deep link?Glossary: smart routing explainedBlog: mobile deep links from short links

Ready to get started?

Create your account and start with the Starter workflow. Compare plans when you need higher limits or supported-plan capabilities.

Start for freeView pricing