Note: Application Deep Linking

Have you ever tapped on a URL link only to have it open an app instead of a website? This is known as deep linking. I hope the following note can help you in gaining greater understanding.

Basic Deep Linking

Deep linking allows apps to open specific content or trigger particular functionality within the app, based on a URL. There are two primary methods for deep linking in iOS and Android apps:

  1. Custom URL Scheme
  2. Universal Links (iOS) or App Links (Android)
Custom URL Scheme 
Both iOS and Android support custom URL schemes (e.g., myapp://) that allow apps to be opened directly via a unique URL. However, since these schemes can be defined without any centralized validation, there’s a risk that triggering a URL might unintentionally open a different app that uses the same scheme. Due to this security risk and lack of control, Custom URL Schemes are generally not recommended.

Universal Links (iOS) or App Links (Android)
Introduced after Custom URL Schemes, Universal Links (on iOS) and App Links (on Android) use standard HTTP/HTTPS URLs to open content or trigger functionality within an app. When a Universal Link or App Link is clicked, the operating system determines whether to open the link in the app or the browser. This method is more secure and flexible than Custom URL Schemes because it allows for greater control over link handling and avoids conflicts with other apps.

Cheatsheet:
Universal Links (iOS)
  • Supporting Apple Universal Links: Here 
  • Supporting Associated Domains: Here 

Key Takeaways Beyond Code Implementation:

  • Add the Associated Domains entitlement to the app.
  • Add a JSON file named apple-app-site-association to the website. For example: https://<fully qualified domain or subdomain>/.well-known/apple-app-site-association. This file specifies the app that is allowed to handle the links for the domain.
  • Since Apple cache the apple-app-site-association file content,  you may check its current state here: https://app-site-association.cdn-apple.com/a/v1/<fully qualified domain or subdomain>
Sample of apple-app-site-association, which opens the link in-app if the page at https://<fully qualified domain or subdomain>/sample/* is requested. Apple recommends using components, while popular articles suggest paths--I opted to use both for greater effectiveness.


App Links (Android)
  • Creating Links to App Content: Here 
  • Verifying App Links: Here 

Key Takeaways Beyond Code Implementation:

  • Add an Intent Filter to the app for link verification.
  • Publish a JSON file named assetlinks.json to the website as part of the Digital Asset Links protocol. For example: https://<fully qualified domain or subdomain>/.well-known/assetlinks.json. This file verifies the ownership of the app and domain, allowing the app to handle the links.

Deferred Deep Linking

Deferred deep linking extends the functionality of basic deep linking by allowing users to be redirected to specific content or functionality within an app, even if the app isn't installed when the link is first clicked.

  • Typically, a deferred deep linking service manages the user’s intent when they click on an HTTPS URL.
  • If the app isn’t installed, the service redirects the user to the appropriate app store.
  • After installation, the app automatically communicates with the deferred deep linking service to retrieve any stored user intent.
  • If a stored intent is detected, the app then opens the specific content or triggers the desired function, seamlessly completing the user journey.
Examples of deep linking services:
  • Branch.io
  • Adjust
  • AppFlyer
  • Firebase Dynamic Links (Deprecated - Service to be shut down on August 25, 2025)
Disclosure: This entry is based on a collection of my personal notes, and some of the information may be outdated or no longer relevant. If you notice any inaccuracies, please let me know in the comments. I appreciate your feedback and will correct the entry as needed. :)

Comments

Post a Comment

Popular posts from this blog

Words: You Aren't Gonna Need It (YAGNI)

Another daily muse. It’s not surprising that our technical team continues to discover unused functions within a particular feature library. Although the names of these functions may sound promising, the logic inside is often outdated, as they haven’t been refactored to align with the current context of the feature. Some of these functions were written ages ago. This is where I need to borrow a concept from my university days, when my mates and I often applied Extreme Programming (XP) principles in our software projects. The core idea: Don’t add functionality until it’s actually needed. This is essentially the You Aren't Gonna Need It (YAGNI) philosophy. To quote Ron Jeffries, a co-founder of XP, as taken from Wikipedia: "Always implement things when you actually need them, never when you just foresee that you [will] need them."
Read more

Words: Domain-Driven Development

Today, I stumbled upon a simple read on Reddit that serves as a reminder for both new and seasoned programmers about the importance of Domain-Driven Development (DDD). The post shared this article by Google: Write Change-Resilient Code with Domain-Driven Design . While it just touches on DDD, it's good enough to raise awareness. In case DDD is new to you, here’s a brief description from Wikipedia: Domain-Driven Development is a major software design approach that focuses on modeling software to match a domain based on input from that domain’s experts. DDD opposes the idea of having a single, unified model. Instead, it divides a large system into bounded contexts, each with its own model. For a more in-depth exploration of DDD, here are some useful articles: DDD 101: The 5-Minute Tour Domain-Driven Design (DDD) From my perspective, the DDD concept allows for simpler collaboration between technical teams and domain experts through the use of a consistent language. It also reduces th...
Read more

Words: Chaos Engineering

"Chaos Engineering" is a rather cool IT discipline, but I haven't had the privilege of implementing it—perhaps because the systems I work with are never complex enough to require such a high degree of redundancy. Essentially, chaos engineering involves testing a system by introducing controlled faults or failures to identify its weaknesses and ensure it can handle unexpected disruptions. Examples of Chaos Engineering : Killing servers or nodes in a High Availability configuration to see if the service continues to run as expected. Introducing latency between servers/nodes (in a microservices environment) to observe how the system handles slow communication. Why It’s Important : Proactive Resilience : It helps you uncover weaknesses before they escalate into actual incidents, enabling teams to build more resilient systems. Improved Incident Response : By simulating real-world failures, teams gain valuable experience in handling outages, making them better equipped to resp...
Read more