Cuéntame sobre tu experiencia trabajando con Release Candidate (RC), ¿cómo has aplicado este enfoque en tus proyectos?

Utilicé la versión Candidate Release como la etapa final de pruebas antes del lanzamiento en la App Store.

El proceso generalmente incluía:

1. Construcción de RC basada en la rama release o main después de estabilización.
2. Subida de la compilación a TestFlight para un grupo de testers internos y/o beta testers externos.
3. Pruebas exhaustivas en diferentes dispositivos y versiones de iOS.
4. Corrección solo de errores críticos que bloqueaban el lanzamiento. Mejoras menores y errores no críticos se posponían para versiones futuras.
5. Si se encuentran errores críticos: creación de una rama de parche desde RC, corrección, creación de una nueva compilación RC y repetir los pasos 1-4.
6. Si el RC pasa con éxito las pruebas y no contiene errores críticos: lanzamiento de esta misma compilación en la App Store.

El uso de RC permitía minimizar el riesgo de lanzar una versión inestable, ya que la compilación utilizada para las pruebas era idéntica a la que llegaba a los usuarios finales. Esto aumentaba la confianza en la calidad del lanzamiento.