Debugging Deep Links – A Developer’s Toolkit (ADB, Charles, Safari Console, Postman)

Deep linking is a cornerstone of modern mobile user experience, but it can also be one of the hardest features to debug. This guide walks through practical debugging techniques using real-world developer tools to help you validate and fix deep link and attribution flows confidently.

Why Debugging Deep Links Is Tricky

Deep links depend on multiple systems working together:

• App configuration (AndroidManifest, Info.plist)
• Domain association files (AASA / assetlinks.json)
• SDK initialization timing
• Redirect chains and campaign parameters
• User state (installed vs not installed)

A small issue in any of these layers can break the entire experience. That’s why using the right debugging workflow is essential.

Step 1 – Confirm App Configuration

Before using any advanced tools, verify the basics.

Android

Check AndroidManifest.xml for correct intent filters:

<intent-filter android:autoVerify="true">
 <action android:name="android.intent.action.VIEW" />
 <category android:name="android.intent.category.DEFAULT" />
 <category android:name="android.intent.category.BROWSABLE" />
 <data android:scheme="https"
 android:host="myapp.com"
 android:pathPrefix="/product" />
</intent-filter>

Ensure assetlinks.json is accessible: https://myapp.com/.well-known/assetlinks.json It should declare your app package name and signing certificate.

iOS

Check Associated Domains inside Info.plist:

<array>
 <string>applinks:myapp.com</string>
</array>

Verify AASA file: https://myapp.com/apple-app-site-association

Once these base configurations are in place, move on to active debugging.

Step 2 – Simulate Deep Links with ADB (Android)

ADB (Android Debug Bridge) is one of the fastest ways to test how your app responds to links.

Launch your deep link manually:

adb shell am start -a android.intent.action.VIEW \
 -d "https://myapp.com/product?id=123" com.myapp.android

This command simulates a user clicking your link. If your app opens the wrong screen or shows no response, check the logcat output.

View logs for deep link activity:

adb logcat | grep "DeepLink"

Look for entries showing the incoming intent, URI, and route handling.

Step 3 – Use Safari Console for iOS Testing

On iOS, debugging universal links can be tricky because the OS silently falls back to Safari if something fails.

Enable the Developer Menu in Safari:

Go to Safari > Preferences > Advanced. Enable “Show Develop menu in menu bar”. Connect your iPhone or use a simulator.

Inspect universal link activity:

Open the link in Safari on the device. From Mac: Develop → [Your Device] → Console. Check for logs like: Checking AASA file... Associated domain verification failed...

Step 4 – Inspect Redirect Chains with Charles Proxy

Deep linking often involves redirects between ad networks, tracking URLs, and attribution endpoints before the app opens. Charles Proxy lets you capture and visualize this flow.

Step 5 – Validate APIs with Postman

Sometimes your link routes through APIs before reaching the final app link. Use Postman to validate these server-side redirect or attribution endpoints.

Step 6 – Verify SDK Initialization Timing

Deep linking and deferred linking rely on SDKs initializing before any navigation.

Step 7 – Debugging Attribution Mismatches

Sometimes installs or events don’t appear in dashboards. Recheck SDK version and keys. Append utm_* parameters to your link.

Step 8 – Privacy and Logging Hygiene

Always remember: debugging tools reveal sensitive data. Mask user identifiers before sharing logs. Avoid capturing PII in Charles or Postman screenshots. Keep logs only as long as needed for debugging.