"No-code" parece fácil. Configure seu aplicativo em um navegador, clique em publicar e pronto. E é exatamente como deve ser para um único aplicativo, visto de fora. Manter milhares de aplicativos no código sem escala funcionando e publicados por anos é outro trabalho completamente diferente. Este post abre o quarto da máquina: hospedagem, entrega push, submissões à loja e a esteira rolante que está em operação.
Contexto rápido: GoodBarber é um construtor de aplicativos no código sem escala desde 2011. Os clientes configuram um aplicativo em uma web back office; a plataforma compila builds nativos (Swift para iOS, Kotlin para Android) mais uma PWA e opera tudo que esses aplicativos precisam em tempo real. Essa última cláusula é o assunto aqui.
O que "em escala" significa para um aplicativo publicado
O problema de demonstração e o problema de produção são problemas diferentes. Qualquer pilha pode produzir um aplicativo que funciona hoje. Um aplicativo publicado é um compromisso mais longo: um binário sentando em duas lojas atrás de dois processos de revisão, uma parte traseira que chama todos os dias, credenciais push que expiram, uma versão do sistema operacional a cada ano e políticas da loja que se movem sob seus pés.
Escala, no nosso caso, em meados de 2026:
- milhares de aplicativos ativos em produção;
- um download a cada quatro segundos na frota, cerca de 20.000 por dia e 8 milhões ao ano (medido sobre 29 dias em abril de 2026);
- clientes pagantes em 152 países;
- uma plataforma em funcionamento desde 2011, então "longo prazo" é medido em gerações do sistema operacional, não em sprints.
A definição operacional de escala é multiplicação. Com um aplicativo, uma mudança na política da loja custa-lhe uma tarde. Com milhares, toda mudança externa se torna um evento de frota: o que Apple ou Google decidir neste trimestre deve ser multiplicado por cada aplicativo em produção. A arquitetura inteira abaixo existe para fazer essa multiplicação suportável.
A infraestrutura que ninguém vê
Hospedagem. GoodBarber é seu próprio provedor de hospedagem. Alugamos espaço em racks em grandes data centers europeus e executamos nossos próprios computadores lá: vários racks de hardware, não uma locação em um hiperscaler alguém. O backend é multi-inquilino: milhares de aplicativos compartilham os serviços da plataforma, cada um com seu próprio conteúdo, configuração e superfície API, e o CDN na frente dele move vários terabytes por dia. Executar o hardware nós mesmos mantém a questão dos dados curta (uma empresa, uma jurisdição, servidores na Europa) e coloca o planejamento de capacidade onde pertence: conosco, uma vez, em vez de milhares de proprietários individuais de aplicativos.
Push, em volume. A plataforma entrega vários milhões de notificações push por semana. A visão do proprietário do aplicativo dessa sentença: escreva a mensagem, escolha o público-alvo, envie agora ou agende. Tudo o resto é nosso:
- fan-out para APNs e FCM, com credenciais de aplicativo provisionadas e rotacionadas;
- higiene do token do dispositivo: tokens morrem constantemente (desinstalações, restaurações de dispositivo, reinstalações do sistema operacional), então as respostas de entrega têm que ser consumidas e tokens mortos removidos ou taxas de entrega silenciosamente deterioram;
- limites de carga, limitação, retentativas e a fila de agendamento que transforma milhares de campanhas "enviar às 9h" em explosões sincronizadas de entregas individuais.
A entrega confiável é um problema de higiene de dados tanto quanto um problema de capacidade. A capacidade é intermitente e previsível; a deterioração do token nunca para.
Submissões à loja, tratadas por pessoas que fazem isso o dia inteiro. Uma equipe dedicada publica e mantém aplicativos na App Store e Google Play. A linha de base contra a qual essa equipe trabalha: Apple rejeita aproximadamente 42% das primeiras submissões (medido nas submissões que nossa equipe lidou nos últimos 12 meses; isso é a linha de base da Apple, não nossa taxa de falhas). A equipe recupera 91% dessas rejeições de primeira submissão. Em atualizações, trabalho preventivo upstream torna as rejeições raras no primeiro lugar. A revisão do aplicativo não é uma chamada da API que retorna 200; é uma negociação com diretrizes que mudam e vai significativamente melhor quando é alguém emprego integral.
A esteira rolante: o que uma plataforma absorve
Um aplicativo deixado sozinho degrada. Não porque seu código muda, mas porque tudo ao seu redor se move. Um exemplo do que "ao redor" significa, com datas:
- A cada ano: O Google Play eleva o nível API obrigatório. Se você perder a data limite, não poderá enviar atualizações; cair mais para trás e o aplicativo será escondido de novos usuários.
- De abril a dezembro de 2020: A Apple parou de aceitar novos apps, então atualizações, ainda usando UIWebView. Todo app incorporando conteúdo web teve que se mover para WKWebView.
- March 2021: APNs abandonou seu protocolo binário legado. Os emissores de push tiveram que migrar para a API baseada em HTTP/2 ou parar de entregar.
- Julho de 2022: O formulário de segurança dos dados do Google Play se tornou obrigatório para cada listagem.
- Maio de 2024: A Apple começou a exigir manifestos de privacidade e declarações de "motivo necessário" da API, incluindo para SDKs de terceiros.
Agora adicione o ritmo anual por cima: novas versões iOS e Android todos os outonos, cadeias de ferramentas Xcode e Gradle que se movem, SDKs que depreciam.
Em uma plataforma, cada um desses é absorvido exatamente uma vez. A correção pousa no código base compartilhado, os apps são recompilados e a frota avança através de atualizações regulares do aplicativo. Isso também é por que recomendamos aos proprietários que atualizem regularmente mesmo quando nada visível mudou: a atualização é o veículo que carrega essas correções para produção, e as lojas em si são hostis a apps adormecidos (A Apple varre periodicamente aplicativos que não foram atualizados há anos; O Google enterra apps direcionados a níveis API obsoletos). Um app que envia atualizações permanece atualizado, visível e instalável. A maioria dos nossos proprietários experimentou os eventos acima como uma nota de lançamento, se notaram algo.
O itemizado da fatura
Remova a plataforma e aqui está o que um aplicativo de produção faz você assumir permanentemente:
- uma elevação do nível API alvo por ano, então pelo menos uma recompilação e resubmissão por ano;
- temporada beta do SO: teste todo verão, corrija antes de cada outono;
- sua dependências' CVEs, depreciations e mudanças de licença;
- infraestrutura push: credenciais, higiene de token, monitoramento de entrega;
- vigilância da política da loja: novos formulários, novos manifestos, novas diretrizes de revisão;
- monitoramento e alguém alcançável quando quebra.
Nenhum desses é difícil isoladamente. Todos eles são permanentes, e se acumulam. O que um plataforma no-code realmente vende não é o editor; é a amortização. Uma equipe absorve essa lista uma vez, e milhares de apps herdam o resultado com sua próxima atualização.
Nossos próprios recibos são públicos: um engenheiro está em chamada durante todo o ano, e a página de status da plataforma está em goodbarberstatus.com.
Perguntas nos comentários. Estou feliz em ir um nível mais profundo sobre qualquer um desses, desde escolhas de colocalização até o pipeline push a histórias de revisão.