Prisioneiros do Google no desenvolvimento para Android

• Um pequeno trabalho de manutenção para elevar o targetSdkVersion de um app Android legado, em conformidade com as exigências do Google, acabou se transformando em um crash em produção no Android 13 e em uma longa espera pela revisão do Google Play
• Para que o app existente continuasse disponível a usuários de dispositivos com versões mais novas do Android, ele precisava mirar o API level 31 ou superior; o autor então atualizou do API level 30 para o 33 e fez o deploy
• A primeira release foi aprovada em menos de 1 hora, mas o app passou a crashar logo após o login em dispositivos reais com Android 13, e não havia como fazer rollback para a versão anterior estável
• A build corrigida foi enviada logo após a alteração no código, mas ficou em revisão por cerca de 72 horas; depois, só foi publicada em produção em 4 de setembro, 11 dias depois
• Mesmo operando diretamente o código-fonte e a infraestrutura, apps mobile nativos ainda têm seu canal final de entrega controlado pelos operadores das lojas de aplicativos, o que limita correções urgentes, rollback e velocidade de distribuição

---

Uma pequena atualização de SDK virou incidente em produção

• O trabalho de manutenção era em um aplicativo Android legado usado por um cliente
  • A funcionalidade já estava concluída havia anos, e não era um app em desenvolvimento ativo
  • No cenário ideal, a versão estável teria sido deixada como estava
• Em 18 de agosto de 2023, o Google enviou um e-mail informando os requisitos de nível de API do Android
• O ponto central da orientação do Google era que, para que um app existente continuasse disponível a usuários de dispositivos com versões mais novas do Android, ele precisava mirar o API level 31 ou superior
• O impacto exato sobre apps já instalados não estava claro, e a atualização foi priorizada com base na interpretação mais conservadora
• Faltavam menos de 3 semanas para o prazo final, e o Google não havia enviado lembretes mais cedo sobre essa exigência

Mudança de targetSdkVersion 30 para 33

• O trabalho começou em 23 de agosto, elevando o targetSdkVersion do app do API level 30 para 33
• A primeira build falhou por causa de uma dependência de analytics incompatível
  • Como essa dependência não estava fortemente ligada à lógica de negócio, ela pôde ser removida
• Depois disso, o app foi executado em um emulador Android, e os principais recursos pareceram funcionar como antes
• Essa mudança era uma atualização para atender política, sem entregar novo valor de negócio

Primeiro deploy no Google Play e crash no Android 13

• O processo de publicação no Google Play inicialmente correu bem
  • Como o app legado era atualizado só uma ou duas vezes por ano, foi necessário preencher vários questionários
  • A release passou pela revisão em menos de 1 hora e foi para produção
• Naquela noite, por volta das 21:30, o problema apareceu quando o cliente relatou usuários que não conseguiam fazer login na nova versão do app
• Ao testar em um dispositivo Android real, o aplicativo passou a crashar logo após o login
• Uma investigação adicional mostrou que o problema ocorria no Android 13, a versão mais recente naquele momento, enquanto as versões anteriores funcionavam normalmente
• No trabalho inicial, só haviam sido testadas imagens antigas de emulador, então o problema de compatibilidade não apareceu
• Se várias versões do Android tivessem sido testadas, o problema poderia ter sido detectado
  • O escopo pequeno da mudança e a pressão do prazo geraram confiança excessiva, mas a cobertura insuficiente de testes foi um erro da equipe

Uma estrutura de deploy que bloqueia rollback

• A resposta inicial mais segura teria sido restaurar a release anterior estável e investigar o crash no próximo horário comercial, mas no Google Play essa opção não existia
• Não havia como retirar a release de produção mais recente e reativar a versão anterior
• Como alternativa, tentou-se voltar o targetSdkVersion para 30, aumentar a versão do app e publicar uma nova build, mas o Google Play rejeitou
  • A orientação publicada parecia permitir um alvo mais baixo até 1º de setembro, mas surgiu um erro dizendo que novas atualizações precisavam mirar o API level 33
• Foi solicitado um adiamento que permitiria API level 30 até 1º de novembro, mas o erro de publicação continuou o mesmo
• O único caminho possível era corrigir o crash no Android 13 e enviar uma nova release

Correção sob pressão e longa espera na revisão

• A versão com problema estava sendo entregue gradualmente aos usuários por atualização automática, e quanto mais rápido a build corrigida chegasse à produção, menor seria o número de clientes afetados
• O crash podia ser reproduzido no emulador do Android 13, e a alteração de código necessária não era grande
• Ainda assim, o trabalho precisou ser feito tarde da noite e sob pressão, com tempo limitado para testes de regressão abrangentes
• Naquele momento, o plano era mais próximo de uma resposta pragmática
  • corrigir todos os crashes conhecidos
  • testar os fluxos mais importantes
  • enviar imediatamente a versão corrigida
  • continuar testando de forma mais ampla e preparar outra atualização, se necessário
• A nova build foi enviada ao Google Play, mas mesmo após 2 horas continuava aguardando revisão, e por volta de 01:00 ainda não havia sido aprovada
• Na manhã seguinte, o app continuava com status in review
• Boa parte do dia foi usada em testes no Android 13 e na checagem do Google Play Console, e alguns pequenos problemas foram encontrados e corrigidos, embora fossem menos graves que o crash no login
• Mesmo no fim daquele dia, a correção para produção ainda não havia sido aprovada
• Naquele momento, a build corrigida já estava aguardando havia cerca de 72 horas; o código estava consertado, mas a distribuição seguia presa em uma fila de revisão opaca

Atualizações posteriores: revisão, chat de suporte e rollout gradual

• Em 27 de agosto, o autor publicou o texto no Hacker News, e a discussão trouxe tanto estratégias de release para Android quanto críticas
  • O texto chegou à página principal e recebeu cerca de 130 mil visitantes únicos ao longo de alguns dias
  • O site estático, hospedado em um VPS de cerca de €5 por mês, suportou o tráfego
  • Essa atenção não levou a uma resposta do Google, e a atualização do app continuou em revisão
• Em 1º de setembro, foi descoberto o chat de suporte escondido atrás do ícone de interrogação no Google Play Console
  • O atendente prometeu acelerar a revisão, mas não forneceu prazo claro nem solução concreta
  • Chamou atenção o fato de ninguém na grande discussão no Hacker News ter mencionado esse caminho
  • Isso pode refletir a reputação de difícil acesso ao suporte do Google, fazendo desenvolvedores não esperarem ajuda direta
• Em 4 de setembro, a atualização corrigida foi finalmente publicada após 11 dias de revisão
• Depois disso, em vez de liberar imediatamente para 100% dos usuários, foi enviada uma release posterior menor usando rollout gradual, e essa atualização passou pela revisão em menos de 1 hora
• Em 7 de setembro, foi enviada outra pequena atualização para substituir a versão que havia chegado a 99,9999% dos usuários
  • Quando a nova versão entrou em revisão, o Google interrompeu automaticamente o rollout anterior sem aviso
  • Se a nova revisão tivesse demorado alguns dias, os usuários restantes também não teriam recebido a release anterior
  • Mesmo ao retirar a nova submissão, o rollout anterior não foi restaurado
  • Felizmente, essa revisão terminou em menos de 1 hora

Como o controle da plataforma muda a responsabilidade em produção

• Desenvolvedores mobile já passaram por muitos casos parecidos em que Google ou Apple atrasam correções urgentes em produção, removem apps ou quase não oferecem explicações para suas decisões
• Mesmo quando a equipe técnica consegue diagnosticar e corrigir um defeito rapidamente, o momento em que os usuários recebem a solução é controlado pelos operadores das lojas de aplicativos
• Para o usuário comum, pode não haver rollback, caminho alternativo de distribuição nem método confiável para acelerar a revisão
• Mesmo sendo dono do código-fonte e da infraestrutura, se você não controla o canal final de entrega, a natureza da posse da produção muda
• Quando um app nativo não é estritamente necessário, cresce o motivo para preferir a plataforma web aberta
  • Aplicações web muitas vezes conseguem fornecer a funcionalidade necessária, enquanto a própria equipe controla deploy, monitoramento e rollback
• Ainda há casos de uso válidos para apps nativos
  • dependência de recursos do dispositivo
  • execução em segundo plano
  • necessidade de distribuição via app store
• Escolher mobile é aceitar, junto com as vantagens do produto, o custo operacional de trazer um terceiro poderoso para dentro do processo de release

[GN⁺]

Opiniões no Hacker News

• Recebi esse e-mail tanto pessoalmente quanto no trabalho.
  No lado pessoal, crio e mantenho voluntariamente apps open source para sistemas de transporte público de 16 cidades, e por causa de uma tarefa que não beneficia ninguém tive que atualizar 16 apps em 2 semanas.
  Meu app é um PWA, e a versão Android é basicamente Cordova com alguns plugins para acrescentar algumas opções nativas. Ao atualizar o Cordova para dar suporte à nova API-alvo do Android, plugins que ainda não tinham sido atualizados quebraram, então passei o fim de semana inteiro trabalhando e testando.
  Sinceramente, eu queria remover os apps e fazer os usuários acessarem o site e instalarem o PWA, mas o usuário médio ainda não sabe como fazer isso. O primeiro lugar onde o usuário procura um app também continua sendo a Play Store. Eu já ficaria satisfeito se o Google ao menos permitisse enviar PWAs diretamente para a app store, e não quero repetir isso todo ano.
  No trabalho, também estamos correndo para responder. Temos um app legado usado por alguns clientes com suporte até o fim do ano; é um app bastante complexo, e só mudar a versão da API-alvo já quebrou várias partes nos testes básicos. Conseguimos uma extensão, mas sei que uma atualização sem nenhuma mudança de funcionalidade além de apaziguar o Google vai consumir 1 a 2 semanas de desenvolvimento e 1 a 2 semanas de QA. E isso para um app que será removido oficialmente da loja no fim do ano, quando todos os clientes migrarem para o app novo.

  • É para esses casos que existem as Trusted Web Activities (TWA). Dá para colocar um PWA na Play Store sem frameworks como o Cordova.
    https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
    https://developers.google.com/codelabs/pwa-in-play#0
  • Para deixar claro: não é só porque os usuários não sabem como fazer. É porque Google e Apple não tornaram isso tão fácil quanto instalar apps pelas suas próprias app stores. Isso é uma escolha, e uma escolha deliberada.
  • Acho que você entendeu mal os usuários. Não é simplesmente uma questão de ignorância. Eu gostaria que os apps voltassem a ser apps nativos de verdade, ou seja, não Cordova. Quase não há web apps que cheguem à experiência de um app real bem feito, e não de algo baseado na web feito de qualquer jeito.
  • Concordo. Alguns dos meus apps pessoais também foram afetados.
    Dito isso, esse prazo vinha sendo comunicado havia meses, e era óbvio que em algum momento ele seria mostrado de forma mais explícita. Não gostei da redação em si, e reclamar que a versão de produção estava ok, mas a versão de teste não atendia ao requisito, também não fazia sentido.
    Além disso, o problema sempre foi enviar uma nova atualização, e é assim todo ano. O app podia ter continuado público por um bom tempo.
    Então dizer que havia apenas 2 semanas não é correto.
  • Não sei se ajuda, mas, se fosse comigo, eu lançaria algumas atualizações do app com uma tela explicando como instalar a versão PWA e iria saindo gradualmente desses problemas. Também daria para oferecer um formulário de feedback sobre as dificuldades que os usuários encontrarem.

• Concordo que o desenvolvimento Android é difícil, mas o autor cometeu dois grandes erros.
  Primeiro, não testou o app na versão mais recente do Android. Isso é um erro muito grande, e é por isso que mantemos 11 máquinas virtuais para todas as versões do Android que damos suporte.
  Segundo, ao distribuir um app no Google Play, você nunca deve liberá-lo para 100% dos usuários logo de início. Distribuição gradual é o padrão, e nós nunca passamos de 10% dos usuários no começo depois de publicar um release. Quando ganhamos confiança, distribuímos para 99%, não para 100%. Assim, se por qualquer motivo precisarmos interromper a distribuição, é fácil parar desde que ela não tenha sido feita para 100%.
  Gostem ou não, esses dois métodos são táticas bem conhecidas por desenvolvedores Android experientes.

  • Concordo que dava para ter feito melhor em vários aspectos. Mas, como expliquei, este é um aplicativo legado, não um app em desenvolvimento ativo hoje, então não faz sentido montar uma estrutura de QA tão robusta. Esse app foi escrito há muito tempo por outra empresa e nem testes unitários simples ele tem. Essa é a realidade.
    Mas, mesmo com uma estrutura tão complexa, erros acontecem, e o verdadeiro problema é que não há como reverter, cancelar ou fazer rollback de um release.
    Como a distribuição gradual ajuda todos os clientes nessa situação? Quando um usuário final recebe uma versão quebrada, existe algum modo de ele receber a versão funcional?
  • Uma dica: esse campo também aceita valores decimais. Nós sempre configuramos como 99.99999999% para que nenhum usuário fique de fora por engano. Ao mesmo tempo, como você disse, isso permite cancelar a distribuição.
  • Se for preciso manter uma máquina virtual para cada versão suportada do Android, tudo bem, mas isso acaba fazendo a gente se perguntar: afinal, para que serve a taxa de 30% da receita?
  • Isso soa um pouco como culpar a vítima. Essas duas coisas nem deveriam ser um problema em primeiro lugar.
  • O que você disse está absolutamente correto e é a única forma prática de fazer atualizações e releases. Mas é lamentável que não se possa esperar que uma atualização de API simplesmente funcione se compilar.

• Não entendo as reações que estão encurralando o autor do post original. Claro, ele poderia ter sido mais cuidadoso e poderia ter testado o login no Android mais recente. Mas e se não fosse um crash no login? E se funcionasse na versão mais recente, mas não em outra? Onde traçar a linha?
  Em algum momento, é preciso dizer: “esta é, literalmente, uma plataforma usada por milhões de apps e milhões de desenvolvedores; erros podem acontecer; e deveria ser possível corrigir isso facilmente, por exemplo republicando imediatamente uma versão anterior já aprovada, sem precisar saber truques como pausar a própria distribuição ou fazer rollout gradual”. Especialmente em lugares como uma app store, tornar as mudanças reversíveis e recuperáveis é um princípio básico de design

  • Sou o autor do post original, e obrigado por pensar junto. Como já disse em várias respostas, concordo totalmente que eu poderia ter feito melhor do ponto de vista de testes. Claro, sempre há espaço para melhorar nessa parte
    O Google definiu o prazo e, repetindo, eu só soube disso em 18 de agosto; antes disso eu não sabia. A mudança parecia trivial na época e, como o app funcionava como antes nas versões antigas do Android, eu não previ que falharia de forma tão catastrófica
    Não sou um desenvolvedor Android experiente, mas tenho mais de 15 anos de experiência em desenvolvimento de software em geral, então tenho uma certa noção de como as coisas funcionam, do que esperar e do que temer. Eu realmente não sabia que um rollout gradual de 99,99999999% era a boa prática para manter a possibilidade de “retirar” ao menos parcialmente a versão mais recente
    Eu jamais imaginei que não haveria uma forma de cancelar ou excluir a versão mais recente e voltar para a versão anterior que funcionava. Parece ser algo que só se aprende passando por essa situação
    Dá para me culpar por não ter testado todos os recursos em todas as versões do Android, e eu também penso assim, mas espero que as pessoas abram os olhos e entendam que a forma como a Play Store lida hoje com lançamentos não é algo que uma pessoa normal faria fora da Play Store. Qualquer um pode passar por um problema desses um dia, e espero que este texto e esta thread reduzam o número de desenvolvedores que enfrentam situações parecidas
  • “E se funcionasse na versão mais recente, mas não em outra?” é uma desculpa fraca. Mesmo em uma aplicação web, é preciso testar em vários navegadores
    Um smoke test para uma nova release é ética profissional básica
    Rollout gradual com rollback também não é um conceito novo
  • Não há desculpa para portar o app para o Android 13, isto é, para targetSdkVersion 33, sem fazer testes no Android 13

• A frase “voltemos aos padrões abertos da web para retomar o controle” pode soar diferente quando você percebe que a web também é controlada pela metade pela Google, a mesma empresa que está causando o problema agora. A Apple, com o Safari, que é na prática o único navegador no iOS, também não é exatamente sua amiga

  • Isso também é verdade, mas pelo menos problemas assim podem ser tratados com rollback e coisas do tipo. Na situação atual, você sabe que um build ruim está em produção e que os celulares estão sendo atualizados automaticamente para ele, mas não pode fazer nada. Isso é o pior
  • Hospedar na web pode acabar exigindo mais manutenção do que simplesmente pagar o custo
    Eu definitivamente prefiro um site a um app qualquer que existe só para rastrear melhor, mas li este texto como um caso de manutenção feita meio nas coxas
  • Se você se recusa a embarcar em uma direção que prioriza a privacidade e a segurança do usuário, a Apple certamente não é sua amiga. Se for para dar um motivo, é esse

• Esta é uma situação impossível de vencer
  A Microsoft investe um esforço enorme em compatibilidade retroativa, e isso é algo bastante digno de reconhecimento. Mas, na mesma medida, a superfície de ataque também aumenta muito
  Da mesma forma, muitos dos piores aspectos do C++ que é injustamente criticado vêm da postura rígida em relação à compatibilidade retroativa. Código antigo, até código C antigo, deve continuar compilando e se comportando como esperado pelo maior tempo possível, chegando ao ponto de aceitar vincular com binários antigos cujo código-fonte foi perdido
  A maioria não faz esse nível de esforço e invalida o que é antigo em nome de manutenibilidade, confiabilidade e segurança
  Qualquer ponto de bifurcação que você escolha, alguém sai prejudicado. Se não, é porque ninguém usa aquele código

  • Exato. Esse é um lado do problema, e eu também não estou pedindo compatibilidade retroativa excessiva. A maior preocupação nesta situação específica é que, no Android, não há como reverter, cancelar ou fazer rollback de uma release, e tudo fica bloqueado atrás do processo de revisão do Google
    Por que é impossível “retirar” uma release problemática e continuar mostrando a release anterior como a versão mais recente? Isso resolveria a maior parte dentro do contexto deste problema
  • Acho que um meio-termo que ajuda todo mundo é mudar a API e quebrar a compilação. Basta fazer o desenvolvedor corrigir os erros de compilação e usar a API corretamente
    Mas não se deve mudar o comportamento de uma função existente com a mesma assinatura. Se você fornece uma API, deve fazer o máximo para que a compilação tenha significado
  • Não há uma opção vencedora ideal, mas também dá para distribuir o app separadamente. Isso não é um requisito do Android, é um requisito da Play Store
    Em muitos casos, não é nada simples e nunca será tão usado quanto a versão da Play Store, mas é bom existir uma rota de fuga
  • O que o autor parecia reclamar principalmente era do fato de o Google fazer o papel de árbitro sobre que software os usuários podem executar. A questão da descontinuação de APIs foi apenas o gatilho que nos fez perceber o quanto ficamos vulneráveis aos caprichos do Google
  • É difícil aceitar isso como desculpa do Google
    A maioria dos aplicativos distribuídos no Android mira bytecode do Android. Não são aplicativos compilados nativamente
    O motivo pelo qual C++ cria problemas de segurança difíceis de superar é sua natureza de baixo nível e o fato de que, uma vez gerado um binário nativo, acabou
    Mas, se for bytecode de uma linguagem com segurança de memória, por que não seria possível fazer backport de correções de segurança? Executar esse tipo de código já tem, por natureza, o aspecto de recompilar bytecode continuamente
    Para ver o quanto essa posição é absurda para o Google, a JVM ainda hoje consegue executar e usar classes direcionadas ao Java 1.0, lançado em 1996
    Isso não é um problema de segurança, é um problema de “o Google não quer dar suporte à plataforma”
    Dá até para entender, em certa medida, o Google ser mais rígido com artefatos que contenham código compilado nativamente. Mas uma política generalizada do tipo “o app foi criado mirando uma versão antiga do Android, então não vamos mais dar suporte” não faz sentido. Parece mais uma forma de podar apps antigos da loja do que uma questão de segurança
    Especialmente porque esse tipo de política essencialmente empurra um grande ônus de manutenção para os desenvolvedores Android. Para dar suporte ao maior público possível, você acaba mirando a versão mais antiga possível do Android. Quase ninguém mira a versão mais recente do Android, com medo de excluir clientes demais
    Se o Google levasse a sério segurança e amplo acesso às tecnologias mais recentes do Android, tentaria separar o runtime do Android da versão do sistema operacional. Não há motivo para que os runtimes ART e Dalvik não possam ser distribuídos pelo Google Play, como outras partes do ecossistema Android. Isso também eliminaria situações idiotas como “para fazer isto, você precisa do Android 17… ah, o fabricante do hardware não atualiza os drivers”
    Mas isso prejudicaria as vendas de novos dispositivos, então deve ser inaceitável

• Sempre foi óbvio que a Play Store e a “comunidade” de desenvolvedores presa dentro dela eram uma armadilha. Upgrades obrigatórios de API são apenas um dos aspectos disso
  Há claramente tarefas em que celulares ou apps móveis são melhores. Normalmente coisas relacionadas a movimento, como navegação, ou coisas que dependem dos sensores do telefone, como descobrir qual lado é “para cima”. Mas quase todo o resto pode ser feito com um site
  Deve ser realmente difícil manter sozinho um app móvel multiplataforma, e eu simpatizo. Só que, como decidi há muito tempo que não queria participar do jogo das plataformas proprietárias e gatekeepers, minha simpatia vem totalmente da perspectiva de alguém de fora

  • Na verdade, até essas duas coisas podem ser feitas facilmente em apps de navegador
    Hoje, a única coisa que praticamente ainda não é fácil no mobile são GPU compute shaders. Mas, quando o WebGPU migrar dos navegadores de desktop, isso também vai cair
    Outra coisa que me vem à mente é o gerenciamento geral de arquivos em todo o sistema. Isso provavelmente nunca vai chegar. A File System API até permite que o usuário conceda acesso a diretórios específicos, mas não sei se essa permissão persiste depois de recarregar a página
  • Eu tinha certeza de que as lojas de apps fracassariam. Porque não achava que desenvolvedores suficientes aceitariam abrir mão da garantia de poder realmente distribuir seus próprios apps
  • É engraçado ler isso em um site que frequentemente ataca o Google por não fazer gatekeeping suficiente de software no Android, e elogia o iPhone como melhor justamente por controlar tudo de forma mais agressiva
  • Você não vai querer insistir ideologicamente na soberania do usuário sobre o próprio dispositivo, certo? Em vez disso, basta agir de forma inteligente e prática, seguindo o caminho de menor resistência até entrar por conta própria no cercado

• É irônico pensar que um dos princípios de SRE do Google é “rollback é normal”
  https://cloud.google.com/blog/products/gcp/reliable-releases...
  “No Google, nossa filosofia é que ‘rollback é normal’. Se um erro for encontrado em uma nova release, ou houver suspeita razoável, a equipe de release primeiro faz rollback e depois investiga o problema. Uma solicitação de rollback não é interpretada como um ataque à equipe de release nem à pessoa que escreveu o código com bug. Pelo contrário, é entendida como a coisa certa a fazer para tornar o sistema o mais confiável possível para os usuários. Desde que o problema observado esteja descrito na lista de mudanças do rollback, ninguém pergunta ‘por que vocês fizeram rollback dessa mudança?’”

  • Pelo que era no ano passado, a combinação das políticas do Google Play com as atualizações do Android significa que, se você distribui um app pela Play Store, a única forma de fazer rollback é desinstalar e redefinir os dados do usuário
    Não é possível fazer downgrade para um versionCode menor, e o versionCode é definido pelo desenvolvedor
    O Android 11 proíbe escrever no armazenamento “permanente” do telefone, exceto pelo uso das exceções de mídia ou da API DocumentFile, que trata pastas locais como armazenamento em nuvem. DocumentFile não serve para muitos casos de uso
    O desenvolvedor pode definir hasFragileUserData, caso em que, ao desinstalar, o usuário deveria ser perguntado se deseja apagar os dados. Mas, por causa de um bug do Google/Android, essa caixa de diálogo pode não ser exibida
    Se o app for desinstalado e o usuário não apagar os dados, o Android impede o downgrade para um versionCode menor
    Ao solicitar MANAGE_EXTERNAL_STRORAGE, é possível usar o java.io.File comum
    O Google Play só permite MANAGE_EXTERNAL_STRORAGE em casos excepcionais
  • “Rollback para mim, mas não para você”

• A mesma coisa aconteceu em vários apps baseados em um framework que eu criei. Uma nova versão da API entrou em conflito com dependências existentes, e foi preciso um trabalho enorme só para voltar exatamente ao estado que já existia
  Passei a respeitar muito mais a Microsoft, onde coisas dos anos 90 rodam no Windows moderno com menos problemas do que um app móvel que escrevi para Android há 4 anos

  • Se o framework usado não veio do Google, isso é uma afirmação injusta
    Você não culparia a Microsoft pelo Adobe Flash não funcionar na loja do Windows 11, certo?

• Vejo desvantagens demais e praticamente nenhuma vantagem em ser forçado a distribuir apps apenas por uma única loja de apps “autoaprovada”.
  A suposta vantagem, ironicamente, é que o administrador da loja de apps verifica malware e vírus antes da publicação. Mas apps cheios de anúncios do Google e rastreadores do Google/Facebook são bem-vindos em todas as formas.
  Também há o fato de facilitar para o usuário pesquisar, instalar e atualizar apps — se ele conseguir encontrar o que quer em meio a bilhões de apps de jogos e a apps muito parecidos, publicados só para enviar anúncios ou coletar dados pessoais.
  A desvantagem é ficar preso aos caprichos do administrador da loja de apps e não ter controle sobre o processo de publicação do app. Não sou eu que decido se posso publicar o app, nem quando; quem decide é o administrador da App Store, conforme a conveniência dele. Acho que esse direito deveria caber apenas ao usuário.
  Para apps nativos comerciais, como um app de home banking, eu gostaria de fazer login na área privada do site do desenvolvedor e baixá-lo de lá. O app deveria ser assinado com GPG e permitir a verificação da integridade do pacote. Atualizações automáticas também seriam possíveis.
  Para apps open source, existe a loja F-Droid, e é possível adicionar repositórios próprios. Admito que é um pouco técnico e não serve para todo mundo. Seria uma grande ajuda se o F-Droid viesse pré-instalado em celulares novos, mas não acho que o Google permitiria.
  Outra opção realista são os PWAs. Na minha opinião, pouquíssimos apps precisam de recursos nativos, e quase todo o resto é possível com tecnologia de PWA. Também não é preciso enviar atualizações aos usuários nem pedir que façam upgrade.
  Lojas de apps proprietárias e comerciais, operadas sob o pretexto de facilitar a vida do usuário e oferecer “mais segurança”, são um “ótimo” meio para Apple e Google ganharem bilhões de dólares com o trabalho de desenvolvedores independentes e, no caso do Google, coletarem e venderem dados pessoais dos usuários e venderem anúncios de todo jeito.

  • Você deixou passar outra vantagem: poder manter o Boston Strangler[0] do lado de fora da sua casa. Se você amarra as mãos do usuário para trás, pode determinar em que condições ele usa o seu trabalho. Sem pirataria, sem bloqueio de anúncios.
    Foi por isso que os desenvolvedores de jogos nos anos 80 e 90, em geral, seguiram o modelo “Licensed by Nintendo”, e que os desenvolvedores de apps móveis no fim dos anos 2000 seguiram exatamente o mesmo caminho com a iOS App Store. Eles não querem cooperar diretamente com os usuários para contornar o dono da plataforma. Querem que o dono da plataforma amarre as mãos dos usuários, e aceitam que suas próprias mãos também sejam amarradas no processo.
    Pegue o caso de um app de banco, por exemplo: o banco quer autenticação remota segura. Quer bloquear usuários que façam ataques de credential stuffing contra o app, impedir que malware abra o app do banco e aperte o botão “transferir dinheiro para o golpista”, impedir que o usuário extraia segredos criptográficos relacionados a tap-to-pay e também impedir que segredos roubados sejam injetados no app do celular.
    O app não consegue verificar por conta própria se as mãos do usuário estão amarradas. É preciso haver um terceiro confiável, confiável para o banco, não para o usuário, presente na cadeia de boot ou no EL3. Por isso a ideia não é simplesmente entregar o app e a assinatura; o que querem é que o Google faça isso, para que o Google possa amarrar as mãos do usuário.
    É importante notar que todos os benefícios das lojas de apps para o lado do usuário são racionalizações posteriores. Desde o início, o objetivo era manter os usuários amarrados. Porque, para eles, o usuário é uma espécie de mosquito ladrãozinho. Essa é a “parte silenciosa” que eles não dizem em voz alta.
    Espero muito que a proposta WEI do Google não vire realidade e que os PWAs não tenham acesso a recursos de comprovação. O Google já vem com aquela bobagem de “não dá para fazer login em navegadores desconhecidos”, e esse câncer não precisa se espalhar.
    O F-Droid é excelente. As manobras do Google no Android precisam ser barradas. A UE poderia ter feito isso, mas os EUA também precisam fazer e fazer valer internacionalmente.
    [0] Codinome que a MPAA usava para cópias não comerciais em pequena escala, isto é, gravar programas de TV em um videocassete. Jack Valenti era mesmo uma pessoa péssima, não era?

• Há anos também sou contra desenvolver apps móveis, porque, no momento em que você decide desenvolver um app móvel, entrega o controle do produto ou serviço a um terceiro.
  Não é difícil concordar.
  Se “suporte” significa esperar receber uma atenção útil no HN ou no Twitter, estamos indo pelo caminho errado.