Casos de adoção de IA
O aplicativo iOS do mesmo serviço era o campo principal, onde estava a maioria dos membros. Ainda assim, as notificações estavam ainda mais silenciosas que no Android — a rota de notificação da geração anterior fora completamente cortada. Dando sequência ao Relato ⑥ (a parte Android), desta vez reunimos os pontos de travamento específicos do iOS e, comum aos dois sistemas, como modernizamos as notificações sem tocar no servidor antigo.
É justamente a “falha que ninguém percebe” que vale eliminar primeiro.
A maioria dos usuários estava no iOS. E no iOS as notificações estavam mortas.
Assim como no Android, o aplicativo iOS também era uma casca nativa exibindo um serviço web existente — um invólucro WebView somado a notificações. O envio dependia de um mecanismo da geração anterior e a entrega parou no instante em que essa rota deixou de funcionar. Como a maior parte dos usuários estava aqui, o alcance do impacto era o maior possível. Migrar justamente esta parte para uma plataforma de entrega moderna foi o maior retorno do projeto.
Os travamentos do iOS eram todos daqueles que só aparecem no aparelho real.
No iOS, os problemas eram sobretudo aqueles que nem o dispositivo virtual nem a revisão de código revelam — problemas que só afloram no aparelho real.
A casca foi refeita em Swift; o conteúdo e os membros permaneceram.
O aplicativo iOS foi reconstruído por um agente de IA sobre uma pilha nativa atual (Swift + WKWebView + a plataforma de notificação atual). Percorremos tudo, da geração do esqueleto do projeto até a verificação no aparelho real, confirmando o funcionamento em uma build de dispositivo a partir do Mac. O conteúdo exibido (o serviço web existente) e o ativo de membros representado por cerca de 14.000 dispositivos registrados foram herdados sem alteração.
| Item | Antes | Depois da reconstrução |
|---|---|---|
| Rota das notificações | Esquema de notificação da geração anterior (descontinuada – não envia) | Plataforma de entrega atual + chave de autenticação do novo esquema |
| Casca do aplicativo | Implementação nativa de geração antiga | Regerado com Swift + WKWebView |
| Telas (conteúdo) | Exibem o serviço web existente | Continuam iguais (ativos dos membros preservados) |
| Defeitos no aparelho real | Texto japonês corrompido, entre outros | Fontes, selos e diferenças de geração tratados caso a caso |
O servidor antigo foi modernizado sem ser trocado.
O ponto comum aos dois sistemas era o servidor do lado do envio. Esse servidor roda em um ambiente de execução muito antigo, de modo que as ferramentas oficiais atuais não funcionam nele como estão. Por isso implementamos por conta própria o processamento de assinatura exigido pela autenticação e conectamos à plataforma de entrega atual. Sem trocar o servidor inteiro, migramos apenas as notificações para um esquema moderno.
Além disso, o lado do envio também foi separado da base compartilhada e refeito como um serviço de entrega independente, permitindo escolher os destinatários e enviar pela tela administrativa.
Mesmo um aplicativo móvel dado como “quebrado” pode voltar à operação atual com uma única reconstrução: refaça a casca, herde as chaves e os ativos dos membros e modernize o servidor antigo. Se você tem um aplicativo que já desistiu por considerá-lo intocável, comece conversando conosco sobre analisar o que de fato existe.
* Este artigo generaliza um projeto real na medida em que nem a empresa nem o serviço possam ser identificados. Os números são aproximados, com base em medições de agosto de 2026. Prazo e escopo do trabalho variam conforme a estrutura do aplicativo.