Mobile app URLs are just links that open a specific screen inside an app instead of a website. You've got a few ways to make this happen. You can use custom schemes like myapp://product/123, HTTPS Universal Links or App Links (like https://example.com/product/123 which rely on AASA or assetlinks.json files), or deferred deep links that somehow manage to carry that product/123 payload all the way through an app install.
Pick the wrong approach and you'll end up with broken redirects, lost attribution data, and users staring at a blank screen. Here's how these links actually work on iOS and Android, what you can do with parameters, and how to test them before you ship.
What a mobile app URL is
A mobile app URL is just a link that opens a specific screen inside an app rather than a regular website. It can use a custom scheme, a standard HTTPS domain, or a hybrid format depending on the platform.
The catch is that the operating system needs to know which app owns the link, and whether that app is even installed. Regular web links don't have this problem. That's why Apple and Google built verification systems: Apple uses an apple-app-site-association file, and Google uses assetlinks.json. If you don't have these files set up, the OS just falls back to treating your link as a standard web address.
When you break it down, a mobile app URL usually carries three things:
- The scheme or domain (tells the OS which app to check)
- The path (tells the app which screen to load)
- Parameters (extra data like referral codes or campaign tags)
Honestly, maintaining all these verification files and fallback rules for every platform is a headache. Smler handles this routing logic automatically so you don't have to.
Mobile app URL examples by type: custom scheme, Universal Link, App Link
How these links behave depends entirely on whether the user actually has your app installed.
Custom schemes are the oldest format. They still technically work, but you can't click them directly from Safari or Chrome anymore because of security changes. Universal Links and App Links fix that by using standard HTTPS domains that the OS verifies against a hosted JSON file. Deferred deep links go one step further: they actually survive the app install process itself.
| Type | Example URL | Opens app when installed | What happens when not installed | Verification file |
|---|---|---|---|---|
| Custom scheme | myapp://product/123 |
Yes, if OS resolves the scheme | Error or blank screen, no fallback | None required |
| iOS Universal Link | https://example.com/product/123 |
Yes, directly in-app | Redirects to App Store | apple-app-site-association |
| Android App Link | https://example.com/product/123 |
Yes, directly in-app | Redirects to Play Store | assetlinks.json |
| Deferred deep link | https://example.com/product/123?ref=sms |
N/A, triggers install flow first | Redirects to App Store or Play Store, then resumes after open | Attribution SDK or Install Referrer |
You'll notice the exact same URL format works for both Universal Links and Android App Links. That's not a typo. A single HTTPS link can work flawlessly across iOS and Android, provided you have both verification files hosted on that domain.
Deep link URL examples with paths and parameters
A deep link URL usually combines a path with at least one query parameter. The path tells the app what to draw on the screen, and the parameters just tag along to pass tracking or personalization data.
Here are a few realistic examples:
https://example.com/product/123?ref=email
The app opens the product detail screen for item 123 and logs the referral source as email.
https://example.com/checkout?cart_id=9f82a1&promo=WELCOME10
The app resumes a saved cart and auto-applies a promo code at checkout.
myapp://profile/4521?utm_source=instagram&utm_campaign=fall_launch
The app opens a user profile and attributes the visit to an Instagram campaign.
https://example.com/article/9981?lang=fr
The app renders the article screen in French based on the lang parameter.
https://example.com/invite?code=ABCDE12345
The app opens an invite acceptance screen and validates the referral code server-side.
This is exactly why a plain custom scheme isn't enough on its own. You need those parameters to carry campaign, language, and session context so the app actually renders the right experience. Smler's analytics layer grabs these parameters automatically, so marketers can see which path or campaign tag drove the click without building custom logging logic from scratch.
Deferred deep link URL example: when the app is not installed
Deferred deep links are incredibly useful because they work even when the user doesn't have the app installed yet. The link routes them to the App Store or Play Store first, then passes the original path and parameters back to the app the first time they open it.
Say someone clicks https://example.com/product/123?ref=sms but doesn't have your app. Here's the flow:
- The OS checks for Universal Link or App Link support and finds nothing.
- The link falls back to a store redirect page.
- The user installs the app and opens it.
- The attribution SDK or Install Referrer API matches the fresh install to the original click.
- The app opens directly to
product/123instead of dumping them on the home screen.
This matching happens through Android's Install Referrer API or, on iOS, alternative mechanisms such as temporary clipboard-based attribution, as iOS does not provide an Install Referrer-style API. If you want a deeper technical breakdown of how this differs from a direct deep link, check out the deep linking vs deferred deep linking comparison. The actual implementation details are in the deferred deep links documentation.
Testing a mobile app URL on iOS and Android
You really don't want to test mobile app URLs in production. Catching broken redirects, missing verification files, and parameter parsing bugs before launch will save you a lot of headaches. Apple and Google both provide command-line tools so you can simulate clicks without running a live campaign.
On iOS, you can use xcrun simctl openurl to fire a link directly into the simulator. On Android, adb shell am start does the exact same thing for emulators or connected devices. Just remember that both platforms require their respective verification files to be reachable and properly formatted before links will open the app at all.
Rather than repeating every step here, I'll point you to two dedicated guides that cover the full process:
If you want to keep going down the rabbit hole:
- App Links vs Universal Links: Technical Comparison
- What Are iOS Universal Links? Complete Guide
- What Are Android App Links? Complete Expert Guide
Frequently Asked Questions
Q: What is an example of a mobile app URL?
A: It could be a custom scheme like myapp://product/123, an HTTPS Universal Link or App Link like https://example.com/product/123, or a deferred deep link that carries that same path all the way through an app install.
Q: What is the difference between a custom URL scheme and a Universal Link? A: A custom scheme only works if the app is already installed, and it can't be opened safely from a browser. A Universal Link uses a real HTTPS domain, works fine in browsers, and falls back to a normal webpage if the app is missing.
Q: Does a mobile app URL work if the app is not installed? A: It depends. A custom scheme usually just fails silently. A Universal Link or App Link opens a normal webpage. A deferred deep link will redirect the user to the app store and resume the original destination after they install the app.
Q: How do I test a mobile app URL?
A: You can use xcrun simctl openurl on an iOS simulator or adb shell am start on an Android emulator to simulate a click. Detailed steps are in the iOS and Android testing guides linked above.
Q: Do I need a verification file for every mobile app URL?
A: Custom schemes don't need one. But Universal Links require an apple-app-site-association file, and App Links require an assetlinks.json file hosted on your domain.
Q: Can one URL work as both a Universal Link and an App Link?
A: Yes. The same HTTPS URL (like https://example.com/product/123) works for both iOS and Android as long as both verification files are correctly configured on that domain.