Mobile é manutenção multiplataforma disfarçada de uma linguagem

TL;DR

• Mobile em produção é manutenção simultânea de iOS, Android e backend — bug é sempre falha em um dos três, mas não há console local para abrir.
• Crash reporting, logs estruturados centralizados e beta com usuários reais são pré-requisitos de sobrevivência; sem eles, a manutenção opera às cegas.
• Performance mobile tem teto de hardware: usuário com iPhone 7 e 64 GB não instala app de 200 MB; tamanho e código morto precisam ser governados ativamente.
• Fragmentação de sistema operacional é regra: a base instalada convive com Android 10, 12 e 14 simultaneamente; feature flags e suporte às últimas três versões são obrigatórios.
• Atualização é voluntária: usuário não atualiza o app por anos. Deprecation path, hard requirements e contratos de versão longa são inegociáveis.
• A integração com câmera, localização, contatos e sensores é onde o app se diferencia — e onde a manutenção é mais frágil. Permissões explícitas e degradação elegante são arquitetura, não polimento.

Mobile é manutenção de 3 ambientes ao mesmo tempo

A primeira assunção errada sobre mobile é que existe um único ambiente. Em produção, o app depende de três runtimes que precisam estar coerentes entre si: runtime iOS, runtime Android e runtime backend. Uma falha de autenticação pode estar no token expirado (backend), no `Keychain` corrompido (iOS) ou no `EncryptedSharedPreferences` migrado para um formato que a versão antiga do Android não lê. Identificar em qual dos três está o defeito exige instrumentação nos três.

A prática obrigatória começa com telemetria centralizada. Logs estruturados em JSON — com identificador de sessão, versão do app, modelo do aparelho e nível de bateria — precisam chegar ao servidor enquanto o usuário está usando o app. O log local só serve para desenvolvimento. Sentry, Crashlytics e Firebase Crashlytics fazem parte do stack mínimo. Crash reports automáticos com stack trace agrupado por release reduzem o tempo entre detecção e correção de semanas para horas.

Beta testing com usuários reais é a única forma de capturar defeitos que dependem de condição de rede, versão de SO e modelo de aparelho específico. TestFlight para iOS e Google Play Beta Testing para Android distribuem builds para centenas de perfis de hardware e firmware que emulador nenhum reproduz. A versão beta fica em produção por pelo menos duas semanas antes do release geral. Bugs que aparecem em 0,5% dos dispositivos costumam escapar do QA interno e aparecer nas primeiras 24 horas de beta.

Performance mobile é teto de hardware do usuário

Backend tem escalabilidade horizontal via servidor adicional. Mobile tem teto fixo: o aparelho do usuário. Cada vez que a feature inflou o APK em 10 MB, alguns usuários que hoje estão no limite de armazenamento deixaram de atualizar. Cada segundo a mais de boot fez uma porcentagem dos usuários suspender o ícone. A matemática é simples, mas poucos times acompanham.

A governança de tamanho começa com métrica. App Size Report no Xcode e Android Size Analyzer na Play Console mostram a contribuição de cada módulo para o tamanho total. Code shrinking com `R8` no Android e `strip` no iOS elimina código morto em build de release. Bibliotecas que adicionam 30 MB para resolver problema de 2 MB raramente compensam. Cada dependência nova precisa justificar o custo em megabytes — não em argumentos de produtividade de dev.

Feature flags permitem reverter comportamento sem publicar nova versão. Firebase Remote Config, LaunchDarkly ou configuração custom em JSON remoto controlado por feature toggle desativam feature problemática em produção no momento da detecção. Feature que precisa esperar dois meses pela próxima release é feature que já causou churn. O ciclo de release mobile é lento; a governança dentro do release precisa ser instantânea.

Fragmentação é regra, não exceção

Em backend, controle a versão do Node, do Postgres, do Redis. Sobe a versão, valida em homologação, promove. Em mobile, isso é impossível. A base instalada convive com três a cinco versões principais de cada SO simultaneamente. App publicado em 2026 ainda roda em dispositivos com Android 8, lançado em 2017.

Suportar as últimas três versões maiores de cada plataforma é o piso mínimo. Lançar versão que exige Android 14 quando 25% da base ainda está em Android 11 é decisão de negócio, não só técnica — e precisa estar documentada. Feature flag por versão de SO permite degradar funcionalidade sem bloquear o app inteiro. Câmera com processamento pesado em Android 8 pode cair para JPEG simples se a abstração estiver desde o design.

Testes em múltiplas versões exigem matriz. Firebase Test Lab e BrowserStack App Live rodam a suíte emulando dezenas de combinações de aparelho e SO. Testes em emulador local não substituem testes em device farm, mas cobrem regressão de fluxo em CI. Combinar os dois é o padrão. A versão de SO mínima declarada na Play Store e App Store é contrato com usuário: subir a versão mínima quebra a confiança acumulada no app.

Atualização é voluntária e o bug não conserta sozinho

Em SaaS, corrigiu no backend, todo usuário recebe o fix. Em mobile, o usuário precisa abrir a loja de apps, baixar a atualização e reabrir o app. Estatísticas de update variam por categoria, mas taxa de adoção de 50% nos primeiros 30 dias é otimista. App bugado fica bugado por anos.

Deprecation path é a resposta canônica. Avisar na release notes que a versão será descontinuada em data definida, mostrar banner dentro do app para versões antigas, bloquear funcionalidade crítica após o prazo. Caminho de deprecamento em três fases: aviso suave em update da versão atual, aviso duro forçado na abertura, bloqueio total via backend que recusa token de versão descontinuada. O bloqueio via backend é a única defesa contra versão zombie que ninguém conseguiu atualizar.

Hard requirements de versão mínima existem por motivo. App que exige Android 10+ por causa de API de segurança nova não é capricho — é resposta a CVE que afeta Android 8 e 9. Mas a migração precisa ser gradual: durante 6 a 12 meses, app roda em versão antiga e nova simultaneamente, com feature degradation coerente. Após o prazo de deprecamento, enduro o bloqueio. Suportar versão legada para sempre não é compatibilidade — é manutenção de terceiro app que ninguém atualiza.

Integração com dispositivo é onde o app se diferencia

Mobile é a única plataforma com acesso profundo a sensor de câmera, GPS, giroscópio, microfone, contatos, calendário, Bluetooth, NFC. É o que torna o app diferente de um site responsivo. É também onde a manutenção é mais frágil: permissão revogada, sensor descalibrado, atualização de firmware que muda formato de saída, versão de SO que deprecia API.

Testes de integração com features do dispositivo precisam de device farm, não emulador. Pipeline de QA roda build em iPhone físico com iOS atual e iOS dois releases atrás, em Galaxy com Android atual e em Pixel com Android mínimo suportado. Cada feature de sensor tem teste que liga o app com sensor real e valida output em pelo menos três modelos distintos. Emulador mascara problemas de timing e codec que só aparecem em hardware real.

Graceful degradation é arquitetura. Se a câmera falhar ao abrir, o app continua funcionando — formulário manual substitui o fluxo de captura, mensagem clara informa que foto não foi tirada. Se a permissão de localização for revogada, app usa último local conhecido em vez de quebrar. Permissões explícitas e mínimas — pedir só o que aquela feature precisa, naquele momento, com justificativa textual clara — reduzem taxa de rejeição e aumentam taxa de instalação. Pedir “todas as permissões” no primeiro launch é padrão de app abandonado.

O framework dos Três Ambientes Mobile, aplicado de forma disciplinada, separa app que cresce de app que vira chá de cadeira na próxima sprint. Crash reports centralizados, feature flags por versão de SO, deprecation path documentado e graceful degradation nas integrações de hardware não são polish de release — são a diferença entre app em produção e app em manutenção eterna.

Leitura relacionada

• Manutenção de código web: browser é caixa preta — a outra face da manutenção sem console: web tem DOM inspectável mas estado invisível, mesmo problema sob outro disfarce.
• Manutenção de código Windows é estar preso ao passado enquanto mundo avança — desktop preso em stack legada completa a trilogia: web com browser opaco, Windows com runtime congelado, mobile com três ambientes sob uma única base de código.
• O código novo que ninguém consegue manter é pior que o legado — o destino do app mobile que este post alerta é virar código que ninguém quer manter; a regra geral de sustentabilidade de manutenção fecha o ciclo.