Mobile app URLs explained: deep links that actually work

TL;DR: A mobile app URL is any address that sends someone to your app or its store page. Three formats: HTTPS verified links (Universal Links on iOS, App Links on Android), custom schemes like myapp://, and store listing URLs. Use HTTPS for anything public. It opens the app when installed and falls back to the browser when it is not.

A mobile app URL is any address that sends someone to your app, or to your app's store page. There are three kinds. Most teams pick the wrong one and lose the click.

Here's the short version. Use HTTPS links for anything public. Use `myapp://` only inside tools you control. Use store listing URLs in ads and emails.

The three formats:

HTTPS verified links are called Universal Links on iOS and App Links on Android. They win for two reasons. If the app is installed, the phone opens it. If it is not, the link opens in the browser like a normal web page. No dead end, no extra code.

Why custom schemes break in public

A custom scheme tells the phone to open a specific app. The problem is that any app can claim the same scheme.

On Android that means the user gets asked which app to open. Worse, another app can register your scheme first and take your traffic. And if your app is not installed, the link just fails. Silently.

That is a conversion you paid for and lost. Never put `myapp://` in a campaign.

Custom schemes still have a job. Sign-in redirects, partner-to-partner handoffs, internal tools on devices you control. Outside that, use HTTPS.

Finding your store URLs

Apple App Store. Open the app's page, tap share, copy the link. The shape is `https://apps.apple.com/au/app/app-name/id123456789`. You can also get it from App Store Connect under App Information.

The `/au/` bit is the country code. Use it for Australian campaigns. Or drop the country code entirely and Apple sends people to their own store.

Google Play. Open the listing at play.google.com. The address bar shows `https://play.google.com/store/apps/details?id=com.yourpackage.name`. The `id` is your package name, the same one in your Android manifest.

Play does not use country codes in the URL. It works out pricing and availability from the device. If your app is not released in Australia, that link shows an error, so check your distribution settings first.

Setting up iOS Universal Links

Three things have to line up.

• Add the Associated Domains entitlement in Xcode, written as `applinks:example.com`
• Host a file called `apple-app-site-association` at `https://example.com/.well-known/apple-app-site-association`
• Serve it as `application/json` over real HTTPS. Self-signed certificates break it

The file lists your app ID as `TEAMID.com.yourcompany.yourapp` and the URL paths it should catch, like `/product/*` and `/order/*`. Then handle the incoming activity in your app delegate.

Apple's associated domains documentation has the full file format.

Where this usually goes wrong:

• Wrong content type. An incorrect header breaks it with no error message at all.
• iOS caches hard. After a change, reinstall the app to see it.
• In-app browsers ignore it. Links tapped inside Instagram or Slack open in the browser, not your app. That is normal, not a bug.
• The user chose Safari once. iOS remembers. They fix it by long-pressing the link and choosing Open in App.
• Team ID mismatch. Your signing must match the file exactly.

Setting up Android App Links

Android checks a file called `assetlinks.json` at `https://example.com/.well-known/assetlinks.json`.

In your manifest, the intent filter needs `android:autoVerify="true"` on an HTTPS data tag with your host and path prefix. Without `autoVerify`, Android still shows the pick-an-app dialog and you have gained nothing.

The `assetlinks.json` file holds your package name and the SHA-256 fingerprint of your signing certificate. Get the fingerprint with `keytool -list -v -keystore your-keystore.jks`. Include both debug and release fingerprints if you test with debug builds.

Android re-fetches this file from time to time, so you can fix it without shipping an app update.

Android Studio has an App Links Assistant under Tools. It writes the intent filters, maps paths to activities, and fires test URLs at a connected device. Google's guide to creating deep links covers the rest.

To test from the command line, use `adb shell am start -W -a android.intent.action.VIEW -d "https://example.com/product/42" com.yourcompany.yourapp`. If it opens the browser instead of your app, verification has not completed or the file is unreachable.

How to test deep links properly

Emulators lie. In-app browsers lie. Test on a real device, through a real channel.

The flow that catches real problems:

1. Send the link to yourself by SMS or email.
2. Tap it from Messages or Mail, not from a browser.
3. Check the app opens on the right screen.
4. Uninstall the app. Tap the link again. Check the browser fallback loads something useful.
5. Reinstall and check the link still lands correctly.

Useful tools along the way: `adb shell am start` for firing intents, Console.app filtered by your bundle ID for watching iOS resolve links, Deep Link Tester for walking through scheme and Universal Link cases, and your phone's own camera app for QR codes.

One more time, because it is the failure that reaches production: run the final test by SMS to a real device on a real carrier. Webview tests will not catch it.

Fallbacks and the checklist

Every deep link needs somewhere to land when the app is missing.

• Server redirect. Your fallback URL works out the platform and sends people to the right store page or web page.
• Smart banner. Apple's `apple-itunes-app` meta tag shows a native prompt in Safari.
• Deferred deep linking. Store where the person was headed, then take them there after they install. This is the one most teams skip and most miss.

Tag every deep link with UTM or your own attribution parameter, or your analytics cannot tell you which campaign drove the install. Digiocial has a good piece on marketing attribution if that side is murky for you.

Before you launch, check:

• Both `.well-known` files load over HTTPS with no redirect. A 301 on that path breaks Android verification
• Content type is `application/json` on both
• The fingerprint in `assetlinks.json` matches the certificate that signed the installed build
• `android:autoVerify="true"` is there
• The paths in the file match the paths you are actually testing
• The app was installed after the file went live. Android verifies at install time
• Your test links were opened from SMS or email

You can check the files yourself with `curl -I https://example.com/.well-known/assetlinks.json`. You want a 200 and a JSON content type.

Routing is a product decision, not a dev task

Most teams treat deep linking as a job for the week before launch. Tick the box, ship it.

That is exactly why so many apps drop people on the home screen instead of the product they tapped. Web routing and app routing get designed separately, then someone tries to reconcile them at the end. Paths do not match. The association file gets updated when somebody remembers. The fingerprint is stale because the signing certificate changed.

These are not edge cases. They are what normally happens when routing is treated as plumbing.

The teams that get it right treat the route map as a shared contract between the web team and the mobile team. Agreed early, maintained like an API. Doing that at the start costs almost nothing. Doing it to a live app with an established URL structure costs a lot.

The same logic applies to where people land once they are inside. AI-Led wrote about behaviour-triggered onboarding flows, and a deep link is the first step in that chain.

The Australian details

A couple of things catch local teams out.

Use the `/au/` App Store URL for Australian campaigns, or drop the country code and let Apple redirect. Hard-coding a `/us/` URL still works, but it adds a redirect and can break attribution.

Bigger one. Apple fetches your association file through its own servers, not from the phone. Google does the same at install time. If your server blocks non-Australian IP ranges, or sits behind a firewall rule that does, that fetch fails and your links quietly stop working. Check your logs and confirm those requests get a 200.

If you ship regional variants with different bundle IDs, the store URL differs too. Confirm the right identifier before the campaign links go out.

When to bring in help

Most teams can wire up a basic Universal Link in a day. It gets harder fast.

Worth getting help when:

• You need matching behaviour on iOS and Android at the same time
• You are retrofitting links into an app that was never built for them
• You need deferred deep linking with attribution that finance will believe
• Marketing changes campaign paths often and cannot wait for an app release
• You have a launch date and cannot afford a broken link

Devwiz has shipped 200+ apps, including work for the NSW Government, Briometrix, Vivid and Huskee. We also built CARED, a national allied health platform running four mobile apps and three web platforms, where routing between apps had to work every time.

We handle the whole routing layer as part of a mobile app development build. Association files, intent filters, server-side routing, deferred links, analytics. Not bolted on at the end.

If you are still choosing a team, our mobile app development company page covers how we work, and app store optimisation covers what happens once people reach your listing.

Sort the routing before launch. Retrofitting it later is the expensive version.

Frequently asked questions

Do mobile apps have a URL?

Yes, three kinds. HTTPS verified links (Universal Links on iOS, App Links on Android) open content inside the app. Custom schemes like myapp://product/42 open a specific app. Store listing URLs point at your App Store or Google Play page. Use HTTPS links for anything public.

How do you get a mobile app URL for your app?

For store URLs, find your app in App Store Connect or the Google Play Console. Apple's format is https://apps.apple.com/au/app/name/id123456789 and Google's is https://play.google.com/store/apps/details?id=com.yourpackage. For deep links, you declare the paths in an apple-app-site-association or assetlinks.json file on your domain and handle them in your app.

What is the difference between a Universal Link and a custom URI scheme?

A Universal Link is a normal HTTPS URL verified by a file hosted on your domain, so it opens the browser when the app is missing and no other app can claim it. A custom scheme has no fallback and any app can register the same one, which is both a security risk and a lost conversion in public campaigns.

Why do my deep links not work inside Instagram or Slack?

Those apps open links in their own in-app browser, which does not trigger Universal Links or App Links. That is expected platform behaviour, not a bug. Your fallback page should detect the in-app browser and prompt the person to open the link in Safari or Chrome, where the operating system can route it to your app.

Why did my Android App Links stop working?

Usually one of four things. The assetlinks.json file redirects instead of returning 200, its content type is not application/json, the SHA-256 fingerprint no longer matches the certificate that signed the installed build, or android:autoVerify is missing from the intent filter. Android also verifies at install time, so the file must be live before the app is installed.