Shorebird y GitHub Actions: parches de Flutter sin revisión de tiendas
El code push de Shorebird permite entregar correcciones a apps Flutter ya instaladas sin cola de revisión, y el tutorial que circula explica cómo montarlo en GitHub Actions.
Shorebird permite actualizar apps hechas con Flutter sin volver a la cola de revisión de App Store ni de Play Store, y la gracia está en cómo se integra eso en un pipeline. La receta que circula esta semana monta dos flujos de trabajo sobre GitHub Actions: uno para releases completos, que sí acaban en la tienda, y otro para parches que llegan al usuario en minutos.
El mecanismo no es nuevo: Shorebird hace code push sobre el motor de Flutter, así que las correcciones escritas en Dart viajan al dispositivo sin recompilar el binario nativo. Lo que aporta el artículo es el pegamento de CI, que es donde casi todo el mundo se atasca.
Autenticación y acciones oficiales
El único paso de credenciales es una API key. Se genera en la consola de Shorebird, con nombre, caducidad y permisos, y hay que copiarla en el momento porque no se vuelve a mostrar. En GitHub vive como secreto de repositorio con el nombre exacto SHOREBIRD_TOKEN, y a partir de ahí está disponible en cualquier workflow.
Para no llamar a la CLI a mano hay tres acciones oficiales del proyecto: setup-shorebird@v1 instala la herramienta en el runner, shorebird-release@v1 crea el release y shorebird-patch@v1 genera el parche. El autor recomienda usarlas en lugar de invocar comandos sueltos, y mantiene su propia guía de integración con GitHub Actions con los mismos pasos.
Firmado y secretos
El flujo de release se dispara con etiquetas de versión o a mano, fija la versión de Flutter y decodifica el material de firma desde secretos. En Android eso significa reconstruir el keystore desde base64 y escribir el key.properties con alias y contraseñas. En iOS toca importar el .p12 y el perfil de aprovisionamiento a un llavero temporal. Al terminar, el APK el AAB o el IPA quedan como artefactos listos para subir.
El flujo de parche se dispara en cada push a main o manualmente, admite elegir plataforma y versión de release a parchear (por defecto, la última), y es el que evita la espera de la revisión. Es la parte que de verdad cambia el ciclo de entrega.
Qué mirar antes de copiarlo
El texto llega cortado justo en ese segundo workflow, así que la parte de patch queda esbozada y no se ve el fichero completo. Conviene además recordar los límites del code push: aplica a cambios de código Dart, no a plugins nativos ni a subidas de versión de Flutter, y Apple tiene sus propias reglas sobre qué se puede actualizar por esta vía. La revisión del binario inicial no se la salta nadie; las de después, sí.
