A deep link is a URL that opens a specific screen inside your mobile app instead of just launching home screen. When a user taps a link in an email, a push notification, or a social media post, deep linking routes them directly to relevant content: a product page, an order status screen, a specific chat thread.
Deep link testing verifies that this routing works correctly across every entry point, every app state, and both platforms. It sounds simple, but deep links touch OS, browser, your app's intent handling, and your backend routing logic all at once. A deep link that works from Safari might fail from Instagram's in app browser. A link that works when app is running might crash on cold start.
What is deep linking?
Deep linking is technology that connects URLs to specific screens inside a mobile app. What is deep linking in practice? It's a mapping: this URL pattern should open this screen with these parameters.
There are three types of deep links, and they work differently:
URI schemes are oldest approach. They're easy to set up but insecure (any app can register same scheme) and have no fallback when app isn't installed. Android deep linking with App Links and iOS Universal Links are modern standard because they use verified HTTPS domains and fall back to browser if app isn't installed.
For most mobile app deep link implementations, you'll use Universal Links on iOS and App Links on Android, with URI schemes as a fallback for older OS versions or specific use cases. A deeplink tester or deep link generator tool can help you validate your configuration before running full tests.
What should you test when testing deep links?
Deep link testing covers four layers. Most teams only validate first.
Configuration validation: Is your apple-app-site-association file correctly hosted? Is your assetlinks.json file properly signed? Are domain associations correct? Tools like Median's Deep Linking Validator check this automatically.
Routing validation: Does deeplink open correct screen with correct parameters? A deep link for yourapp://orders/1234 should open order #1234, not orders list. This is where UI level testing matters because you need to verify what appears on screen, not just that app launched.
State handling: Does link work across all app states? A deep link application needs to handle link when app is in foreground, in background, killed, or not installed. Each state has different code paths on both iOS and Android. This is one of harder testing types to get right because same link triggers different code paths in each state.
Entry point testing: Does link work from every source? Users tap deep links from browsers, emails, SMS, push notifications, social media apps, and QR codes. Each entry point handles URLs differently. An in app browser in Instagram or Facebook may strip your Universal Link behavior and open web fallback instead. App deep linking behavior varies depending on where user taps link.
How do you test deep links on Android?
Android deep link testing uses adb (Android Debug Bridge) to trigger links from command line and validate routing. Testing a deep link android setup involves both configuration checks and end to end flow validation.
Testing with adb:
# Test a URI scheme deep link
adb shell am start -a android.intent.action.VIEW \
-d "myapp://orders/1234" com.yourapp.package
# Test an App Link (HTTPS)
adb shell am start -a android.intent.action.VIEW \
-d "https://yourapp.com/orders/1234" com.yourapp.package
# Verify App Links configuration
adb shell pm get-app-links com.yourapp.packageThe am start command simulates a user tapping link. If deep link in android is configured correctly, app opens to specified screen. If not, Android shows a disambiguation dialog or opens browser.
Android specific testing scenarios:
- App Links verification status (check with adb shell pm get-app-links)
- Disambiguation dialog behavior (when multiple apps can handle link)
- Deep link behavior after app update (do verified domains persist?)
- Intent filter configuration in AndroidManifest.xml
- Behavior on Samsung, Xiaomi, and other OEM browsers that may handle links differently
- Deep link for app behavior when Google Play Services is outdated
Android deep links have an extra wrinkle: some OEM browsers (Samsung Internet, Xiaomi Mi Browser) handle link interception differently than Chrome. A deep link that opens app from Chrome might open web version from Samsung Internet. Your testing matrix should include at least two browsers per device.
How do you test deep links on iOS?
iOS deep link testing uses xcrun and Safari for validation.
Testing with xcrun (simulator):
# Open a Universal Link in the iOS simulator
xcrun simctl openurl booted "https://yourapp.com/orders/1234"
# Open a URI scheme deep link
xcrun simctl openurl booted "myapp://orders/1234"
Testing on real devices:
Type deep link URL into Safari's address bar and tap Go. If Universal Links are configured correctly, iOS opens your app directly. If not, Safari loads web page.
A common gotcha: long pressing a Universal Link and choosing "Open in Safari" permanently breaks Universal Link behavior for that domain on that device until user reinstalls app. This is an iOS behavior that catches QA teams off guard.
iOS specific testing scenarios:
- AASA file accessibility (must be at https://yourdomain.com/.well-known/apple-app-site-association with correct content type)
- Universal Link behavior in different browsers (Safari, Chrome, Firefox, in app browsers)
- Associated Domains entitlement in Xcode project settings
- Deep link behavior after iOS update (Universal Link associations can reset)
- Handling when user has denied app link association
- App clip integration with deep links (if applicable)
What does complete deep link testing matrix look like?
This is matrix most teams skip. They test one link from one source in one app state and call it done.
verify that correct screen opens with correct parameters. For "Not installed" scenarios, verify fallback behavior (app store redirect or web page).
Multiply this by number of deep link destinations in your app and number of device configurations in your test environment. A typical e commerce app has 10 to 15 deep link destinations (product, category, cart, order, profile, settings, referral, promo, wishlist). That's 100+ test scenarios.
How do you test deferred deep links?
Deferred deep links work when app isn't installed. The flow is:
- User taps a link (in an email, ad, or shared message)
- The link routes to app store because app isn't installed
- User installs app
- On first launch, app reads deferred deep link and opens correct screen
Testing deferred deep links is hard because flow crosses multiple systems: web browser, app store, app installer, and app itself. Attribution services like Branch, Adjust, and AppsFlyer handle deferred deep linking and provide testing tools.
To test deferred deep links manually:
- Uninstall your app
- Tap deep link (it should redirect to app store or a web fallback)
- Install app from store (or a test build)
- Launch app and verify it opens to correct screen
Automating this flow is difficult with traditional testing approaches because it involves app store and a fresh install. Deep app linking through deferred links is typically tested manually or through attribution service testing tools.
How do you automate deep link testing?
Manual deep link testing doesn't scale. With 10+ destinations, 4 app states, and 5+ entry points, you're looking at 200+ scenarios. Automation is only realistic path.
For Android, UI Automator can trigger deep links via intents and verify resulting screen. But verification step (checking that right screen opened with right data) depends on selectors, which break when UI changes.
Drizz automates deep link testing end to end using Vision AI:
Open URL "https://yourapp.com/orders/1234"
Validate "Order #1234" is visible
Validate "Shipped" status is visible
Tap "Track Package"
Validate map screen is visibleThe test triggers deep link, then validates what appears on screen visually. No selectors needed. The same test works on iOS and Android because Drizz sees screen same way a user does. When order detail screen gets redesigned, test still passes because it's looking for "Order #1234" on screen, not for a specific resource ID in view hierarchy.
For teams that run deep link tests as part of their nightly regression, Vision AI handles verification step that traditional automation struggles with.
What does a real before and after look like?
A travel booking app had 12 deep link destinations (hotel, flight, itinerary, booking confirmation, loyalty points, referral, promo code, destination guide, review, support, profile, settings). The marketing team used deep links in emails, push notifications, and social ads.
Before: one QA engineer tested deep links manually before major campaigns. They covered 4 destinations from email links on 2 devices. Each campaign launch took half a day of deep link testing. They missed a bug where "itinerary" deep link opened home screen on cold start (intent was consumed before app finished loading). Users who tapped link from a kill state saw wrong screen.
After: 48 automated deep link tests run nightly in Drizz across 6 devices. Each destination is tested from a cold start, background, and foreground state. The cold start intent handling bug was caught in first automated run. Campaign launches no longer need manual deep link verification because nightly suite covers every destination and entry point.
The marketing team now ships campaigns confidently because they know every deep link has been validated on real devices night before. Tools like Drizz make this practical because Vision AI verifies screen content without selectors, and same plain English test works across iOS and Android.
FAQs
What is a deep link in a mobile app?
A deep link is a URL that opens a specific screen inside your app, not just home screen. A mobile app deep link like yourapp://orders/1234 or https://yourapp.com/orders/1234 routes users directly to order #1234. Deep links are used in push notifications, emails, social media, and marketing campaigns.
What are three types of deep links?
URI schemes (custom, like myapp://), Universal Links (iOS, HTTPS based with AASA file verification), and App Links (Android, HTTPS based with assetlinks.json verification). Universal Links and App Links are modern standard because they use verified domains and have web fallback when app isn't installed.
How do you test deep links on Android?
Use adb shell am start -d "yourlink" to trigger deep links from command line. Check App Links verification with adb shell pm get-app-links. Test from multiple browsers (Chrome, Samsung Internet) because OEM browsers handle link interception differently. Test across cold start, background, and foreground states.
How do you test deep links on iOS?
Use xcrun simctl openurl booted "yourlink" in simulator for basic testing. For real device testing, type URL in Safari. Verify your AASA file is accessible at correct path. Test Universal Link behavior across Safari, Chrome, and in app browsers. Watch for long press gotcha that breaks Universal Links for that domain.
What is a deferred deep link?
A deferred deep link works even when app isn't installed. The user taps link, gets redirected to app store, installs app, and on first launch app opens correct screen. Attribution services like Branch and AppsFlyer handle deferred deep linking. Testing requires a full uninstall install cycle.
What is biggest deep link testing mistake?
Testing only from one entry point in one app state. A deep link app might work from Safari when app is running but crash on cold start from a push notification. The full matrix (multiple entry points × multiple app states × both platforms) is where real bugs live. Automating this matrix with Vision AI tools catches bugs that manual spot checking misses.
