En la web abierta, window.print() abre el cuadro de impresión del navegador y el usuario puede guardar en PDF o enviar a una impresora. Dentro de un WebView, esa misma llamada es un no-op silencioso. Android solo expone la impresión mediante una API del host, e iOS WKWebView ignora la llamada por completo. Un runtime propio del host hace la ponte de la impresión y la exportación a PDF: una API que produce un documento real en cada motor.
Android: imprimir es una API exclusiva del host
La documentación de Android es clara: para imprimir desde un WebView llamas webView.createPrintDocumentAdapter(jobName) y lo entregas al PrintManager del sistema; la página no puede disparar window.print() por sí sola. Los límites son duros: no se puede usar JavaScript para disparar la impresión, solo un trabajo de impresión por instancia de WebView a la vez, y los documentos HTML con atributos de impresión CSS como orientación horizontal no se soportan. Así, una página de pago con un botón Imprimir ticket que funciona en Chrome no hace nada dentro del WebView de la app. El desarrollador debe poseer la instancia, construir el adaptador y mostrar el cuadro del sistema; la exportación a PDF usa el mismo camino.
iOS: window.print() se ignora en silencio
En WKWebView, window.print() no abre el panel. La solución habitual inyecta un script que redefine window.print para enviar un mensaje a un WKScriptMessageHandler, y el lado nativo maneja UIPrintInteractionController. Aun así, iOS no tiene una impresión web silenciosa equivalente a escritorio: el controlador debe mostrar una interfaz visible de confirmación. No hay una impresión headless que la página alcance. La exportación a PDF es lo mismo: la ponte vive en la app.
Qué se rompe cuando la impresión muere
- Recibos e itinerarios no aparecen. Un botón Guardar PDF que funciona en Safari no hace nada en el WebView.
- Facturas e informes no se exportan. Los flujos financieros que usan imprimir-a-PDF pierden la salida.
- Comprobantes de logística y retail fallan. Listas de picking, etiquetas y recibos POS no se generan en la app.
- Los navegadores integrados empeoran. WeChat, Douyin y similares rara vez exponen impresión, así que el fallo se oculta en QA de escritorio.
La solución del runtime
Un runtime propio del host hace la ponte de impresión y exportación. La página llama a una API uniforme —runtime.print() o runtime.exportPdf()— y el host renderiza con PrintManager en Android y UIPrintInteractionController en iOS. Encabezado, pie, numeración y orientación se manejan de forma nativa y consistente. Una integración, cada motor, un formato.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Disparador | window.print() es no-op | runtime.print() uniforme |
| Ruta Android | El host debe cablear adaptador + PrintManager | PrintManager nativo |
| Ruta iOS | window.print() ignorado | UIPrintInteractionController nativo |
| Impresión por JS | Bloqueada | Ponte nativa |
| Exportar PDF | No desde la página | Una API |
| Consistencia | Por motor | Uniforme |
Una app nativa imprime un recibo en cada dispositivo. Un WebView estándar apenas en ninguno. Un runtime da a la página una superficie de impresión — y un PDF real al final.
Fuentes
- Android Developers — Imprimir documentos HTML —
createPrintDocumentAdapter+PrintManagery los límites: sin impresión por JS, un trabajo por WebView, sin atributos CSS de impresión. - Stack Overflow — Crear PDF desde un WebView en Android — el enfoque PrintManager que convierte un WebView en PDF desde API 19.
- Exchangetuts — Capturar window.print() desde un WKWebView — la redefinición de
window.printa unWKScriptMessageHandlermásUIPrintInteractionController. - 博客园 — iOS Safari/WKWebView sin impresión web silenciosa equivalente — el límite estructural en iOS WebView.
- MDN — window.print() — la API web que el WebView descarta en silencio.
