Publicado: 21 de enero de 2026
A partir de Chrome 144, se optimizó el proceso de actualización de las apps web instalables que tienen un manifiesto de app web, lo que lo hace más determinístico, predecible y eficiente. En esta publicación, se explica el enfoque actual y los cambios que realizamos para mejorarlo.
El enfoque anterior (antes de Chrome 144)
Antes de Chrome 144, las aplicaciones web no tenían un evento específico para activar actualizaciones de forma proactiva. En cambio, las actualizaciones pueden ocurrir cuando los desarrolladores modifican el manifiesto de la app o sus íconos asociados. El proceso de actualización comienza cuando un agente de usuario recupera un manifiesto a través de un vínculo de manifiesto, lo que suele ocurrir cuando un usuario visita un sitio o inicia una app (con ese manifiesto vinculado). Para determinar si se requiere una actualización, el sistema compara el manifiesto y los íconos actuales con el estado registrado anteriormente. Este procedimiento requería muchos recursos, ya que siempre era necesario descargar íconos de la red para realizar una comparación de mapas de bits.
Para mitigar la carga del servidor debido a las descargas de íconos, Chrome implementó una limitación para restringir estas verificaciones a una vez al día por app, pero el consumo total de ancho de banda siguió siendo alto. Además, restringir las verificaciones a una vez al día genera inconsistencias durante el desarrollo y las pruebas, y dificulta que los desarrolladores proporcionen soluciones confiables a los usuarios que no recibieron actualizaciones.
Con este enfoque, los desarrolladores debían superar complejidades cuando implementaban cambios sensibles a la seguridad, como las actualizaciones del nombre o el ícono de una app, que a menudo se denominan cambios en la identidad de la app. Dado que las apps web no tienen una autoridad central como Google Play para revisar las actualizaciones, estas modificaciones deben presentarse claramente a los usuarios para que las confirmen. Sin embargo, determinar el momento más adecuado para solicitar a los usuarios que realicen estos cambios seguía siendo un desafío.
Las iteraciones anteriores del diálogo de actualización también causaban confusión con frecuencia, ya que afirmaban que los íconos habían cambiado cuando visualmente parecían idénticos para el usuario. Este problema se debió a que se dependía de comparaciones directas de píxeles, que a menudo marcaban diferencias insignificantes. Si bien algunas variaciones se debieron a ajustes intencionales de los desarrolladores, muchas se produjeron porque las CDN volvieron a codificar las imágenes de forma dinámica. Esta activación excesiva y frecuente del diálogo de confirmación finalmente llevó a la inhabilitación de las actualizaciones de íconos en Chrome 91.
Para resolver este problema en Chrome para Android, se introdujo un umbral de diferencia visual hace varios años. Esto garantiza que la confirmación del usuario solo se solicite si los cambios en el ícono son significativos. Este perfeccionamiento permitió restablecer la actualización de íconos en Android, aunque la función permaneció inhabilitada para Chrome en computadoras.
Restricciones y objetivos para los cambios en las actualizaciones de las apps web
Los siguientes objetivos guiaron el desarrollo del nuevo proceso de actualización:
- Conserva las expectativas de los usuarios: Dado que la identidad de una app está intrínsecamente vinculada a su origen, no se deben alterar su nombre ni su ícono sin la aprobación explícita del usuario.
- Garantiza la coherencia funcional: Las aplicaciones deben mantenerse lo más actualizadas posible para todos los usuarios y garantizar una funcionalidad coherente.
- Proporciona UX y diálogos predecibles: Los desarrolladores deben poder anticipar fácilmente cuándo los usuarios encontrarán mensajes de interfaz relacionados con actualizaciones de nombres o íconos de apps.
- Optimiza el uso de la red: El mecanismo de actualización debe minimizar el tráfico de datos innecesario.
¿Qué cambió en Chrome 144?
Las actualizaciones de nombres e íconos ahora son opcionales
En el pasado, los usuarios se enfrentaban a un diálogo disruptivo que les exigía desinstalar la app o aceptar de inmediato los cambios de ícono y nombre. Se reemplazó por una sugerencia más fácil de usar a la que se accede desde un menú de 3 puntos expandido. Tras la selección, los usuarios ahora tienen la opción de ignorar por completo estos cambios de identidad si lo prefieren.
Si bien la mayoría de las actualizaciones del manifiesto se aplican de inmediato, los íconos y nombres de las apps, considerados miembros sensibles a la seguridad, se almacenan por separado. Esto permite que los usuarios revisen y apliquen estos cambios específicos cuando les resulte más conveniente.
Si haces clic en Revisar actualización de la app, se mostrará el diálogo revisado. El título cambia según los elementos que se actualizan.
Los íconos no se descargan si el campo de íconos no tiene cambios.
Ahora se considera que los íconos no cambiaron si el campo icons del manifiesto sigue siendo el mismo que en la última versión aplicada. Con esta nueva lógica, Chrome evita descargar íconos para la comparación visual, y trata las URLs de los íconos como Cache-Control:immutable.
Para activar una actualización del ícono, ahora los desarrolladores deben modificar los metadatos o la URL del ícono.
Se quitó la limitación de actualizaciones
Dado que Chrome ya no descarga íconos cada vez que encuentra un manifiesto para una aplicación instalada, se eliminó la restricción anterior, que limitaba las verificaciones de actualización a una vez por día. Ahora los desarrolladores pueden confiar en que la actualización se realizará de inmediato para todos los miembros no sensibles a la seguridad.
Cómo controlar las variaciones menores de los íconos en las diferentes plataformas
Para mejorar la experiencia del usuario, Chrome ahora aplica automáticamente las actualizaciones de íconos que muestran menos de un 10% de diferencia en una comparación píxel por píxel. Esto garantiza que las variaciones menores, como las que causa la recodificación de la CDN, no activen un diálogo de actualización confuso para el usuario.
Este permiso se limita a una vez por día para evitar posibles abusos. Si se producen más cambios dentro de ese período, el ícono se trata como una actualización estándar y se le solicita al usuario que confirme el cambio.
Ejemplo de actualización de ícono y nombre
{
"name": "Example App",
"short_name": "App",
"id": "https://www.example-app.com/",
"start_url": "https://www.example-app.com/index.html",
"scope": "https://www.example-app.com/",
"icons": [
{
"src": "https://www.example-app.com/img/app.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any"
}
],
... other attributes omitted ...
}
Cambiar la URL del ícono garantiza que el usuario verá un diálogo de actualización para cambiar el ícono.
{
"name": "Example App",
"short_name": "App",
"id": "https://www.example-app.com/",
"start_url": "https://www.example-app.com/index.html",
"scope": "https://www.example-app.com/",
"icons": [
{
"src": "https://www.example-app.com/img/app-NEW-URL.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any"
}
],
... other attributes omitted ...
}