O que fazer quando herda um aplicativo direcionado ao iOS 15

O que fazer quando herda um aplicativo direcionado ao iOS 15

Quando você entra em uma equipe e descobre que o aplicativo ainda suporta o iOS 15, não mude imediatamente o alvo de implantação e abra um pull request.

Faça uma auditoria primeiro.

Você precisa entender por que o alvo atual existe, o que depende dele e o que moveria a mudança.

Passo 1: Encontre a decisão original

Procure por:

• Registros de Decisão Arquitetônica
• Requisitos do produto
• Chamados de migração anteriores
• Documentação de lançamento
• Acordos empresariais
• Políticas de suporte
• Discussões no Slack ou por e-mail
• Comentários na configuração do projeto

Peça à equipe:

• Quando o alvo de implantação foi revisado pela última vez?
• Quem tomou a decisão?
• Qual informação foi usada?
• Era vinculado a um cliente específico?
• Essa exigência ainda está ativa?

Frequentemente, ninguém sabe.

Essa resposta em si é útil. Significa que o alvo de implantação provavelmente é uma suposição herdada, e não uma estratégia ativa.

Passo 2: Puxe dados de uso específicos do aplicativo

Não confie apenas na adoção global da Apple.

Construa uma tabela para seu próprio produto:

The exact categories will differ, but the goal is to connect technical support to business impact.

A equipe não pode tomar uma boa decisão com base em apenas um percentual de adoção.

Por exemplo:

• 1% dos usuários gerando 15% da receita pode justificar o suporte.
• 5% de usuários inativos gerando quase nenhuma receita pode não justificar.
• 0,5% vinculado a um contrato empresarial assinado pode superar ambos.

Passo 3: Medir o custo da engenharia

Muitas equipes sabem quantos usuários precisam de uma versão antiga, mas nunca mediram o que custa suportá-la.

Revise a base de código por:

if #available(iOS 18.0, *) {
    // Caminho moderno
} else {
    // Caminho legado
}

Também procure por:

@available(iOS 18.0, *)

E verifique:

• Versões condicionais de pacotes
• Extensões de compatibilidade
• Abstrações personalizadas de navegação
• Mecanismos legados de observação
• Contornos para concorrência antigos
• APIs depreciadas
• Fallbacks de IU
• Variantes de teste de snapshot
• Correções específicas de versão
• Trabalhos CI para simuladores mais antigos
• Casos de teste manual QA
• Dependências bloqueadas pelo alvo de implantação

Então, transforme esse trabalho em custos mensuráveis.

Por exemplo:

Trabalhos de simulação legados: 18 minutos por pull request
Pull requests médios por mês: 220
Uso mensal do CI legado: 66 horas

Regressão manual para velho OS: 6 horas QA por lançamento
Lançamentos por ano: 24
Custo anual de QA manual: 144 horas

O objetivo não é fabricar um número dramático.

O objetivo é tornar o custo oculto visível.

Passo 4: Identifique o que melhora quando a meta se move

Elevar a meta de implantação não deve ser enquadrado como modernização por si só.

Conecte-o a resultados concretos.

Benefícios potenciais incluem:

• Removendo ramificações de compatibilidade
• Simplificando a arquitetura
• Adotando APIs de navegação modernas
• Reduzindo combinações de testes
• Diminuindo o tempo do CI
• Atualizando dependências
• Eliminando APIs obsoletas
• Reduzindo a investigação de crashes e bugs
• Melhorando o comportamento de acessibilidade
• Aumentando a produtividade do desenvolvedor
• Entregando recursos mais rápido

Ao invés de dizer:

Devemos abandonar o iOS 15 porque é antigo.

Diga:

Abandonar o iOS 15 remove duas camadas de compatibilidade, elimina quatro trabalhos legados do CI, permite que atualizemos três dependências bloqueadas e reduza a matriz de regressão da release em 25%. A população afetada é 0,6% dos usuários ativos e não representa contas contratuais.

Isso é um argumento de liderança.

Passo 5: Verifique restrições contratuais e do produto

Antes de propor a migração, pergunte:

• Um contrato de cliente está vinculado ao iOS 15?
• A equipe de vendas promete atualmente suporte para isso?
• Há frotas gerenciadas de dispositivos ainda usando isso?
• A versão mínima está documentada publicamente?
• Há compromissos regulatórios?
• Deixar de dar suporte impediria usuários críticos de receber atualizações de segurança?
• O produto precisa de um período de transição?

A mudança do alvo de implantação não é apenas uma decisão técnica.

Ela pode afetar o sucesso do cliente, obrigações legais, compromissos de vendas, materiais de marketing, documentação de suporte e comunicações de lançamento.

A equipe de engenharia deve liderar a análise, mas não deve tomar a decisão empresarial sozinha.

Um quadro prático de decisões

Um simples sistema de pontuação pode ajudar a tornar a discussão mais objetiva.

Avalie a versão candidata em cinco dimensões:

1. Impacto do usuário

Quantos usuários ativos perderiam acesso a futuras versões?

2. Impacto financeiro

Quanto de receita recorrente ou estratégica está associada a esses usuários?

3. Impacto contratual

Há compromissos exigindo suporte contínuo?

4. Custo de engenharia

Quanto de complexidade, tempo de CI, esforço de QA e dívida técnica o suporte cria?

5. Oportunidade do produto

Quais recursos, atualizações de dependências, melhorias de desempenho ou simplificações arquiteturais se tornam possíveis após a mudança?

O decisão final deve equilibrar todas as cinco.

Uma pequena porcentagem de usuários não significa automaticamente “desista disso.”

Uma versão antiga não significa automaticamente “mantenha isso.”