Het eenvoudige geval
Een deep link is een URL die een bestemming binnen een app aanwijst in plaats van een pagina op het web — een product, een uitnodiging, een gesprek, een wachtwoordherstel. Is de app geïnstalleerd, dan geeft het besturingssysteem de link door aan de app, en die opent dat scherm in plaats van dat de browser een pagina opent.
Twee mechanismen doen dit, en ze zijn niet uitwisselbaar.
Eigen URL-schema's — myapp://product/42 — zijn de oudere vorm. Elke app kan elk schema claimen en niets controleert die claim, dus twee apps kunnen om hetzelfde schema vechten. Erger nog: de URL betekent niets buiten het toestel. Aangetikt zonder de app leidt hij nergens heen, en je kunt hem nergens plaatsen waar een browser hem zou kunnen openen. Schema's hebben nog een plek in overdrachten tussen apps op hetzelfde toestel; als basis voor links die je naar mensen stuurt deugen ze niet.
Universal Links op iOS en App Links op Android zijn gewone https://-URL's die je app claimt door een ondertekend koppelingsbestand vanaf je eigen domein te serveren — respectievelijk apple-app-site-association en assetlinks.json. Het platform haalt dat bestand op en verifieert de claim, zodat niemand je links kan kapen, en dezelfde URL werkt nog steeds als webpagina voor wie de app niet heeft. Dit is de vorm om op te bouwen.
Drie dingen die mensen een "deep link" noemen
| Wat het doet | Zonder de app geïnstalleerd | |
|---|---|---|
| Eigen schema | Opent een scherm via een privé myapp://-URL | Er gebeurt niets — de link is een doodlopende weg |
| Universal / App Link | Opent een scherm via een geverifieerde https://-URL | Valt terug op je webpagina |
| Deferred deep link | Opent een scherm nadat de app is geïnstalleerd | Stuurt de gebruiker naar de winkel en herstelt de bestemming bij de eerste start |
De meeste discussies over deep linking gaan er in werkelijkheid over dat mensen een van deze drie woorden gebruiken en een ander horen. De eerste twee zijn configuratie. De derde is een echt technisch probleem.
Het lastige geval: een installatie overleven
Alles hierboven gaat ervan uit dat de app er al is. Is dat niet zo, dan stuurt de tik de gebruiker naar de App Store of Google Play, en de app die uiteindelijk start is een verse installatie zonder enige herinnering aan wat er is aangetikt. Ze landen op een generiek beginscherm, en waar ze voor kwamen is weg.
Deferred deep linking is het deel dat de bestemming over die kloof heen draagt, en het is moeilijk om een specifieke reden: tussen de tik en de eerste start bestaat er geen gedeelde staat. Een net geïnstalleerde app heeft de browsersessie die de reis begon nooit gezien, dus iets moet een lading over een OS-grens smokkelen die juist is gebouwd om precies dat tegen te houden.
De mechanismen verschillen per platform. Op iOS kan een App Clips de link opvangen voordat de volledige app bestaat en hem via een gedeelde container doorgeven. Op Android levert de Install Referrer-API de campagneparameters betrouwbaar af bij de eerste start. Firebase Dynamic Links verborg beide ooit achter één SDK, en die is in augustus 2025 gestopt — en daarom is dit weer een levende vraag in plaats van een afgehandelde.
De twee sluiproutes die makkelijker lijken zijn het benoemen waard, zodat je ze kunt weigeren. Device fingerprinting koppelt een browser en een app binnen een kort tijdvenster aan elkaar op IP-adres, schermformaat en taal; het gaat slecht op gedeelde en mobiele netwerken, en waarschijnlijkheidsmatching van gebruikers is precies het patroon waar privacyregels van platforms tegenin duwen. Klembordmatching kopieert de lading en leest die bij de start terug; sinds iOS 14 ziet de gebruiker daarbij een plakmelding, en elke andere kopieeractie ertussen vernietigt hem. Beide zijn gokjes vermomd als infrastructuur.
Waar het in de praktijk misgaat
- Het koppelingsbestand. Een redirect, een verkeerd contenttype of een verouderde cache, en het platform honoreert je claim stilletjes niet meer. Het symptoom is geen foutmelding — het is dat je links de website openen in plaats van de app, wat in tests makkelijk te missen is en in productie duur.
- In-app-browsers. Links die binnen sociale apps worden aangetikt openen vaak in een ingebedde webview die nooit aan het OS overdraagt, dus een universal link die vanuit Berichten werkt doet vanuit een feed niets.
- Geen webfallback. Zit er achter de
https://-URL geen echte pagina, dan krijgt iedereen zonder de app een 404 — precies het publiek dat je wilde overtuigen. - Attributie. Overleeft de referrer de installatie niet, dan kun je niet zien welke campagne welke gebruiker opleverde, en zijn de acquisitiecijfers die je rapporteert schattingen.
Wanneer het de moeite waard is
Een link die iemand op een generiek beginscherm dumpt, heeft het ene moment van intentie dat je kreeg verspild. Gedeelde content, uitnodigingen, wachtwoordherstel en elke betaalde acquisitiecampagne hangen ervan af dat de bestemming de reis overleeft — en dat geldt net zo goed voor weten wat je per installatie betaalde.
Het is niet altijd de moeite waard. Een app waarvan de hele waarde achter een login zit die iedereen toch bereikt, of een product zonder delen en zonder betaalde acquisitie, kan zonder deferred-afhandeling live en verliest daar niets mee. De kosten zijn echt: een App Clips-target is een tweede binary om te bouwen, te ondertekenen en onder de 15 MB te houden.
De volledige implementatie — beide platforms, en de wachtrij van openstaande links die op de login wacht voordat ze routeert — beschreven we in deferred deep linking na Firebase Dynamic Links.