Una app nativa controla su propio medio: pantalla completa, reproducción automática y audio en segundo plano funcionan. Dentro de un WebView ese control desaparece. La pantalla completa necesita una vista nativa a medida que el host debe construir a mano; la reproducción automática se bloquea salvo que el host active dos banderas ocultas de configuración; y el audio en segundo plano muere en cuanto la app pasa a segundo plano. Un runtime propio del host ofrece un puente de medios: una superficie de reproducción predecible en todos los dispositivos.
El WebView no puede ir a pantalla completa solo
En Android, requestFullscreen() de HTML no hace nada para un <video> salvo que el WebChromeClient de la app sobreescriba onShowCustomView() y onHideCustomView(). El WebView entrega la superficie del vídeo al host y espera; si el host no implementa el callback, el botón de pantalla completa simplemente no funciona. El comportamiento entre versiones es peor: desde Android 4.0 el callback recibe una clase interna privada, así que detectar el fin o conectar controles propios implica reflexión y ramificación por versión.
iOS fuerza pantalla completa o silencio
En iOS, WKWebView deja allowsInlineMediaPlayback en false por defecto, así que incluso un vídeo playsinline salta al reproductor del sistema en cuanto empieza. La reproducción automática también está limitada: con el mediaTypesRequiringUserActionForPlayback por defecto, un autoplay silenciado aún necesita un gesto, así que el patrón "vídeo como banner" se bloquea en silencio. El Picture-in-Picture solo funciona si el reproductor inline ya es un AVPlayerViewController — y no puede activarse automáticamente al ir a segundo plano, porque un visibilitychange no es interacción del usuario.
Qué se rompe cuando el medio está a medias
- La pantalla completa es un botón muerto. Tócalo en Android y no pasa nada salvo que el host cableó
onShowCustomView. - El vídeo inline salta a pantalla completa. iOS ignora
playsinlinesalvo que el host fijara la bandera en configuración — cambiarla después falla en silencio. - La reproducción automática se bloquea. Sin gesto, sin reproducción; la única salida son dos banderas nativas ocultas.
- El audio en segundo plano muere. Al segundo plano, el medio del WebView se pausa; PiP es la única vía y no es automática.
- Caos entre versiones. La clase interna de Android y las banderas de iOS cambian en cada compilación del SO.
La solución del runtime
Un runtime propio del host controla el medio. El host implementa el traspaso de pantalla completa de forma nativa, expone una API de reproducción uniforme a la página, fija las banderas de inline y autoplay una vez en configuración, y puentea el audio en segundo plano a la sesión multimedia del SO. Una superficie de medio, todos los dispositivos, todas las versiones — en vez de una página que funciona en el teléfono del ingeniero y falla en el del usuario.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Pantalla completa | Muerto salvo que el host sobreescriba onShowCustomView | Traspaso dirigido por el host |
| Reproducción inline iOS | Ignora playsinline por defecto | Banda fijada en configuración |
| Autoplay | Bloqueado sin gesto | Política predecible |
| Audio en segundo plano | Se pausa al segundo plano | Puente a sesión multimedia del SO |
| Picture-in-Picture | No automático | Controlado por el host |
| Entre versiones | Falla por compilación | Estable |
Una app nativa nunca pierde el control de su medio. Un WebView común sí lo hace. Un runtime entrega a la página un reproductor predecible — y mantiene el audio vivo al segundo plano.
Fuentes
- Android Developers — WebChromeClient#onShowCustomView — el callback que el host debe implementar para vídeo a pantalla completa.
- webkit.org — Nuevas políticas de vídeo para iOS — por qué WebKit limita
playsinliney el autoplay. - Apple Developer Forums — PiP y reproducción en segundo plano en WKWebView — ingeniero DTS sobre el traspaso inline a PiP y los límites de
visibilitychange. - MDN — Guía de reproducción automática — las reglas de gesto y autoplay silenciado que aplica cada motor.
- Thomas Visser — Vídeo en autoplay en WKWebView — las dos banderas de WKWebView que hacen funcionar el autoplay inline.
