What Should Happen When Someone Opens a Shared Link to Your Mobile App?

2026-10-24

When someone opens a shared link to your mobile app, the link should lead to the matching content if the app is installed, to a useful web page if it is not, and to the right destination after sign in. It should also show a clear message if the record no longer exists. Write these cases into your brief before development starts, and test them on real devices. This is planning guidance, not a promise that every phone, browser or messaging app behaves the same way.

The decision here is about link behavior: what happens at the moment of the tap. It is not about promoting the app in a store or about whether you should build a native app at all.

Why this needs a written brief

A shared link is often the first contact someone has with a record in your app, such as an invoice, a booking or a task. If the brief is silent, the result depends on defaults. One person lands on the home screen, another on a blank page, a third on a login form that forgets where they were going. Any of these can leave a person unsure whether the link worked.

Two platforms, two mechanisms

Treat iOS and Android separately in your scope. They use different systems, and the details differ.

Android

Android's documentation describes deep links as a way to bring users directly into your app content from links they have tapped. It describes two types of linking. Plain deep links go through the intents system, and the documentation says they are subject to the system disambiguation dialog. Android App Links are described as an enhanced capability that verifies deep links to your own website by establishing a trusted association between your app and your website. Once verified, links can open content in the app without the user selecting an app from a dialog. The same page states that App Links are supported on Android 6 and later on devices that have Google services, and that for deep links to your website, App Links are a recommended approach.

For your brief, this means two questions for the developer: which type are we using, and what happens on devices outside those conditions?

Apple

Apple's documentation on supporting associated domains says that associated domains provide the underpinning to universal links, a feature that allows an app to present content in place of all or part of its website, and that users who don’t download the app get the same information in a web browser. To associate a website with an app, the site needs the associated domain file and the app needs the appropriate entitlement. The file must be hosted over https with a valid certificate and with no redirects. Apple also says that since iOS 14 and macOS 11 apps request this file from an Apple managed content delivery network, which requests it within 24 hours, and that devices check for updates approximately once per week after installation. For your brief, this means a link change on the website side may not reach every device instantly, and the setup should be documented separately from Android. Apple's text does not promise that every tap in every app or browser opens your app, so keep the web fallback and test the channels your customers use.

The cases to specify

App installed

Recommendation: the link opens the screen for the specific record, not the start screen. Define what the back button does afterward, since people may have arrived with no earlier screens in the stack.

App not installed

Recommendation: the same link opens a web page that shows the record or a sensible summary, plus a clear way to get the app if you want to offer one. Decide in advance whether the web page shows the full record, a limited view or only a sign in prompt. The web fallback is a design decision, so describe it in the brief rather than leaving it to chance.

Link opened inside another app

Messaging, email and social apps sometimes open links in their own built in browser. Whether your app opens from there can vary. Specify what the minimum acceptable result is, for example that the web fallback always works, and test the channels your customers actually use.

Signed out or session expired

Recommendation: after sign in, return the person to the record they tapped, not to the home screen. Specify what happens if they sign in with an account that has no permission for that record: a clear message, not an empty screen.

Record unavailable

The record may be deleted, archived or never existed. Recommendation: show a plain message that the item is no longer available, say whether it was removed or the person lacks access when that is safe to reveal, and offer a next step such as going to the list. Do not show a generic error page.

Keep shared URLs safe

Shared links get forwarded, pasted into chats and kept in browser history. Recommendations:

Do not put personal data, such as names, email addresses or amounts, in the URL.
Do not treat knowing the link as proof of permission. Check access on the server each time.
If a link is meant to work without sign in, treat it as a deliberate access grant: use a separate share token, scope it to what it should show and decide whether it expires. An opaque record identifier is not authorization, and it is not the same thing as such a token.
Avoid carrying tokens in links that stay valid for long.

A hypothetical example

Imagine a small repair shop with an app for customers to follow their jobs. The shop emails a link to a job. If the customer has the app, it opens that job. If not, a web page shows the job status and an invitation to install the app. A customer who is signed out signs in and lands on the same job. When a job has been archived, the customer sees a message saying it is no longer available and a button to their job list. The URL contains only an opaque job identifier, and the server still checks who is asking. This is an invented illustration, not a report of a real project.

Testing matrix

Ask for a short table, filled in on real devices and not only simulators:

Rows are scenarios: app installed, app not installed, signed out, signed in without permission, record deleted, record archived.
Columns are device and OS version, entry channel (email, messaging app, mobile browser), expected result and actual result.
Run each scenario on the device and channel combinations your customers actually use, not every possible pairing.

Expect some differences between cells and decide in advance which are acceptable.

Acceptance checklist

Use this list when you write acceptance criteria for the project, and bring it to a project conversation.

A link to a record opens that record in the installed app.
Without the app, the link opens a defined web fallback.
iOS and Android setups are documented separately.
Sign in returns the person to the original destination.
No permission and unavailable record each show a distinct, clear message.
URLs contain no personal data and access is checked on the server.
The testing matrix is completed on real devices.
Accepted differences between channels are written down.

FAQs

Will the link behave the same in every browser and chat app?

Not necessarily. Specify the minimum acceptable result, such as a working web fallback, and test the channels that matter to your customers.

Do I need a web page behind every app link?

It is a strong recommendation, because it gives people without the app a useful result. The page can be simple.

Can a link be private just because nobody knows it?

No. Treat links as shareable. Check permission on the server, and keep personal data out of the URL.