Polaris 2.0 Shopify: nuevo Admin y migración de apps

Interfaccia di una app Shopify che passa dal vecchio stile Admin a un layout moderno compatibile con Polaris 2.0

Polaris 2.0 ya está disponible como release candidate para interfaces App Home embedded, mientras el nuevo diseño del Admin de Shopify se despliega progresivamente desde el 15 de septiembre de 2026. Para quien desarrolla apps, el punto práctico es sencillo: las interfaces embedded no migran automáticamente y, a 28 de septiembre de 2026, Polaris 1.1 sigue siendo la recomendación estable para producción.

Shopify publicó la release candidate de Polaris 2.0 el 24 de septiembre. El nuevo bundle incluye los estilos necesarios para que los Polaris Web Components se adapten al diseño del Admin disponible en cada tienda. En las tiendas que ya tienen el nuevo Admin aparecen los nuevos colores, tipografía, espaciado e iconos; en las que todavía usan el diseño anterior se mantiene el aspecto compatible con Polaris 1.

Quién debe actualizar y quién no

Admin UI extensions y App Home UI extensions reciben automáticamente el diseño disponible para el merchant porque Shopify renderiza directamente esas superficies.

Una App Home embedded que renderiza su propia UI funciona de forma distinta. La adopción es explícita. Una app que permanece en Polaris 1 o en el endpoint legacy sin versión no pasa sola a Polaris 2. Si la interfaz todavía usa Polaris React o una UI custom, primero hay que evaluar la migración a Web Components compatibles.

Release candidate no significa stable

La documentación de Shopify sigue recomendando el canal estable de Polaris 1 para producción. Polaris 2.0 continúa siendo una release candidate y puede cambiar durante el periodo de prueba. La usaría ahora para preparar y validar la migración, no para mover automáticamente una app estable de producción.

Cuando Shopify promueva la 2.0 a stable, publicará el canal estable correspondiente. El cambio seguirá siendo una decisión explícita de la app.

Polaris React no es un simple cambio de versión

Las apps que ya utilizan Polaris Web Components pueden empezar las pruebas cambiando el bundle cargado y verificando la interfaz. Las apps basadas todavía en Polaris React necesitan una migración más cuidadosa. Shopify está publicando guías componente por componente y no todas las primitivas antiguas tienen un equivalente uno-a-uno.

El objetivo no debe ser copiar píxel por píxel. Hay que preservar comportamiento y accesibilidad: foco de teclado, estados de error, selección, navegación, responsive y flujos de guardado deben seguir funcionando después del cambio de componentes.

Checklist de prueba para una App Home embedded

Probar el Admin nuevo y el anterior. Durante el rollout, la misma app puede verse en ambos contextos.
Comprobar Page, Section y acciones principales. Son los elementos con mayor impacto visual.
Revisar CSS custom. Los estilos que reproducen manualmente colores, sombras o espaciados antiguos pueden quedar incoherentes.
Verificar contenido sticky o fixed. Sidekick aparece ahora como chat flotante en la parte inferior del Admin y puede cubrir controles cercanos al borde.
Probar responsive, zoom y teclado. Anchos reducidos, textos traducidos largos y foco visible son puntos de regresión frecuentes.
Terminar con pruebas funcionales. Formularios, filtros, modales, navegación y guardados deben producir los mismos resultados.

Shopify también proporciona una variable CSS de safe area inferior para evitar que el contenido fijo quede cubierto por la barra flotante de Sidekick.

Built for Shopify: la fecha que conviene recordar

Para las apps que participan en Built for Shopify, Shopify indica el 1 de mayo de 2027 como fecha límite para que la App Home embedded refleje el estilo del Admin. Esto no obliga a llevar hoy una release candidate a producción: es una ventana para preparar, probar y después adoptar la versión estable.

Tres errores que evitaría

Primero: tratar la release candidate como si ya fuera stable. Segundo: rediseñar manualmente la app para imitar el Admin en lugar de usar primitivas compatibles. Tercero: comprobar solo el aspecto e ignorar accesibilidad y comportamiento.

En el desarrollo de apps Shopify trataría Polaris 2.0 como un gate de migración separado de la release funcional: entorno de prueba, migración incremental donde sea necesaria, regresión de los flujos del merchant y solo después decisión sobre el paso a stable.

El mismo principio vale para el monitorizado técnico: un cambio no termina porque el código haya cambiado, sino cuando el runtime real confirma el comportamiento esperado. Para el trabajo con coding agents y documentación actualizada, consulta también Shopify AI Toolkit y la skill única shopify.