El caso simple
Un deep link es una URL que nombra un destino dentro de una app en lugar de una página en la web: un producto, una invitación, un hilo de chat, un restablecimiento de contraseña. Cuando la app está instalada, el sistema operativo le entrega el enlace y esta abre esa pantalla en vez de que el navegador abra una página.
Hay dos mecanismos que hacen esto, y no son intercambiables.
Los esquemas de URL personalizados —myapp://product/42— son la forma más antigua. Cualquier app puede reclamar cualquier esquema y nada verifica esa reclamación, así que dos apps pueden pelearse por el mismo. Peor aún, la URL no significa nada fuera del dispositivo: si se toca sin la app instalada no lleva a ninguna parte, y no puede publicarse donde un navegador pueda abrirla. Los esquemas siguen teniendo sentido en traspasos entre apps del mismo dispositivo; son una mala base para enlaces que envías a otras personas.
Los Universal Links de iOS y los App Links de Android son URLs https:// corrientes que tu app reclama sirviendo un archivo de asociación firmado desde tu propio dominio: apple-app-site-association y assetlinks.json respectivamente. La plataforma descarga ese archivo y verifica la reclamación, así que nadie puede secuestrar tus enlaces, y esa misma URL sigue funcionando como página web para quien no tenga la app. Esta es la forma sobre la que construir.
Tres cosas que la gente llama «deep link»
| Qué hace | Sin la app instalada | |
|---|---|---|
| Esquema personalizado | Abre una pantalla mediante una URL privada myapp:// | No pasa nada: el enlace es un callejón sin salida |
| Universal / App Link | Abre una pantalla mediante una URL https:// verificada | Cae de vuelta a tu página web |
| Deep link diferido | Abre una pantalla después de instalar la app | Manda al usuario a la tienda y restaura el destino en el primer arranque |
Casi todas las discusiones sobre deep linking son en realidad gente usando una de estas tres palabras y oyendo otra. Las dos primeras son configuración. La tercera es un problema de ingeniería de verdad.
El caso difícil: sobrevivir a una instalación
Todo lo anterior asume que la app ya está ahí. Cuando no lo está, el toque manda al usuario a la App Store o a Google Play, y la app que acaba arrancando es una instalación nueva sin memoria de lo que se tocó. Aterriza en una pantalla de inicio genérica y lo que quería ha desaparecido.
El deep linking diferido es la parte que lleva el destino a través de ese hueco, y es difícil por una razón concreta: entre el toque y el primer arranque no hay estado compartido. Una app recién instalada nunca ha visto la sesión de navegador que inició el viaje, así que algo tiene que colar una carga útil a través de una frontera del sistema operativo construida deliberadamente para impedir justo eso.
Los mecanismos son específicos de cada plataforma. En iOS, un App Clips puede capturar el enlace antes de que exista la app completa y traspasarlo mediante un contenedor compartido. En Android, la API de Install Referrer entrega los parámetros de campaña de forma determinista en el primer arranque. Firebase Dynamic Links escondía ambos tras un único SDK, y cerró en agosto de 2025, que es por lo que esta vuelve a ser una pregunta abierta y no una cuestión zanjada.
Vale la pena nombrar los dos atajos que parecen más fáciles para poder rechazarlos. El fingerprinting de dispositivo empareja un navegador y una app por dirección IP, tamaño de pantalla e idioma dentro de una ventana corta; se degrada mal en redes compartidas y de operador, y el emparejamiento probabilístico de usuarios es exactamente el patrón contra el que empujan las reglas de privacidad de las plataformas. El emparejamiento por portapapeles copia la carga útil y la lee al arrancar; desde iOS 14 muestra al usuario un aviso de pegado, y cualquier otra copia por medio la destruye. Ambos son conjeturas disfrazadas de infraestructura.
Dónde se rompe en la práctica
- El archivo de asociación. Una redirección, un content type equivocado o una caché obsoleta y la plataforma deja de honrar tu reclamación sin decir nada. El síntoma no es un error: es que tus enlaces abren la web en vez de la app, algo fácil de pasar por alto en pruebas y caro en producción.
- Los navegadores integrados. Los enlaces que se tocan dentro de apps sociales a menudo se abren en una webview embebida que nunca traspasa al sistema operativo, así que un universal link que funciona desde Mensajes no hace nada desde un feed.
- Sin alternativa web. Si detrás de la URL
https://no hay una página real, todo el que no tenga la app recibe un 404: exactamente el público que intentabas convertir. - Atribución. Sin un referrer que sobreviva a la instalación no puedes saber qué campaña produjo qué usuario, y las cifras de adquisición que reportas son estimaciones.
Cuándo compensa la molestia
Un enlace que deja a alguien en una pantalla de inicio genérica ha gastado el único momento de intención que te habían dado. El contenido compartido, las invitaciones, los restablecimientos de contraseña y toda campaña de adquisición de pago dependen de que el destino sobreviva al viaje, y también de ello depende saber cuánto pagaste por instalación.
No siempre compensa. Una app cuyo valor entero está detrás de un login por el que todo el mundo pasa igualmente, o un producto sin compartición ni adquisición de pago, puede lanzarse sin gestión diferida y no perder nada. El coste es real: un objetivo de App Clips es un segundo binario que compilar, firmar y mantener por debajo de 15 MB.
Escribimos la implementación completa —ambas plataformas y la cola de enlaces pendientes que espera al login antes de enrutar— en deep linking diferido después de Firebase Dynamic Links.