Mantenimiento de apps móviles para empresas.

Nadie toca el código y aun así la app falla. Las causas habituales: cada versión de iOS y Android depreca APIs y cambia comportamientos (permisos, ejecución en segundo plano, notificaciones); Google Play exige un target SDK reciente — las apps que no actualizan dejan de poder publicar e incluso de ser visibles para dispositivos nuevos; las dependencias se abandonan (la librería de pagos, el SDK de analítica o el plugin de mapas que dejó de mantenerse y bloquea la actualización de todo lo demás); y los certificados y perfiles de firma caducan. Cada uno de estos frentes es rutinario si alguien lo vigila — y un incendio si nadie lo hace.

El patrón que más vemos en auditorías: una app que funcionó perfecta durante un año sin mantenimiento, y de repente necesita 15.000€ de saneamiento urgente porque la actualización obligatoria del target SDK arrastra una cadena de dependencias rotas. El mantenimiento regular existe precisamente para que esa bola de nieve no se forme.

El estándar de la industria sitúa el mantenimiento entre el 15% y el 20% anual del coste de desarrollo inicial. La cifra no es arbitraria: refleja las 2-4 actualizaciones de compatibilidad al año, la gestión continua de dependencias, la monitorización y un colchón para bugs. Una app de 40.000€ → 6.000-8.000€/año; una de 100.000€ → 15.000-20.000€/año.

Lo que abarata el mantenimiento: una sola codebase multiplataforma (mantener Flutter cuesta menos que mantener dos apps nativas), arquitectura limpia con tests, CI/CD que automatice los despliegues y un stack de dependencias conservador. Lo que lo encarece: dos codebases nativas, integraciones con sistemas legacy, dependencias exóticas y —el más caro de todos— el código heredado sin documentación de un proveedor que ya no responde.

Correctivo es arreglar lo que se rompe: bugs reportados, crashes detectados por la monitorización, fallos tras una actualización de OS. Preventivo es que no llegue a romperse: actualizar dependencias antes de que bloqueen, adaptar la app a las betas de iOS/Android antes del lanzamiento público, vigilar los avisos de las stores. Evolutivo es mejorar el producto: features nuevas, optimización de conversión, A/B testing — la frontera donde el mantenimiento se convierte en crecimiento de producto.

Un contrato sano cubre los dos primeros siempre y deja el tercero dimensionado según la fase del producto. La trampa habitual de los contratos baratos: solo cubren correctivo, así que cobran aparte cada «imprevisto» — que en móvil no son imprevistos, son el calendario anual de Apple y Google.

Las versiones nuevas de iOS te pillan por sorpresa en lugar de estar probadas antes del lanzamiento público. Los bugs tardan semanas en resolverse sin un SLA que lo limite. Tu app va cada vez más lenta y nadie sabe decirte por qué. El proveedor no te da acceso al repositorio o a las cuentas de las stores — señal de lock-in, no de servicio. O simplemente: hace más de seis meses que tu app no publica una actualización. Cualquiera de estas señales justifica una segunda opinión; varias a la vez justifican cambiar de proveedor.

Todo empieza con una auditoría técnica: no asumimos el mantenimiento de código que no hemos visto. Con el diagnóstico, definimos plan y SLA, montamos (o saneamos) el CI/CD y la monitorización de crashes, y a partir de ahí el ciclo es predecible: actualizaciones de compatibilidad alineadas con el calendario de Apple y Google, dependencias al día, informes mensuales con métricas de estabilidad y una bolsa de evolución dimensionada a tu fase. Equipo 100% senior en Barcelona y Andorra, los mismos ingenieros que construyen los proyectos que ves en nuestro portfolio — el mantenimiento no se subcontrata ni se delega a perfiles junior.

Si tu app necesita un responsable técnico, cuéntanos el caso: auditoría inicial con presupuesto cerrado y diagnóstico honesto, aunque la conclusión sea que no necesitas cambiar nada.