Un enlace o window.open dentro de un WebView no abre una nueva pestaña — no hace nada, en silencio. En Android el valor por defecto es setSupportMultipleWindows(false), que ignora toda petición de abrir una nueva ventana; para que funcione la app debe activar múltiples ventanas e implementar onCreateWindow y onCloseWindow, y la mayoría nunca lo hace. En iOS, el delegado createWebViewWithConfiguration de WKWebView devuelve nil por defecto, así que target=_blank se descarta en silencio salvo que la app implemente WKUIDelegate — y cuando lo hacen, suelen crear un segundo WKWebView cuyo historial de adelante y atrás está desconectado del primero. Un runtime propio del host aporta un único gestor de ventanas que mapea los popups a pestañas dentro de la app o a una entrega externa coherente, mantiene el historial intacto y nunca deja morir un enlace en silencio.
Android: las nuevas ventanas se ignoran por defecto
La documentación de Android es clara: por defecto el sistema ignora las peticiones de abrir nuevas ventanas, ya sea por JavaScript o por un atributo target. Para respetar target=_blank la app debe llamar a setSupportMultipleWindows(true) y sobreescribir onCreateWindow (y onCloseWindow para limpiar). Si falta la bandera, onCreateWindow nunca se llama: el toque no produce navegación, ni error, ni nada. El resultado práctico en el ecosistema es una larga cola de enlaces muertos de "abrir en nueva pestaña" que funcionan en un navegador real y desaparecen en el WebView.
iOS: el delegado que devuelve nil
WKWebView no tiene un modelo de pestañas o ventanas integrado; cuando una página pide un nuevo contexto de navegación, se lo pregunta a la app mediante WKUIDelegate.createWebViewWithConfiguration. La implementación por defecto devuelve nil, lo que significa que target=_blank y window.open se descartan en silencio. Los desarrolladores deben establecer el uiDelegate e implementar el método; la solución común recarga la petición en la misma vista (perdiendo la semántica de nueva pestaña) o crea un WKWebView totalmente nuevo — cuyo historial de adelante y atrás es independiente del original, así que el usuario queda atrapado sin forma de volver.
Qué pierdes sin un gestor de ventanas
- Enlaces muertos sin retroalimentación. Los toques target=_blank no hacen nada, así que el usuario cree que la página está rota.
- Historial roto. Un segundo WebView tiene su propio historial de adelante/atrás, desconectando al usuario de donde vino.
- Sin política coherente de enlaces externos. Algunos enlaces deberían quedarse en la app, otros entregarse al navegador del sistema; un WebView de fábrica no tiene regla.
- Contexto de sesión perdido. Un popup que debería heredar login o carrito arranca frío en un contexto aparte.
- Divergencia silenciosa. El mismo HTML abre una pestaña real en Safari y no hace nada en la vista embebida.
La solución del runtime
Un runtime propio del host aporta un único gestor de ventanas bajo la página. Mapea cada petición de nueva ventana a un resultado predecible — una pestaña dentro de la app que comparte el historial y la sesión, o una entrega externa claramente etiquetada al navegador del sistema — y nunca se traga un enlace en silencio. El autor de la página escribe un target=_blank estándar, y el runtime decide, de forma coherente y según política, qué sucede a continuación, en ambas plataformas.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Nueva ventana por defecto | Ignorada (Android) / delegado nil (iOS) | Mapeada a pestaña o entrega |
| Bandera Android | setSupportMultipleWindows + onCreateWindow | Gestionado por el runtime |
| Ruta iOS | WKUIDelegate.createWebViewWithConfiguration | Gestionado por el runtime |
| Historial de navegación | Roto en una segunda vista | Compartido, intacto |
| Política de enlaces externos | Ninguna, a ojo de cada app | Coherente, configurable |
| Enlaces muertos en silencio | Comunes | Nunca |
Un navegador trata target=_blank como una promesa: un contexto nuevo y alcanzable. Un WebView de fábrica lo trata como una petición que es libre de ignorar. Un runtime restaura la promesa — un gestor de ventanas, historial intacto y un enlace que siempre va a un lugar que el usuario puede ver.
Fuentes
- Android Developers — WebView 'Managing windows': peticiones de nueva ventana ignoradas por defecto; requiere setSupportMultipleWindows + onCreateWindow — el valor por defecto que descarta popups.
- Stack Overflow — onCreateWindow no se llama salvo que setSupportMultipleWindows(true) — la bandera faltante que mata el enlace.
- Apple Developer — WKUIDelegate createWebViewWithConfiguration: nil por defecto descarta target=_blank — la ruta silenciosa en iOS.
- Filip Němeček — Cómo abrir enlaces target=_blank en WKWebView en iOS — por qué los enlaces no hacen nada y el arreglo del delegado.
- MDN — Referencia del atributo target=_blank — el estándar web que el WebView viola en silencio.
