Salon Symphony
Salon Symphony es un software de experiencia del empleado para salones y spas: chat de equipo, tareas, una biblioteca de políticas y capacitación, encuestas, eventos con confirmación de asistencia, solicitudes de tiempo libre y flujos de incorporación. Lo construyó otro equipo y salió en diciembre de 2023. A principios de 2024, las correcciones y funciones que quería su fundador no se podían construir sobre ese código, y Appluex lo retomó de febrero a abril de 2024.
La app estaba publicada en las dos tiendas, pero el código detrás se había quedado quieto. Corría sobre una versión de Flutter tan antigua que varias de las funciones pedidas ni siquiera existían en el framework, y varios errores abiertos no se podían resolver sin ellas. El primer obstáculo ni siquiera era el código: esa versión de Flutter ya no compilaba en una máquina actual, así que la app no se podía construir por más que se pidieran cambios. Todo lo que el fundador quería estaba detenido ahí, mientras salones que pagaban usaban el producto todos los días.
Empezamos por las herramientas, no por la lista de pendientes. Para compilar la app tal como estaba publicada, preparamos una computadora con un sistema operativo lo bastante antiguo como para que esa versión de Flutter volviera a construir, y ahí resolvimos primero lo urgente, publicando las correcciones sobre la misma versión que ya tenían los clientes. Solo cuando la app en producción quedó estable actualizamos el código a Flutter actual, resolvimos los cambios de ruptura en dependencias y en las capas de compilación de iOS y Android, y entonces construimos las funciones que la versión vieja nunca habría podido soportar. Cada publicación salió por las cuentas de desarrollador Apple y Google del propio cliente, que él controla.
Una mirada más cercana
El orden de los pasos fue el proyecto entero. Actualizar primero suena más rápido de contar y se vive peor: pone al cliente sobre una app reconstruida antes de que nadie haya comprobado cómo se comporta, y deja sin arreglar los errores de los que se quejan hoy durante todo lo que dure la migración. Así que partimos el trabajo en dos. Estabilizar sobre la versión que de verdad estaba publicada, porque el negocio está en marcha. Modernizar después, cuando ya no hay nada ardiendo.
Estabilizar significó resolver un problema de herramientas antes que uno de código. Cada versión de Flutter fija el SDK de Dart, las versiones de Gradle y Xcode que espera y los plugins que eran actuales en su momento, y los sistemas operativos nuevos van dejando ese conjunto sin soporte. La respuesta práctica no fue ingeniosa: buscamos una computadora con un sistema operativo lo bastante viejo como para que el conjunto original todavía se instalara y todavía compilara. Esa máquina se convirtió en la línea de mantenimiento de la app en producción, y desde ahí salieron las correcciones urgentes mientras el resto del trabajo seguía por delante.
La actualización a Flutter actual pasó entonces a ser un proyecto acotado y no una emergencia. Saltar tantas versiones de golpe implica dependencias que ya no existen en la versión fijada, APIs del framework que se renombraron o desaparecieron por el camino, y configuración de compilación de iOS y Android escrita contra herramientas que desde entonces cambiaron sus requisitos. Lo trabajamos con la app ya estable en producción, que es la única forma cómoda de hacerlo, y salimos con un código donde las funciones que el fundador venía pidiendo simplemente eran posibles.
La app está publicada bajo las cuentas de desarrollador del propio cliente, no las nuestras. Es el acuerdo que defendemos en todo este sitio: la empresa dueña del producto debe tener las cuentas de las tiendas, las llaves de firma y el código, para que cambiar de equipo sea una decisión y no un rescate. También es la razón por la que este proyecto pudo empezar.
La reseña del fundador en Clutch dice: "We were impressed with their ability to dive into an existing codebase without missing a beat!" y "Essiel and his team at Appluex were able to pick up the pieces and polish our product beyond expectation." El proyecto tenía un alcance definido y terminó en abril de 2024. Salon Symphony ha seguido su camino desde entonces, y la versión que hoy está en la App Store es una publicación mayor posterior moldeada por otro trabajo: lo que reclamamos como nuestro son los dos meses que sacaron al producto del atasco. La app sigue viva en las dos tiendas y mantiene una calificación de 4.4 sobre 7 valoraciones en la App Store desde su lanzamiento en diciembre de 2023.
Funciones principales
Un diagnóstico completo de un código Flutter sin mantenimiento
Un entorno de compilación antiguo capaz de construir la app tal como se publicó
Correcciones urgentes primero, sobre la versión que ya usaban los clientes
Actualización a Flutter actual, con dependencias y capas de compilación incluidas
Funciones que la versión anterior no soportaba, construidas después de actualizar
Publicaciones por las cuentas propias del cliente en App Store y Google Play
Preguntas comunes
¿Qué hizo Appluex para Salon Symphony?
Retomamos una app en Flutter construida por otro equipo. Resolvimos lo urgente sobre la versión antigua con la que la app se había publicado y después actualizamos el código a Flutter actual para que las funciones que quería el fundador fueran posibles. El proyecto corrió de febrero a abril de 2024.
¿Appluex puede hacerse cargo de una app que construyó otro equipo?
Sí. Revisar, corregir y retomar software construido por otro equipo es uno de nuestros servicios. Empezamos leyendo y compilando el código tal como está, así que lo primero que entregamos es una evaluación honesta de qué se puede arreglar tal cual y qué exige actualizar primero.
¿Por qué corregir errores en la versión vieja en lugar de actualizar primero?
Porque el producto estaba en producción y había clientes pagando que lo usaban. Actualizar primero habría retrasado cada corrección hasta terminar la migración y habría puesto a los clientes sobre una app reconstruida antes de comprobarla. Primero estabilizar, después modernizar.
¿Qué pasa cuando la versión del framework de una app es demasiado vieja para compilar?
Las herramientas son el primer problema a resolver. Una versión antigua del framework espera versiones antiguas de SDK, Gradle y Xcode que los sistemas operativos actuales ya no soportan, así que lo práctico es reproducir un entorno de compilación lo bastante viejo para construir la app tal como se publicó, sacar desde ahí las correcciones urgentes y después actualizar.
¿De quién son las cuentas de las tiendas?
Del cliente. Salon Symphony está publicada bajo sus propias cuentas de desarrollador de Apple y Google, y todas las publicaciones que hicimos salieron por ahí. Se lo recomendamos a cada cliente: tus cuentas, tus llaves de firma y tu código deben ser tuyos.
¿Listo para construir tu producto de rescate y modernización de apps?
Cuéntanos tu idea. Te ayudamos a lanzarla.
Empieza un proyecto →