Isso encerra a semana de lançamento. O sábado certificado wizard assinou seu aplicativo. Hoje, a funcionalidade lida com o que vem depois da conclusão da build: upload do binário, preenchimento das notas de lançamento, atualização da lista e repetição em cada loja onde seus usuários estão. PR #5353 cobre a ferramenta do cliente; o trabalho pesado está na nuvem de build.
O que é Codename One? Codename One é um framework open-source para criar aplicativos nativos iOS, Android, desktop e web a partir de uma única base de código Java ou Kotlin. Saiba mais em codenameone.com.
Apos a Build Virar Verde
O lançamento não está concluído quando a build vira verde. Alguém ainda precisa fazer o upload do .ipa para App Store Connect, colar o texto de novidades em dois ou três consoles web, re-enviar as capturas de tela porque a loja sinalizou uma delas e repetir o ritual por localidade. Para um único aplicativo é uma hora irritante. Para uma equipe mantendo dez apps entre App Store, Google Play e AppGallery, é um trabalho parcial que produz nada além de erros de copiar e colar.
A obra anterior mais óbvia é o fastlane, que automatizou isso há anos e funciona bem se você manter uma ferramenta Ruby e configurações de lane por loja. O nosso está integrado ao pipeline que já constrói e assina seu binário, reutiliza as credenciais já armazenadas e cobre a AppGallery.
A console de build agora tem uma ação Submit em cada build bem-sucedida: para o App Store para um iOS .ipa, Mac App Store para um .pkg e Google Play ou Huawei AppGallery para Android. Escolha Beta ou Produção, adicione notas de lançamento e o binário é entregue. Para uma submissão de produção Apple a console rastreia o estado da revisão (processando, em revisão, aprovado ou rejeitado) e pode enviar um email quando isso muda.
A fronteira, declarada simplesmente: a submissão automatizada entrega binários e metadados para um registro de aplicativo existente. Criar o registro do aplicativo e responder aos questionários de privacidade e classificação de conteúdo são etapas manuais uma vez em cada console da loja, e nossa pipeline deliberadamente fica fora dos preços e configurações de compra dentro do aplicativo. Depois dessa configuração única, todos os binários e listagens de lançamento são enviados automaticamente.
Sua Lista é Código Agora
A parte que eu gosto mais é cn1:metadata-push. Sua lista de loja, a descrição, subtítulo, palavras-chave, texto de novidades e capturas de tela, tornam-se uma pasta de arquivos simples em seu repositório:
cn1-metadata/
apple/
en-US/
name.txt (max 30 chars)
subtitle.txt (max 30 chars)
description.txt (max 4000 chars)
keywords.txt (comma separated)
whats_new.txt
screenshots/
APP_IPHONE_67/1.png 2.png ...
google/
en-US/
name.txt
subtitle.txt (short description, max 80 chars)
description.txt
whats_new.txt
screenshots/
phoneScreenshots/1.png 2.png ...
Os nomes dos arquivos são neutros e mapeiam aos campos de cada loja: subtitle.txt se torna o subtítulo da App Store e a descrição curta do Google Play. Um arquivo que você não inclui mantém o valor atual da loja. O comando mvn cn1:metadata-init cria toda a estrutura, e o push é um único comando:
mvn cn1:metadata-push # ambos os stores de cn1-metadata/
mvn cn1:metadata-push -Dstore=apple # ou apenas um
Cada campo é validado contra os limites da loja antes de ser armazenado, então um nome muito longo falha rapidamente em sua máquina ao invés de meio caminho durante a submissão. A metadados empurrados são aplicados na próxima vez que você enviar uma build para aquele pacote, e a aplicação é projetada para fazer o melhor esforço: o binário é entregue primeiro, então um campo rejeitado nunca bloqueia uma release, apenas aparece como aviso no console.
Como a lista vive no git e os empurrões são feitos da linha de comando, se encaixa em CI: gere whats_new.txt do seu changelog, empurre, submeta. Dez apps param de ser dez consoles.
Além do Google Play
Aqui está a parte narrativa, e podemos dizer diretamente. A Google oferece uma loja de aplicativos e um framework de aplicativos, e suas ferramentas tratam naturalmente o Play como o ponto final. Não temos uma loja, então não temos interesse em qual vence. Nosso trabalho é alcançar o maior público possível com a menor fricção possível, independentemente da loja.
Isso importa porque uma grande parcela dos usuários do Android não pode instalar aplicativos do Google Play de forma alguma: a maioria do mercado na China, mais muitos dispositivos Huawei em outros lugares. A AppGallery é portanto um alvo de submissão de primeira classe, exatamente como a App Store e o Play. Para as longas caudas dos mercados Android (Xiaomi, OPPO, VIVO, Tencent MyApp e os demais), a compilação pode produzir pacotes para canais de distribuição: seu mesmo APK assinado de lançamento com um ID de canal específico da loja, que o aplicativo lê de volta em tempo de execução com Display.getInstance().getProperty("DistributionChannel", "") para relatórios sobre a fonte do instalador, sem envolver nenhum SDK de terceiros. O Play sempre recebe o pacote padrão e não modificado App Bundle, então nada disso afeta sua conformidade com o Play.
Credenciais são por loja e configuradas uma vez no console: a mesma chave da API do App Store Connect que o assistente de certificados armazenou no sábado, uma conta de serviço do Google Play e um ID de cliente e segredo da API da Huawei.
No que diz respeito ao preço: a submissão manual, o download do seu build e o upload por conta própria permanecem ilimitados e gratuitos em todas as camadas, como sempre foi. Os limites de plano se aplicam apenas à pipeline automatizada.
Contas Organizacionais
Duas pequenas mudanças no Build Cloud foram lançadas junto com isso, e elas se encaixam na mesma temática de equipes enviando muitos aplicativos.
Agora as contas do Build Cloud podem pertencer a uma organização. Os membros compartilham visibilidade nos aplicativos que a equipe constrói, nas análises e relatórios de falhas ao redor deles, e em dados comuns como as credenciais de submissão acima, enquanto os builds e quotas permanecem individuais. As assinaturas e o pagamento são cobrados para a organização em vez de um cartão pessoal.
E as contas agora têm exclusão de conta por autoatendimento. Sem ticket de suporte, sem troca de e-mail: uma seção de zona perigosa nas configurações da conta remove permanentemente sua conta e todos os seus dados, incluindo certificados de assinatura, builds, relatórios de falhas e análises, e registros de cobrança. Se você sair, não deve ter que pedir permissão para levar seus dados com você.
Encerrando a Semana
Essa é a nova versão: uma VM que troca golpes com HotSpot aquecido, um assistente de certificado que parou de se passar por você, AR que você pode depurar na sua mesa e uma linha de montagem de lançamento que termina nas lojas em vez do binário. O fluxo de envio é documentado do início ao fim no novo capítulo da guia do desenvolvedor, "Envio para a App Store". Tente isso na próxima versão e nos diga onde há problemas.