Test your app links with and without the app installed

By Noe Guerrero III

A link to a workshop should take someone to the workshop details. Before you share it, decide what a customer should see in the app and on the web. Then tap the link from the message, email or page where they’ll actually find it.

Start with one HTTPS address for the item you’re sharing. Write down the exact screen you want an eligible app tap to open and the page people should get in a browser. A link that opens the app home screen can still send a customer looking for the item all over again.

Give the web page a job

Imagine a McAllen ceramics studio with a website and an app for classes. It emails customers a link to a Saturday beginner workshop. In this fictional example, the browser page shows the workshop name, date, location and a way to check availability. The app opens the same workshop in its class list.

The browser page has to work on its own. Someone who just wants to check the date shouldn’t have to install the app to find it. If the workshop is full, both versions can show the same next step, such as joining a waitlist. Agree on that behavior before handing the link to the marketing team.

Private pages need a different decision. Suppose the studio sends a customer a link to manage an existing reservation. If they’re signed out, ask them to sign in and take them back to the reservation when their account has access. Plan a clear recovery path for an expired link or an account without access. The URL identifies the destination, and the app or website still checks who can see it. Include those rules in the project’s permission plan. Business app permission matrix

Give your developer the exact link

Apple Universal Links can open an eligible link in an installed app through an association between the website and app. Without the app, the link opens in a browser. Apple documents context that matters during testing, including Safari navigation within the same domain and the user’s choice of how links open. Pasting a URL into Safari’s address bar tests browser navigation. Apple’s Universal Links troubleshooting guide

Android App Links also use a verified association with a website. Ask your developer to confirm verification for the hostname you plan to share and check the device’s link handling settings. Android exposes verification and user selection separately, which helps explain why a link can behave differently on two phones. Android App Links overview and verification guide

Share the literal address used in the campaign. If the email tool wraps it for tracking, test that wrapped link too. A test of the direct address won’t tell you what happens when someone taps the button in the delivered email. Include the actual entry points in the scope you give your app developer. App development project brief

Tap it in the states your customers use

Use test accounts and sample reservations for the private cases. Write the expected result before each tap, then record where the link landed and whether you could finish the next step. Cover both supported platforms and the apps or browsers your customers will use to open it.

• App installed and signed in. Tap the workshop link from the planned email or message. Confirm the app shows the correct workshop and the agreed next action when the platform hands the link to the app.

• App absent. Tap the same link on a phone without the app. The browser page should show the workshop and a way to check availability.

• App installed with links opening on the web. Check that the browser page still serves the customer when their settings or the source app keep them there.

• Signed out on a private link. Sign in with an authorized test account. Confirm that the intended reservation loads and can be managed. Repeat with an account that lacks access and check the recovery message.

• Item unavailable. Try a test link for a retired workshop. Confirm that both reachable versions explain what happened and offer a relevant next step.

Run the checks against the build and website you plan to release. In the handover, keep the address, source of the tap, device and system version, app build, account state, expected destination and observed destination. A screen recording can help when the failure depends on a particular email app or browser.

When something misses the mark, give the developer a description they can reproduce. For the fictional workshop, a report could say the email button opened the class list on the release build, while the direct address from a test message opened the correct workshop. Record both entry points and retest the failing one after the fix. Keep the same link on your release checklist when the website host, app build or campaign link changes.