How Deep Linking Standards Are Evolving

Deep linking has gone through three distinct generations, each solving problems the previous generation could not. Understanding this evolution helps you make better technical decisions today and prepare for what comes next.

For the current state of standards, see deep linking standards in 2026. For the practical comparison, see URI schemes vs Universal Links.

Generation 1: Custom URI Schemes (2008-2014)

How They Worked

The first deep linking mechanism was custom URI schemes. Apps registered a scheme (myapp://), and any URL using that scheme opened the app:

myapp://products/shoes
twitter://user?screen_name=example
fb://profile/123456

Introduced with the original iPhone SDK, URI schemes were simple: register a scheme in your app's Info.plist, and iOS routes matching URLs to your app.

What They Got Right

• Simple to implement. One entry in a configuration file.
• Reliable when the app is installed. The OS routing is fast and direct.
• No server required. The scheme is local to the device.

What They Got Wrong

• No fallback. If the app is not installed, the URL fails silently or shows an error. There is no web page to fall back to.
• No ownership. Any app can register any scheme. Two apps registering myapp:// creates a conflict with no resolution mechanism.
• No verification. No way to prove that the scheme belongs to a specific developer or domain.
• No web discoverability. Search engines cannot index myapp:// URLs.
• Platform-specific. The same scheme might work differently on iOS and Android, or not at all on the web.

Legacy

Custom URI schemes are still supported on both iOS and Android, but Apple and Google both recommend against them for new development. They remain useful for one specific case: detecting whether an app is installed (via canOpenURL on iOS).

Generation 2: Platform Links (2015-Present)

Universal Links (iOS 9, 2015)

Apple introduced Universal Links to solve the URI scheme problems:

https://yourapp.com/products/shoes

Key changes:

• Standard HTTPS URLs. The same URL works on the web and in the app.
• Domain verification. The app must prove it owns the domain via the apple-app-site-association file.
• Automatic fallback. If the app is not installed, the URL opens in Safari.
• No scheme conflicts. Only one app can claim a verified domain.

App Links (Android 6, 2015)

Google introduced App Links with a similar approach:

https://yourapp.com/products/shoes

Key changes:

• Domain verification via assetlinks.json (Digital Asset Links).
• Auto-verify attribute in the manifest.
• Fallback to Chrome if the app is not installed.

What Generation 2 Got Right

• Web compatibility. Deep link URLs are web URLs. They work everywhere.
• Security. Domain verification prevents claiming someone else's URLs.
• SEO. Deep link pages are indexable by search engines.
• Fallback. Users without the app see a real web page.

What Generation 2 Still Gets Wrong

• Complex setup. Verification files, entitlements, signing certificates, and manifest declarations all must align.
• Fragile verification. A CDN misconfiguration, a certificate rotation, or a server outage can break verification silently.
• No deferred deep linking. The standard does not handle the "install and then route" flow. That requires third-party libraries or custom code.
• Platform differences. iOS and Android have different verification mechanisms, different failure modes, and different edge cases (like in-app browsers).
• No standard for context passing. How to pass parameters, authentication tokens, or state through a deep link is left to each developer.

Generation 2.5: Platform Enhancements (2020-2026)

Both Apple and Google have iterated on their deep linking standards:

Apple Enhancements

Year	Change
iOS 13	Associated Domains debugging improvements
iOS 14	App Clips use the same AASA file
iOS 15	Managed Associated Domains for MDM
iOS 16	AASA file caching improvements, developer mode for testing
iOS 17	App Intents integration with Universal Links

Google Enhancements

Year	Change
Android 12	Stricter App Link verification (must auto-verify)
Android 13	Per-app language preferences affect deep link routing
Android 14	Improved handling of conditional navigation
Android 15	Enhanced security for intent verification

The Missing Standard: Deferred Deep Linking

Neither Universal Links nor App Links solve deferred deep linking (routing a user to specific content after they install the app for the first time). This gap has been filled by:

1. Platform-specific APIs:

   • Android Install Referrer API (passes parameters through install)
   • iOS SKAdNetwork (aggregate attribution only, no deep link routing)
   • iOS Smart App Banner app-argument (limited context passing)

   Third-party services:

   • Deep linking platforms that use cookies, clipboard, or fingerprinting
   • Custom server-side matching

   Custom implementations:

   • Server-side click ID generation and matching
   • First-party cookie-based matching

   There is no cross-platform standard for deferred deep linking. Each platform has its own partial solution, and none provides the full picture.

   What Comes Next

   Trends Shaping the Future

   AI Assistants and App Intents: Siri, Google Assistant, and other AI assistants need structured ways to invoke app actions. Apple's App Intents framework and Google's App Actions are early steps toward a standard for describing what apps can do, not just what URLs they handle.

   Privacy-First Attribution: As cross-app tracking becomes impossible, deep linking standards will need to incorporate privacy-preserving attribution directly. The current separation between "deep linking" (routing) and "attribution" (tracking) will likely merge into a unified, privacy-compliant standard.

   Cross-Platform Consistency: Web standards bodies (W3C, WHATWG) may eventually standardize how web URLs map to app content. The Web App Manifest and URL Handlers proposals are early indicators.

   Spatial Computing: VisionOS, Meta Quest, and other spatial platforms need deep linking standards for 3D content, scenes, and spatial anchors. Current URL-based standards do not capture spatial context.

   Practical Recommendations

   Given where standards are today:

   1. Use Universal Links and App Links as your primary deep linking mechanism.
   2. Own your domain. Do not rely on third-party deep link domains that you do not control.
   3. Build web fallback pages for every deep link URL.
   4. Implement deferred deep linking using platform APIs (Install Referrer on Android, Smart App Banner on iOS) supplemented by server-side matching.
   5. Add structured data to web pages for search engine and AI assistant compatibility.
   6. Test verification regularly. Automated monitoring catches issues before users do.

   Tolinku and Deep Link Standards

   Tolinku implements the current generation of deep linking standards: Universal Links, App Links, custom domain routing, and web fallback pages. As standards evolve, Tolinku adapts the underlying implementation while keeping your deep link URLs stable.

   Configure your deep links in the Tolinku dashboard. For more on the future direction, see the future of mobile deep linking.