¿Seguirá funcionando tu app dentro de tres años?

El día del lanzamiento todo va bien: has visto tu app funcionar. Está en las tiendas, los primeros usuarios la descargan, todo responde. La pregunta que de verdad importa no aparece ese día.

Aparece mucho más tarde, la mañana en que alguien te escribe para avisarte de que algo ha dejado de funcionar. Entre medias han pasado tres años en los que no has tocado nada.

Tu app no ha cambiado ni una coma. El mundo a su alrededor, sí. Ahí está la paradoja: una app puede dejar de funcionar sin que se mueva una sola línea dentro de ella.

Cuatro movimientos, básicamente. Las tiendas endurecen sus reglas: declaraciones de privacidad, versiones mínimas, políticas de permisos. Los sistemas operativos abandonan funciones por el camino y convierten otras en obligatorias. Algunas cosas tienen fecha de caducidad: los certificados y algunas credenciales de servicio expiran — el certificado SSL de un dominio, por ejemplo. Y los datos se acumulan, hasta que lo que era instantáneo se vuelve pesado.

Pierre-Laurent ha hecho el inventario detallado de lo que se degrada en silencio, con las políticas de las tiendas y los plazos incluidos. No lo voy a repetir aquí. Lo que me interesa en este artículo es la pregunta siguiente: una vez que sabes todo eso, ¿quién se ocupa?

Decir que una plataforma «se ocupa del mantenimiento» es tan vago que acaba siendo hueco. El mecanismo real cabe en una frase: el problema se corrige una vez, a nivel de plataforma, y cada app hereda la corrección en su siguiente compilación.

Cuando entra en vigor un nuevo requisito de privacidad, no son miles de creadores de apps leyendo la documentación de Apple cada uno por su lado. Es un equipo, una vez, actualizando el motor que construye las apps. Cuando un sistema abandona una función, el componente que la usaba se reescribe una vez, en ese mismo sitio. Tú no has leído nada, no has migrado nada, no has decidido nada.

Vale la pena enunciar la alternativa, porque es todo el argumento de construir sobre una plataforma en lugar de mantener tu propio código. Si eres tú quien tiene que mantener el código fuente de la app —escrito por un desarrollador que has contratado, o generado a partir de un prompt en una tarde—, esa misma frase describe tu tarde. Te toca a ti darte cuenta de que la regla ha cambiado, entender qué exige, modificar el código, recompilar, volver a enviar. Nadie lo ha hecho una vez para todos: se hace una vez para ti, y otra vez para el cambio siguiente, y para el de después. Producir una app se ha vuelto notablemente barato, y esa es una buena noticia de verdad. Mantenerla al día no se ha movido ni un milímetro. Pierre-Laurent ha analizado esa distancia en detalle.

Un punto de honestidad, porque cuenta: esta vigilancia solo atrapa lo que alguien vio venir. Leer las reglas antes de que se apliquen, reescribir un componente antes de que un abandono se convierta en una avería, es un oficio ejercido de forma continua, no una garantía automática.

Todo lo anterior vale para una app viva, que se vuelve a publicar de vez en cuando. Pero la preocupación real está en otra parte, y nadie la formula: dejé mi app aparcada dos años. ¿Está perdida?

No. Y la razón está en cómo se acumula el trabajo: las correcciones esperan a tu app, no van detrás de ella. Una app que nadie toca no se repara sola por la noche; nada le llega mientras duerme. Pero durante esos dos años, cada cambio de regla y cada función abandonada por iOS o Android se trató una vez, aguas arriba, para todas las apps de la plataforma. Ese trabajo no se ha evaporado porque la tuya estuviera en silencio. Está ahí, apilado, esperándola.

La consecuencia es muy concreta: cuando vuelves, no recuperas dos años a mano. Recompilas, y tu app sale con los estándares del mundo de hoy, no con los del mundo en el que nació. Ponerse al día no es un proyecto: es una compilación. No tienes que saber qué había dentro.

Esto es exactamente lo que no ocurre cuando eres tú quien mantiene el código fuente. Nada se acumuló en tu lugar mientras dormía. Dos años de cambios siguen siendo dos años de cambios, esperando a que alguien —tú, o alguien a quien pagues— los vaya resolviendo uno a uno antes de que la app pueda volver a salir.

Esta es la verdadera respuesta a la pregunta del título, y cabe en dos columnas.

De nuestro lado: el motor que construye las apps, mantenido al día de forma permanente. La lectura de las reglas de las tiendas antes de que se apliquen. La reescritura de los componentes antes de que un abandono se convierta en una avería. La cadena que envía tus notificaciones. El certificado SSL de tu dominio, renovado antes de cada vencimiento. Nada de eso te pide una decisión, ni siquiera estar al tanto.

De tu lado, y nadie puede hacerlo por ti:

• Tus cuentas de desarrollador de Apple y Google. Están a tu nombre —eso es lo que hace que la app sea tuya— y hay que renovarlas. Una cuenta caducada retira la app de las tiendas, por buena que sea lo que hay dentro.
• Las declaraciones que describen tu contenido y tus prácticas de datos. Hablan de tu actividad, no de la nuestra: podemos prepararlas a partir de las funciones que has activado realmente, pero no decidir en tu lugar qué haces con los datos de tus usuarios.
• El gesto de enviar la actualización. Toda versión nueva pasa por la revisión de las tiendas: la plataforma lo prepara todo, tú aprietas el botón. Si eso último te pesa, GoodBarber Takes Care es la opción en la que enviamos las actualizaciones a las tiendas en tu lugar.

La lista es corta. Es a propósito, y cada una de esas líneas merece su propio artículo: es lo que hará esta serie.

El beneficio real no es técnico: es tiempo. Las horas que no dedicas a leer las notas de versión de Apple, a descifrar qué es una declaración de privacidad o a buscar por qué ha caducado un certificado, las dedicas a tu contenido, a tu audiencia, a tu negocio.

Es un beneficio difícil de anunciar, porque no se ve: cuando funciona, no pasa nada. Ninguna demo puede demostrarlo; solo el tiempo lo verifica. Es lo que la plataforma hace, discretamente, desde 2011.

Si te interesa el detalle técnico, he descrito en otro sitio, desde el lado de la ingeniería, qué se rompe de verdad en tres años.

La forma más sencilla de ver cómo es una app construida sobre esta mecánica es empezar la tuya: crear mi app con GoodBarber.

¿Seguirá funcionando mi app dentro de tres años?

Una app que se deja estrictamente intacta acaba quedándose atrás respecto a su entorno, y eso pasa en todas partes. La diferencia está en lo que cuesta ponerse al día: en una plataforma que absorbe los cambios, las correcciones ya están hechas y esperan a tu app. Actualizarla es una recompilación, no un proyecto.

Dejé mi app aparcada dos años. ¿Está perdida?

No. Nada le llega a una app mientras duerme, pero todo el trabajo hecho entretanto a nivel de plataforma la está esperando: en la siguiente recompilación sale con los estándares actuales. Ahí está la diferencia con una app cuyo código fuente tienes que mantener tú, donde nada se acumuló en tu lugar.

¿Quién es responsable de qué entre la plataforma y yo?

La plataforma asume lo que es común a todas las apps: el motor que las construye, el cumplimiento de las reglas de las tiendas, la sustitución de los componentes abandonados y la infraestructura de notificaciones. Tú conservas tus cuentas de desarrollador de Apple y Google, las declaraciones que describen tu contenido y la decisión de publicar las actualizaciones.

¿Hacen falta conocimientos técnicos para mantener una app a lo largo del tiempo?

No, y ese es justamente el punto: la parte que los exige se hace una vez, aguas arriba, para todas las apps. Lo que queda de tu lado es administrativo y editorial —renovar cuentas, describir tu contenido, elegir cuándo publicar—, no código.

¿Por qué mi app va más lenta que cuando la lancé?

La mayoría de las veces no se ha roto nada: ha cambiado el volumen. Lo que era instantáneo con un catálogo pequeño exige más trabajo cuando lleva años creciendo. Es el único de los cuatro movimientos que viene de tu propio éxito y no de fuera, y será el tema de un próximo artículo de esta serie.