Na web aberta, window.print() abre a caixa de impressão do navegador e o usuário pode salvar em PDF ou enviar para uma impressora. Dentro de um WebView, essa mesma chamada é um no-op silencioso. O Android só expõe a impressão por uma API do host, e o iOS WKWebView ignora a chamada por completo. Um runtime próprio do host faz a ponte da impressão e da exportação em PDF: uma API que produz um documento real em cada motor.
Android: imprimir é uma API exclusiva do host
A documentação do Android é clara: para imprimir a partir de um WebView você chama webView.createPrintDocumentAdapter(jobName) e entrega ao PrintManager do sistema; a página não dispara window.print() sozinha. Os limites são duros: não dá para usar JavaScript para disparar a impressão, apenas um trabalho de impressão por instância de WebView por vez, e documentos HTML com atributos de impressão CSS como orientação paisagem não são suportados. Assim, uma página de checkout com um botão Imprimir cupom que funciona no Chrome não faz nada dentro do WebView do app. O desenvolvedor precisa possuir a instância, montar o adaptador e mostrar o painel do sistema; a exportação em PDF segue o mesmo caminho.
iOS: window.print() é ignorado em silêncio
No WKWebView, window.print() não abre o painel. A solução comum injeta um script que redefine window.print para enviar mensagem a um WKScriptMessageHandler, e o lado nativo conduz o UIPrintInteractionController. Ainda assim, o iOS não tem uma impressão web silenciosa equivalente a desktop: o controlador precisa mostrar uma interface visível de confirmação. Não há pipeline headless que a página alcance. A exportação em PDF é a mesma história: a ponte vive no app.
O que quebra quando a impressão morre
- Recibos e itinerários não aparecem. Um botão Salvar PDF que funciona no Safari não faz nada no WebView.
- Faturas e relatórios não são exportados. Fluxos financeiros que usam imprimir-para-PDF perdem a saída.
- Comprovantes de logística e varejo falham. Listas de separação, etiquetas e recibos POS não são gerados no app.
- Navegadores integrados pioram. WeChat, Douyin e similares raramente expõem impressão, então a falha se esconde no QA de desktop.
A solução do runtime
Um runtime próprio do host faz a ponte de impressão e exportação. A página chama uma API uniforme —runtime.print() ou runtime.exportPdf()— e o host renderiza com PrintManager no Android e UIPrintInteractionController no iOS. Cabeçalho, rodapé, numeração e orientação são tratados de forma nativa e consistente. Uma integração, cada motor, um formato.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Disparador | window.print() é no-op | runtime.print() uniforme |
| Caminho Android | Host liga adaptador + PrintManager | PrintManager nativo |
| Caminho iOS | window.print() ignorado | UIPrintInteractionController nativo |
| Impressão por JS | Bloqueada | Ponte nativa |
| Exportar PDF | Não a partir da página | Uma API |
| Consistência | Por motor | Uniforme |
Um app nativo imprime um cupom em cada dispositivo. Um WebView padrão quase em nenhum. Um runtime dá à página uma superfície de impressão — e um PDF real no fim.
Fontes
- Android Developers — Imprimir documentos HTML —
createPrintDocumentAdapter+PrintManagere os limites: sem impressão por JS, um trabalho por WebView, sem atributos CSS de impressão. - Stack Overflow — Criar PDF a partir de um WebView no Android — a abordagem PrintManager que transforma um WebView em PDF desde a API 19.
- Exchangetuts — Capturar window.print() de um WKWebView — a redefinição de
window.printpara umWKScriptMessageHandlermaisUIPrintInteractionController. - 博客园 — iOS Safari/WKWebView sem impressão web silenciosa equivalente — o limite estrutural no iOS WebView.
- MDN — window.print() — a API web que o WebView descarta em silêncio.
