Publicar y actualizar: lanzamiento por fases, versión mínima y planes de emergencia
Publicar una app es una puerta de un solo sentido: no existe la vuelta atrás, porque el binario que instaló el usuario no se puede sustituir por el anterior. Esta lección deduce de ese hecho todo lo demás: por qué el lanzamiento por fases es el único freno real y qué protege exactamente, cómo se elige el suelo de versión del sistema con datos propios en lugar de con estadísticas globales, y qué se hace de verdad cuando una versión sale defectuosa y no hay ningún botón que deshaga lo hecho.
Todo lo que distingue una operación de publicación madura de una improvisada se deriva de una única propiedad del medio: en la tienda no hay reversión. Se puede detener el avance de una versión, se puede publicar otra encima, se puede incluso retirar la app de la venta, pero no se puede devolver a nadie el binario que tenía ayer. Un despliegue de servidor se deshace en dos minutos; una versión de iOS defectuosa vive en los dispositivos hasta que cada usuario decida actualizar, lo que en la práctica significa días para la mayoría y semanas para la cola. Aceptar esa asimetría es lo que convierte la publicación en ingeniería en lugar de en un acto de fe.
- Decidir el momento de publicación entre liberación manual, automática o programada según lo que haya que coordinar.
- Usar el lanzamiento por fases sabiendo con precisión a quién alcanza y a quién no.
- Elegir la versión mínima del sistema con los datos de tus propios usuarios y entender qué les ocurre a los que quedan fuera.
- Preparar de antemano la respuesta a una versión defectuosa, incluidos los mecanismos que no viven en el binario.
Del aprobado al publicado
La aprobación y la publicación son dos hechos distintos y conviene no confundirlos. Una versión aprobada puede quedar esperando a que alguien la libere, salir automáticamente en cuanto pase la revisión, o programarse para una fecha. La liberación manual es la opción por defecto razonable para cualquier equipo que tenga algo que coordinar —una nota de prensa, un cambio en el servidor, una campaña— porque desacopla el momento impredecible del visto bueno del momento elegido de la salida.
Ese desacople también resuelve un problema táctico frecuente: enviar a revisión con antelación holgada y guardar la versión aprobada sin publicar. El coste de tener una versión lista y detenida es cero; el coste de descubrir un rechazo la víspera del lanzamiento es un retraso de días que nadie puede recuperar.
Si la versión nueva depende de un extremo de servidor, ese extremo tiene que estar desplegado y ser compatible con la versión antigua antes de liberar nada. La razón es la asimetría de esta lección: el servidor lo puedes revertir, el cliente no. Toda dependencia entre ambos debe diseñarse de modo que el lado reversible sea el que se mueve primero.
El lanzamiento por fases y lo que realmente frena
El lanzamiento por fases reparte la actualización a lo largo de una semana en proporciones crecientes, empezando por una fracción mínima de la base instalada. Se puede pausar en cualquier punto, reanudar, o pasar al cien por cien de golpe. Es el instrumento más valioso del proceso y también el peor entendido, porque casi todo el mundo cree que gobierna quién recibe la versión nueva, y no es así.
El reparto gradual solo gobierna las actualizaciones automáticas de quienes ya tienen la app. Cualquiera que entre a la tienda y pulse actualizar recibe la versión nueva de inmediato, y cualquiera que instale por primera vez recibe también la última. Es decir: durante la fase del uno por ciento tu versión ya está públicamente disponible. El freno limita la velocidad de propagación, no la exposición.
Exposición gradual
Una semana de reparto creciente convierte un fallo que habría alcanzado a todos en uno que alcanza a una fracción mientras aún hay tiempo de reaccionar.
Pausa
Detiene el avance manteniendo el porcentaje alcanzado. Es la primera acción ante cualquier anomalía y no cuesta nada equivocarse al usarla.
Observación comparada
Con dos poblaciones conviviendo puedes comparar tasa de fallos y comportamiento entre versión nueva y anterior, algo imposible en una salida instantánea.
Salida inmediata
Cuando la versión corrige un fallo grave, el reparto gradual juega en tu contra y conviene publicar al cien por cien desde el principio.
Ese último matiz se pasa por alto a menudo. El reparto gradual es la opción prudente para una versión que añade cosas y la opción equivocada para una que repara algo urgente, porque prolongar durante días la llegada de la corrección deja expuesta a la mayoría de la base instalada por pura inercia del procedimiento.
El suelo de versión del sistema
Subir la versión mínima admitida es una decisión de producto disfrazada de ajuste técnico. A favor: interfaces nuevas sin comprobaciones de disponibilidad, menos ramas de código, menos combinaciones que probar y menos defectos que solo se dan en sistemas antiguos. En contra: usuarios que dejan de recibir actualizaciones.
La parte que casi nadie sabe reduce mucho el dramatismo de la decisión. Quien tiene un sistema demasiado antiguo para tu versión nueva no se queda sin app: la tienda le ofrece la última versión compatible con su sistema, de modo que sigue instalando y usando el producto, solo que congelado en el punto en que dejaste de darle soporte. Eso convierte la pregunta en una mucho más manejable: no es a quién expulsas, sino a quién dejas de mejorar.
# Fijar el suelo de version desde la linea de comandos.
xcodebuild archive -scheme MiApp \
IPHONEOS_DEPLOYMENT_TARGET=18.0 \
-archivePath build/MiApp.xcarchiveLa decisión debe tomarse con los datos de tus usuarios y no con la estadística global del ecosistema, que casi siempre es más optimista que la realidad de una app concreta. Un producto orientado a empresas, a mercados con parque de dispositivos antiguo o a públicos que no actualizan tiene distribuciones muy distintas de la media. Y mientras el suelo no suba, la alternativa es adoptar las interfaces nuevas tras una comprobación de disponibilidad con if #available, que es el mecanismo correcto para aprovechar lo nuevo sin abandonar lo viejo.
Cuando algo sale mal
Ante una versión defectuosa la secuencia útil está fijada de antemano, porque improvisarla con el pulso acelerado sale mal. Primero se pausa el reparto, que es gratis y reversible. Después se mide el alcance real con la tasa de sesiones sin fallo y los informes entrantes, para distinguir un problema masivo de uno que afecta a una combinación rara. Solo entonces se decide entre esperar, corregir con calma o pedir una revisión acelerada, mecanismo reservado a fallos críticos y cuya credibilidad se agota si se usa por rutina.
flowchart TB d[Se detecta un fallo en produccion] --> p[Pausar el lanzamiento por fases] p --> m[Medir alcance real con sesiones sin fallo] m --> s[Se puede apagar desde el servidor] s --> f[Desactivar la funcion con una bandera remota] f --> t[Corregir con calma y publicar version normal] s --> n[No hay interruptor remoto] n --> u[Corregir y solicitar revision acelerada] u --> r[Publicar al cien por cien sin reparto gradual] m --> q[Alcance pequeno y acotado] q --> t
Lo que falta en esa secuencia es lo más importante: no aparece ninguna reversión, porque no existe. Retirar la app de la venta no la desinstala de ningún dispositivo ni devuelve a nadie la versión anterior; solo impide instalaciones nuevas, y suele ser un remedio peor que la enfermedad. La conclusión operativa es incómoda y liberadora a la vez: si quieres poder deshacer algo, ese algo no puede vivir únicamente en el binario.
Toda la disciplina de publicación en el ecosistema Apple se deduce de una sola restricción física: una vez que el binario está en el dispositivo, tú ya no mandas sobre él, y solo puedes añadir el futuro, nunca corregir el pasado. Frente a esa restricción existen exactamente dos palancas y conviene verlas como lo que son. La primera es la exposición gradual, que no elimina el riesgo sino que lo acota, comprando tiempo entre el instante en que un defecto empieza a existir y el instante en que alcanza a toda la base instalada; su valor no está en la lentitud sino en la ventana de detección que abre, y por eso es inútil si nadie está mirando los indicadores durante esa ventana. La segunda, mucho más poderosa y sistemáticamente infrautilizada, es mover la decisión fuera del binario: una función nueva gobernada por un interruptor remoto, un extremo de servidor que puede devolver la respuesta antigua, un texto que se descarga en lugar de compilarse. Cada pieza que sacas del artefacto inmutable es una pieza que recuperas para el terreno donde sí puedes deshacer, y esa es la razón profunda de que los equipos que publican sin miedo no lo hagan porque sus versiones sean mejores, sino porque han reducido deliberadamente la superficie de lo irreversible. El objetivo, enunciado con precisión, no es publicar sin errores: es garantizar que ningún error obligue a esperar a que el usuario actualice.
- Configura tu próxima versión con liberación manual y lanzamiento por fases, y escribe de antemano en qué indicador y con qué umbral pausarías.
- Consulta la distribución de versiones del sistema entre tus propios usuarios y decide con ese dato si subir el suelo de despliegue, calculando a cuánta gente dejarías de mejorar.
- Toma la función más arriesgada de esa versión y ponla detrás de un interruptor remoto, de modo que puedas apagarla sin publicar nada.
- Ensaya el procedimiento de emergencia completo con un fallo simulado: pausar, medir alcance, apagar la función y decidir si haría falta revisión acelerada.
- Escribe el documento de una página con esa secuencia y los umbrales acordados, y déjalo donde lo encuentre quien esté de guardia el día que ocurra de verdad.