Publicar una aplicación móvil no significa que el proyecto haya terminado

Desarrollar una aplicación móvil y conseguir que esté disponible en las principales tiendas suele percibirse como la culminación de un proyecto. Después de meses de análisis, diseño, desarrollo, pruebas y procesos de publicación, la aplicación llega finalmente a los dispositivos de los usuarios.

Desde la perspectiva del negocio, es comprensible pensar que comienza entonces una etapa mucho más estable. Si la aplicación cumple su función y no necesitamos incorporar nuevas funcionalidades, ¿por qué habría que seguir interviniendo sobre ella?

La particularidad del software móvil es que una aplicación no evoluciona de forma aislada.

Aunque su funcionalidad permanezca exactamente igual, a su alrededor continuarán apareciendo nuevas versiones de iOS y Android, nuevos dispositivos, cambios en permisos y capacidades del sistema, nuevas versiones de librerías y SDK, modificaciones en servicios externos y nuevos requisitos técnicos y de distribución.

Y a todo ello se añade un elemento que diferencia especialmente a las aplicaciones móviles de otros productos digitales: para llegar a buena parte de sus usuarios dependen de plataformas de distribución gestionadas por terceros.

Por eso, que una app siga funcionando hoy no significa necesariamente que esté preparada para seguir haciéndolo mañana.

La aplicación puede no cambiar. Su entorno sí lo hará

Una aplicación publicada hace varios años puede continuar resolviendo exactamente la misma necesidad para la que fue diseñada. Eso no implica que el entorno tecnológico en el que se ejecuta permanezca intacto.

Los fabricantes presentan nuevas generaciones de dispositivos. Los sistemas operativos incorporan funcionalidades, modifican comportamientos y endurecen determinados requisitos de seguridad y privacidad. Algunas capacidades quedan obsoletas y otras empiezan a utilizarse de una manera diferente.

Aparecen además nuevas resoluciones, proporciones de pantalla, configuraciones de accesibilidad y características de hardware que una aplicación desarrollada años atrás no necesariamente contemplaba.

Esto no significa que cada nueva versión de un sistema operativo obligue a reconstruir una aplicación. Tampoco que todos los cambios tecnológicos tengan impacto sobre todos los proyectos.

Significa algo más sencillo: alguien debe comprobarlo.

Una aplicación mantenida profesionalmente no necesita cambiar porque haya aparecido un nuevo teléfono. Necesita que exista un proceso capaz de determinar si ese nuevo dispositivo, esa nueva versión del sistema operativo o ese cambio tecnológico afectan realmente a su funcionamiento.

La diferencia importante vuelve a estar, como ocurre con cualquier software empresarial, entre decidir conscientemente que no es necesario intervenir y simplemente no saber si es necesario hacerlo.

En una aplicación móvil existe un tercero que también decide: la plataforma de distribución

Cuando desarrollamos una aplicación web, la organización conserva un elevado grado de control sobre cómo y dónde se publica.

En el mundo móvil aparece una variable adicional.

Una aplicación distribuida públicamente a través de App Store o Google Play debe convivir con los requisitos establecidos por esas plataformas. Y esos requisitos no son permanentes.

Las tiendas evolucionan sus políticas, modifican condiciones técnicas, introducen nuevos requisitos de privacidad y seguridad y establecen progresivamente qué características deben cumplir las aplicaciones nuevas, las actualizaciones e incluso, en determinados casos, aplicaciones que llevan tiempo publicadas.

Google Play, por ejemplo, actualiza periódicamente los niveles de Android que deben utilizar como objetivo las aplicaciones que se publican o actualizan. Las aplicaciones existentes que quedan suficientemente alejadas de los requisitos actuales pueden ver limitada su disponibilidad para nuevos usuarios que utilizan versiones recientes del sistema operativo.

Apple también mantiene procesos destinados a revisar aplicaciones que llevan largos periodos sin actualizarse y que presentan una actividad muy reducida.

No se trata de interpretar estas medidas como una amenaza de las plataformas hacia los desarrolladores. Responden a una realidad lógica: Apple y Google también necesitan que el catálogo de aplicaciones que distribuyen evolucione junto con sus respectivos ecosistemas.

Para una empresa que dispone de una aplicación móvil, la consecuencia es importante.

Publicar una aplicación en una tienda no garantiza indefinidamente las mismas condiciones de distribución.

Mantener la publicación también forma parte del mantenimiento

Hay otra dimensión que con frecuencia queda fuera de las conversaciones técnicas: una aplicación no depende únicamente de su código.

Existen cuentas de desarrollador, certificados, credenciales, perfiles, configuraciones, información administrativa, declaraciones de privacidad y otros elementos necesarios para mantener la capacidad de publicar y actualizar el producto.

Algunos tienen fechas de renovación. Otros necesitan revisarse cuando cambian determinadas condiciones. Y las propias cuentas desde las que se gestiona la publicación requieren una administración continuada.

El caso del ecosistema Apple resulta especialmente visible porque la distribución mediante su programa de desarrolladores requiere mantener activa la correspondiente membresía. Pero el principio es aplicable de forma más amplia: la continuidad de una aplicación también depende de conservar correctamente los mecanismos que permiten administrarla y distribuirla.

Es relativamente fácil prestar atención a estas cuestiones durante el lanzamiento inicial, cuando el proyecto está activo y existe un equipo pendiente de cada detalle.

El problema aparece varios años después.

La persona que creó determinadas cuentas puede haber cambiado de responsabilidad. Un certificado puede estar próximo a caducar. Un proveedor puede haber dejado de colaborar con la organización. Las credenciales pueden estar vinculadas a procesos que ya nadie recuerda con precisión.

Nada de esto modifica una sola pantalla de la aplicación.

Pero todo ello forma parte de su ciclo de vida.

Que no necesitemos nuevas funcionalidades no significa que no necesitemos nuevas versiones

Existe una asociación habitual entre actualización y mejora funcional.

Si no queremos añadir nada, parece razonable pensar que tampoco necesitamos publicar una nueva versión.

Sin embargo, en una aplicación mantenida durante años pueden existir actualizaciones cuyo objetivo no sea ofrecer una nueva funcionalidad visible para el usuario.

Una nueva versión puede simplemente adaptar el proyecto a los requisitos actuales de la plataforma, actualizar una dependencia, corregir un comportamiento detectado en determinados dispositivos, mejorar compatibilidad, renovar algún componente técnico o preparar la aplicación para una próxima versión del sistema operativo.

Desde el punto de vista del usuario, aparentemente no ha cambiado nada.

Desde el punto de vista de la continuidad tecnológica, puede haber cambiado mucho.

Esta distinción es especialmente importante en aplicaciones empresariales cuya funcionalidad es deliberadamente estable. Un servicio de atención, una herramienta profesional, una aplicación logística o una solución vinculada a un proceso de negocio no necesita reinventarse cada pocos meses para justificar su existencia.

Pero estabilidad funcional y abandono tecnológico son conceptos completamente diferentes.

También debemos decidir hasta dónde queremos mantener la compatibilidad

La evolución de los dispositivos plantea además una cuestión que no siempre tiene una respuesta universal.

Mientras aparecen nuevos terminales y versiones de los sistemas operativos, otros dispositivos van envejeciendo y eventualmente dejan de recibir determinadas actualizaciones.

¿Debe nuestra aplicación seguir siendo compatible con todos ellos?

La respuesta depende del producto y, sobre todo, de sus usuarios.

Mantener compatibilidad con versiones muy antiguas puede incrementar la complejidad técnica y limitar la posibilidad de adoptar determinadas capacidades modernas. Eliminarla demasiado pronto, en cambio, puede dejar fuera a usuarios que continúan utilizando dispositivos perfectamente válidos para sus necesidades.

No debería tratarse de una decisión automática.

Una organización que conoce el parque de dispositivos desde el que se utiliza su aplicación puede tomar decisiones mucho más razonables sobre qué versiones mantener, cuándo ampliar requisitos y en qué momento dejar atrás determinadas generaciones.

Una vez más, mantener no significa actualizar todo indiscriminadamente. Significa disponer de información suficiente para decidir.

La compatibilidad no debería comprobarse cuando empiezan a llegar las quejas

Una nueva versión de iOS o Android puede introducir cambios que afecten a comportamientos que hasta ese momento funcionaban correctamente.

En ocasiones serán pequeños detalles visuales. En otras, pueden verse afectados permisos, notificaciones, autenticación, acceso a cámara o ubicación, almacenamiento, procesos en segundo plano, comunicaciones con otros servicios o funcionalidades específicas del dispositivo.

Esperar a que los usuarios descubran esos problemas en producción es una forma particularmente costosa de comprobar compatibilidad.

El mantenimiento permite anticiparse.

Revisar las versiones que se aproximan, evaluar cambios relevantes, probar la aplicación sobre sistemas actuales y futuros cuando sea posible y comprobar las funciones críticas antes de que una nueva versión alcance masivamente los dispositivos reduce considerablemente la incertidumbre.

El objetivo no consiste en garantizar que nunca aparecerá una incidencia. En software, esa promesa difícilmente sería responsable.

Consiste en no depender exclusivamente de los usuarios para descubrir que el entorno alrededor de nuestra aplicación ha cambiado.

Una app también envejece a ojos de sus usuarios

El mantenimiento móvil tiene además una dimensión que trasciende lo estrictamente técnico.

Los usuarios pueden ver cuándo se ha actualizado una aplicación, valorar su experiencia y consultar las opiniones de otras personas antes de instalarla.

Una aplicación que lleva mucho tiempo sin mostrar signos de evolución puede generar dudas, especialmente cuando compite con alternativas que sí transmiten una sensación de producto activo.

Esto no significa que debamos publicar versiones artificialmente para aparentar actividad.

Una aplicación empresarial tampoco necesita entrar en una carrera permanente por incorporar funcionalidades que nadie ha solicitado.

Pero existe una diferencia perceptible entre un producto estable y un producto aparentemente abandonado.

Actualizar cuando existe una razón técnica o funcional, mantener actualizada la información de la aplicación, responder cuando corresponde y demostrar que detrás del producto sigue existiendo una gestión activa contribuye también a la confianza.

En una aplicación móvil, el mantenimiento técnico y la percepción del producto están más relacionados de lo que puede parecer.

Las reseñas no son solamente una valoración pública

Las estrellas llaman inmediatamente la atención, pero probablemente la información más interesante se encuentre detrás de ellas.

Las opiniones de los usuarios constituyen una fuente continua de información sobre el funcionamiento real del producto.

Un comentario aislado puede responder a una situación particular. Cuando empiezan a repetirse determinadas observaciones, sin embargo, pueden aparecer patrones: dificultades con una funcionalidad, comportamientos inesperados en ciertos dispositivos, problemas después de una actualización, necesidades que no se habían contemplado o simplemente aspectos de la experiencia que los usuarios no entienden como esperábamos.

No todo comentario debe convertirse automáticamente en una tarea de desarrollo.

Escuchar no significa obedecer cada petición individual.

Significa incorporar esa información al proceso de mantenimiento y evolución del producto, contrastarla con datos técnicos y de uso y determinar si existe algo que merece ser investigado.

Además, las principales plataformas permiten responder a las reseñas. Gestionarlas adecuadamente no es solamente una cuestión de reputación: permite demostrar que el producto continúa teniendo detrás un equipo que escucha y puede aportar contexto, resolver dudas o identificar incidencias que requieren atención.

Una mala reseña puede ser también una señal técnica

Existe otro motivo por el que conviene supervisar las opiniones con cierta regularidad.

En ocasiones, el primer indicio de una incidencia no aparece en una herramienta de monitorización.

Aparece en una reseña.

“Desde la última actualización no puedo iniciar sesión.”

“No funciona en mi nuevo teléfono.”

“Las notificaciones han dejado de llegar.”

Individualmente, estos mensajes no demuestran necesariamente que exista un problema general. Pero cuando varios usuarios empiezan a describir comportamientos similares, la información adquiere otro valor.

Por eso las reseñas no deberían permanecer aisladas en el ámbito comercial o de marketing. Pueden formar parte de la observación técnica del producto.

La combinación de monitorización, información de las plataformas, comportamiento de la aplicación y feedback de usuarios ofrece una visión mucho más completa que cualquiera de esas fuentes por separado.

Mantener una aplicación móvil implica vigilar varios ciclos simultáneamente

Con el paso de los años resulta fácil que la responsabilidad sobre una aplicación se fragmente.

Alguien se ocupa de renovar una cuenta. Otra persona recibe las comunicaciones de la tienda. El departamento de marketing observa las reseñas. Un proveedor conserva el código fuente. Otro mantiene determinados servicios de backend. Y las actualizaciones técnicas se plantean únicamente cuando aparece una nueva necesidad de negocio.

Cada tarea puede estar razonablemente cubierta de manera independiente y, aun así, faltar una visión global.

Porque una aplicación móvil combina varios ciclos de vida simultáneos: el del propio producto, el de iOS y Android, el de los dispositivos, el de sus dependencias técnicas, el de los servicios con los que se integra, el de las políticas de distribución y el de las expectativas de sus usuarios.

El mantenimiento consiste precisamente en conectar todos esos ciclos.

No hace falta intervenir continuamente sobre todos ellos. Hace falta que alguien los observe, entienda cuándo un cambio puede afectar al producto y pueda actuar antes de que una obligación externa se convierta en una urgencia.

Actualizar también requiere método

Cuando finalmente es necesario intervenir, publicar una nueva versión tampoco debería convertirse en una operación improvisada.

Una actualización puede necesitar revisar dependencias, adaptar código, comprobar integraciones, validar permisos y verificar su comportamiento en distintas versiones de los sistemas operativos y dispositivos representativos.

También conviene volver a recorrer las funcionalidades realmente críticas para el negocio.

Una aplicación puede abrirse correctamente y, sin embargo, presentar un problema en un proceso de autenticación, una notificación, un pago, una lectura de cámara, una firma, una descarga documental o una integración concreta que solo utiliza una parte de los usuarios.

Después llega el proceso de distribución, con sus correspondientes compilaciones, configuraciones, revisión y publicación.

Por eso, disponer del código fuente no equivale necesariamente a disponer de la capacidad de mantener una aplicación.

Hace falta conservar también el conocimiento técnico, los accesos, la configuración, los procedimientos y la capacidad de construir, probar y publicar una nueva versión cuando sea necesario.

El momento más difícil para recuperar una aplicación es cuando necesitamos actualizarla urgentemente

Muchas aplicaciones pasan largos periodos sin requerir ninguna intervención significativa.

Eso, en sí mismo, puede ser una excelente noticia.

El problema aparece cuando esa tranquilidad hace que se pierda progresivamente la capacidad de actuar.

Años después puede surgir una modificación obligatoria de la plataforma, una incompatibilidad con una nueva versión del sistema operativo o una incidencia relevante. Y es entonces cuando descubrimos que el entorno de desarrollo ya no se reproduce fácilmente, que algunas dependencias han quedado atrás, que determinados accesos no están claros o que publicar una nueva versión requiere mucho más trabajo del previsto.

En ese momento, el problema ya no es únicamente realizar un cambio.

Es recuperar primero la capacidad de cambiar.

Un mantenimiento periódico reduce precisamente esa distancia. Permite que una aplicación pueda permanecer funcionalmente estable durante años sin que eso signifique perder el control técnico sobre ella.

Mantener no significa cambiar constantemente. Significa estar preparado cuando el cambio sea necesario

Una buena estrategia de mantenimiento móvil no debería convertir una aplicación estable en un proyecto de desarrollo permanente.

Tampoco debería introducir funcionalidades únicamente para demostrar actividad.

Su objetivo es mucho más práctico: conocer el estado real del producto y conservar la capacidad de intervenir con seguridad cuando exista una razón para hacerlo.

Eso implica revisar periódicamente compatibilidad y dependencias, seguir la evolución de los sistemas operativos y de las políticas de distribución, mantener bajo control cuentas y mecanismos de publicación, comprobar el comportamiento de la aplicación en dispositivos relevantes y escuchar lo que están experimentando sus usuarios.

Algunas revisiones terminarán con una actualización.

Otras concluirán que no es necesario hacer nada.

Ambos resultados son perfectamente válidos cuando proceden de una revisión consciente.

Una aplicación publicada sigue siendo un producto vivo

La vida de una aplicación móvil no termina cuando supera la revisión de la tienda y aparece disponible para descargar.

En realidad, es entonces cuando empieza la etapa más larga.

Durante los años siguientes cambiarán dispositivos, sistemas operativos, requisitos técnicos, políticas de distribución y expectativas de los usuarios. Algunas modificaciones serán importantes para nuestra aplicación y muchas otras no tendrán ningún efecto relevante.

La cuestión no es intentar reaccionar a todo.

La cuestión es tener a alguien que sepa distinguir una cosa de la otra.

Porque mantener una aplicación móvil no consiste únicamente en corregir errores o desarrollar nuevas funcionalidades. Consiste en conservar su compatibilidad, su capacidad de distribución, su relación con los usuarios y, sobre todo, la posibilidad de seguir evolucionándola cuando el negocio o el ecosistema tecnológico lo requieran.

Una aplicación puede pasar meses sin necesitar un solo cambio visible y estar perfectamente mantenida.

Lo importante es que ese silencio sea consecuencia de que no hay nada que hacer, y no de que nadie esté mirando.