Seu app ainda vai funcionar daqui a três anos?

No dia do lançamento está tudo bem: você viu seu app funcionar. Ele está nas lojas, os primeiros usuários baixam, tudo responde. A pergunta que realmente importa não aparece nesse dia.

Ela aparece muito depois, na manhã em que alguém escreve para avisar que algo parou de funcionar. Entre os dois momentos passaram-se três anos em que você não tocou em nada.

Seu app não mudou uma vírgula. O mundo ao redor dele, sim. É aí que está o paradoxo: um app pode parar de funcionar sem que uma única linha se mexa lá dentro.

Quatro movimentos, essencialmente. As lojas endurecem suas regras: declarações de privacidade, versões mínimas, políticas de permissões. Os sistemas operacionais abandonam funções pelo caminho e tornam outras obrigatórias. Algumas coisas têm prazo de validade: certificados e algumas credenciais de serviço expiram — o certificado SSL de um domínio, por exemplo. E os dados se acumulam, até que o que era instantâneo fica pesado.

Pierre-Laurent fez o inventário detalhado do que se degrada em silêncio, com as políticas das lojas e os prazos. Não vou refazer isso aqui. O que me interessa neste artigo é a pergunta seguinte: uma vez que se sabe tudo isso, quem cuida disso?

Dizer que uma plataforma «cuida da manutenção» é vago a ponto de ficar vazio. O mecanismo real cabe em uma frase: o problema é corrigido uma vez, no nível da plataforma, e cada app herda a correção na sua build seguinte.

Quando entra em vigor uma nova exigência de privacidade, não são milhares de criadores de apps lendo a documentação da Apple cada um por conta própria. É uma equipe, uma vez, atualizando o motor que constrói os apps. Quando um sistema abandona uma função, o componente que a usava é reescrito uma vez, no mesmo lugar. Você não leu nada, não migrou nada, não decidiu nada.

Vale a pena enunciar a alternativa, porque é todo o argumento de construir sobre uma plataforma em vez de manter o próprio código. Se é você quem tem de manter o código-fonte do app — escrito por um desenvolvedor que você contratou, ou gerado a partir de um prompt em uma tarde —, essa mesma frase descreve a sua tarde. Cabe a você perceber que a regra mudou, entender o que ela exige, alterar o código, recompilar, reenviar. Ninguém fez isso uma vez para todos: é feito uma vez para você, e de novo para a mudança seguinte, e para a seguinte. Produzir um app ficou notavelmente barato, e isso é uma boa notícia de verdade. Mantê-lo em dia não andou um milímetro. Pierre-Laurent detalhou essa distância.

Um ponto de honestidade, porque ele conta: essa vigilância só pega o que alguém viu chegando. Ler as regras antes que se apliquem, reescrever um componente antes que um abandono vire uma pane, é um ofício exercido continuamente, não uma garantia automática.

Tudo o que vem antes vale para um app vivo, republicado de tempos em tempos. Mas a preocupação real está em outro lugar, e ninguém a formula: deixei meu app de lado por dois anos. Ele está perdido?

Não. E a razão está na forma como o trabalho se acumula: as correções esperam pelo seu app, elas não correm atrás dele. Um app em que ninguém toca não se conserta sozinho durante a noite: enquanto dorme, nada chega até ele. Mas nesses dois anos cada mudança de regra e cada função abandonada pelo iOS ou pelo Android foi tratada uma vez, na origem, para todos os apps da plataforma. Esse trabalho não evaporou porque o seu estava em silêncio. Ele está ali, empilhado, esperando.

A consequência é bem concreta: quando você volta, não recupera dois anos na mão. Você recompila, e seu app sai com os padrões do mundo de hoje, não com os do mundo em que nasceu. Ficar em dia não é um projeto: é uma build. Você não precisa saber o que havia dentro.

É exatamente o que não acontece quando é você quem mantém o código-fonte. Nada se acumulou no seu lugar enquanto ele dormia. Dois anos de mudanças continuam sendo dois anos de mudanças, esperando que alguém — você, ou alguém que você pague — resolva uma a uma antes que o app possa voltar ao ar.

Esta é a verdadeira resposta à pergunta do título, e ela cabe em duas colunas.

Do nosso lado: o motor que constrói os apps, mantido em dia permanentemente. A leitura das regras das lojas antes que elas se apliquem. A reescrita dos componentes antes que um abandono vire uma pane. A cadeia que envia suas notificações. O certificado SSL do seu domínio, renovado antes de cada vencimento. Nada disso pede uma decisão sua, nem sequer que você fique sabendo.

Do seu lado, e ninguém pode fazer no seu lugar:

• Suas contas de desenvolvedor Apple e Google. Elas estão no seu nome — é isso que faz o app ser seu — e precisam ser renovadas. Uma conta expirada tira o app das lojas, por melhor que seja o que há dentro.
• As declarações que descrevem seu conteúdo e suas práticas de dados. Elas falam do seu negócio, não do nosso: podemos prepará-las a partir das funções que você realmente ativou, mas não decidir no seu lugar o que você faz com os dados dos seus usuários.
• O gesto de enviar a atualização. Toda versão nova passa pela revisão das lojas: a plataforma prepara tudo, você aperta o botão. Se for esse último ponto que pesa, o GoodBarber Takes Care é a opção em que enviamos as atualizações às lojas no seu lugar.

A lista é curta. É de propósito, e cada uma dessas linhas merece um artigo próprio: é o que esta série vai fazer.

O benefício real não é técnico: é tempo. As horas que você não passa lendo as notas de versão da Apple, decifrando o que é uma declaração de privacidade ou procurando por que um certificado expirou, você passa no seu conteúdo, no seu público, no seu negócio.

É um benefício difícil de anunciar, porque não aparece: quando funciona, nada acontece. Nenhuma demonstração prova isso; só o tempo verifica. É o que a plataforma faz, discretamente, desde 2011.

Se o detalhe técnico interessa, descrevi em outro lugar, do lado da engenharia, o que realmente quebra em três anos.

O jeito mais simples de ver como é um app construído sobre essa mecânica é começar o seu: criar meu app com a GoodBarber.

Meu app ainda vai funcionar daqui a três anos?

Um app deixado rigorosamente intacto acaba ficando para trás em relação ao seu ambiente, e isso vale em qualquer lugar. A diferença está no custo de ficar em dia: em uma plataforma que absorve as mudanças, as correções já foram feitas e esperam pelo seu app. Colocá-lo em dia é uma recompilação, não um projeto.

Deixei meu app de lado por dois anos. Ele está perdido?

Não. Nada chega a um app enquanto ele dorme, mas todo o trabalho feito nesse meio-tempo no nível da plataforma está esperando por ele: na recompilação seguinte, ele sai com os padrões atuais. É toda a diferença em relação a um app cujo código-fonte você tem de manter, onde nada se acumulou no seu lugar.

Quem é responsável pelo quê entre a plataforma e eu?

A plataforma assume o que é comum a todos os apps: o motor que os constrói, a conformidade com as regras das lojas, a substituição dos componentes abandonados e a infraestrutura das notificações. Você mantém suas contas de desenvolvedor Apple e Google, as declarações que descrevem seu conteúdo e a decisão de publicar as atualizações.

É preciso ter conhecimento técnico para manter um app ao longo do tempo?

Não, e é justamente esse o ponto: a parte que exige conhecimento é feita uma vez, na origem, para todos os apps. O que resta do seu lado é administrativo e editorial — renovar contas, descrever seu conteúdo, escolher quando publicar —, não código.

Por que meu app está mais lento do que no lançamento?

Na maioria das vezes nada quebrou: o volume mudou. O que era instantâneo com um catálogo pequeno exige mais trabalho depois de anos crescendo. É o único dos quatro movimentos que vem do seu próprio sucesso, e não de fora, e será o tema de um próximo artigo desta série.