Publicação de apps nas lojas de aplicações
Neste artigo vou falar de um passo obrigatório para qualquer programador de aplicações móveis, o processo de submissão na loja de aplicações. Dependendo do ecossistema, este pode ser um processo intuitivo, como é o caso para o sistema operativo Android, ou mais artilhado, como é o caso da Apple.
A Apple, pioneira, estabeleceu como diretriz que tudo o que fosse publicado na loja iTunes tinha que ser uma experiência única e gratificante para os seus utilizadores. Steve Jobs estabeleceu isso com punho de ferro dentro e fora da empresa. Nenhuma app é publicada sem validação interna, isto é, humana. O revisor destacado segue uma checklist apertada de pontos a inspecionar, que vai desde a confrontação dos metadados inseridos na ficha com o visualizado na aplicação até à execução de todas as funcionalidades no último modelo da marca, desativando todas as permissões e stressando a aplicação para ver se ela suporta o uso de uma utilização típica. A aplicação chumba sempre que houver uma anomalia como, por exemplo, indicar-se que se trata de uma aplicação de fitness e na realidade ser comércio de gadgets eletrónicos ou a secção de ajuda conter um “lorem ipsum”, restos do processo de desenvolvimento, representando um comentário de um utilizador.
Os ecossistemas Android e Windows Mobile, por terem entrado já tarde neste nicho de mercado, tiveram que simplificar o processo de forma a facilitar o desenvolvimento. Por exemplo, enquanto na Apple o acesso ao programa de desenvolvimento implica um pagamento anual de 99 USD, nas concorrentes Google e Microsoft basta um pagamento único substancialmente inferior para ter a possibilidade de publicar nos seus dispositivos. Claro que há diferença de tratamento entre plataformas. No caso da Apple, se enviarmos um pedido de ajuda, por exemplo, solicitando mais detalhes sobre uma build reprovada, ao fim de alguns dias recebemos uma chamada de Cupertino/Califórnia, de um técnico especializado a informar, de forma educada, que o problema está entre o teclado e a cadeira, pois nos esquecemos que a aplicação deve ser passível de execução, mesmo que o utilizador desative a permissão de notificações Push.
Dito isto, voltemos ao intuito deste artigo: falar sobre publicações de aplicações nas lojas de aplicações dos nossos smartphones.
Em primeiro lugar, devemos criar uma conta de programador nos vários ecossistemas em que pretendemos publicar a nossa aplicação.
No caso da Apple Store, devemos aceder ao link https://developer.apple.com e criar uma conta de desenvolvimento. Para tal precisamos de um Apple ID, o mesmo que é usado pelo iCloud, iTunnes e outros serviços da Apple. Caso não tenhamos um Apple ID, ser-nos-á pedido para criar um. Tendo a conta criada, é necessário inscrever-nos no programa de desenvolvimento da Apple usando a opção “Enroll”.
É neste passo que definimos os dados apresentados na Apple Store sobre o produtor da app e temos duas opções: podemos inscrever-nos como produtor individual (ou empresário de nome individual) ou como empresa/organização.
Nota. A Apple usa os serviços da D’U’N’S para validar a veracidade da informação inserida. Se precisamos de nos registar como empresa/organização, precisamos de garantir que a empresa se encontra listada em https://developer.apple.com/enroll/duns-lookup/. Caso não cumpramos os requisitos legais ou não consigamos efetivar o pedido de inserção dos dados da organização, podemos sempre subscrever-nos como individual.
Depois de preencher os dados requeridos, quer como Individual quer como Organização, o processo salta para a página de pagamentos.
Inserimos os dados do cartão de crédito e, quando a transacção é finalizada com sucesso, regressamos a nossa conta Developer já com um leque vasto de opções.
No caso da Google o processo é muito mais simples. Com a nossa conta Google, entramos na loja via Developer Console, no url https://developer.android.com.
Na primeira interação com a nossa conta de desenvolvimento, temos que seguir o fluxo apresentado, aceitar os termos do serviço, inserir os dados do cartão de crédito para pagar a taxa de serviço de 25 USD e, por fim, inserir os dados de autoria que serão apresentados na loja.
Com a Microsoft, o processo é semelhante. O acesso é feito pelo link https://developer.microsoft.com e a taxa de subscrição é de 15 USD para individuais e 99 USD para empresas e organizações. Tal como na Google, trata-se de um pagamento único.
Com as nossas contas criadas podemos passar ao segundo passo: criar a ficha da nossa aplicação. Nos ecossistemas Android e Windows podemos deixar esse passo para o fim. Podemos criar a ficha e submeter o binário produzido pela nossa ferramenta de eleição ou podemos criar e desenvolver a aplicação, deixando a ficha da app para o fim. É um passo lógico já que vamos necessitar de screensshots da app para introduzir na ficha.
No caso do Android, o habitual será usar o Android Studio. Ao gerar uma build, a ferramenta requer a criação de um certificado que fica armazenado do lado do cliente, numa keystore. Esse certificado, uma vez usado na publicação de uma build, terá que ser mantido e usado em todas as atualizações seguintes ou a Play Store não permitirá atualizações. No visualStudio, o processo é semelhante. Em ambas as plataformas os certificados são gerados localmente.
No caso da Apple o percurso é outro. Todos os certificados são gerados na console de desenvolvimento, na secção “Certificates, Identifiers & Profiles”, e a sua geração segue um fluxo rígido. Tudo o que seja relacionado com a ficha da app na loja e gestão de versões se encontra concentrado no “iTunes Connect”.
Para criar a ficha da nossa aplicação, devemos obter primeiro um App ID. O App ID é um identificador único para todo o universo Apple. Vou usar como exemplo uma app que criei chamada Intimidades. A motivação e a base psicológica por detrás desta aplicação serão explicadas num futuro próximo, no meu blog pessoal http://assimsomos.apmuga.com. Para os efeitos deste artigo basta dizer que se trata de uma aplicação HTML5 com PhoneGap/Cordova usando a ferramenta XDK da Intel para geração de builds. Podia ter usado o DevExtreme ou outra ferramenta equivalente. Também podia ter criado aplicações nativas com o Android Studio, VisualStudio e o Xcode; no entanto, isso implicava ter que criar três aplicações em vez de uma.
Conforme apresentado na ilustração seguinte, é necessário criar um App ID, com o formato revertido com.domainname.appname, indicando que serviços serão disponibilizados. Neste caso apenas pretendo usar o Push Notifications.
Depois de criar o App ID temos que gerar dois certificados, um para desenvolvimento (“iOS App Development”) e outro para produção (“App Store and Ad Hoc”). Como os nomes indicam, o primeiro serve para assinar os binários de desenvolvimento, quando os instalamos manualmente com o iTunes. O segundo certificado, o de produção, é usado para submeter os binários na loja de aplicações. O processo consiste em criar um CSR, Certificate Signing Request, com a nossa ferramenta de desenvolvimento ou outra tool semelhante.
O Processo não acaba aqui já que será pedido para inserir o certificado associado ao pedido acabado de criar. Vamos à gestão de certificados Apple onde inserimos o nosso CSR e, depois do certificado ter sido gerado, fazemos o download do nosso certificado de desenvolvimento.
Regressando à nossa ferramenta de desenvolvimento, nela devemos ter uma janela a pedir o novo ficheiro gerado pela Apple e uma password para o usar sempre que pretendemos criar uma build nova.
Alem dos certificados de desenvolvimento, para podermos instalar os nossos binários nas máquinas de testes ou na loja propriamente dito, precisamos de criar perfis de aprovisionamento. Para criar um perfil de aprovisionamento para desenvolvimento, precisamos de inserir e registar equipamentos (iPads, iPods, iPhones, etc…). Todos os equipamentos da Apple possuem um UDID (Unique Device Identifier). Para obter o UDID usamos a ferramenta iTunes.
Para cada dispositivo que pretendemos instalar nas nossas versões de teste, precisamos de inserir o respectivo UDID na plataforma Apple. Por fim, vamos à secção de Provisioning Profiles e criamos dois perfis de aprovisionamento: um para o desenvolvimento, para permitir instalar a build nos dispositivos de testes.
O outro serve para enviar a build final, de produção, para a Apple para inserir na loja.
O processo de criação de um perfil de aprovisionamento é constituído por três fases. Primeiro escolhemos o App ID da aplicação pretendida; em seguida, escolhemos o certificado, de desenvolvimento ou de produção consoante o tipo de perfil que pretendemos criar.
Por fim, caso se trate de um perfil de desenvolvimento, são pedidos os dispositivos onde iremos proceder à instalação da build.
No caso de um perfil de aprovisionamento de produção, como esperado, saltamos o passo de seleção de dispositivos. Caso a nossa aplicação precise de Notificações Push ou de outros serviços, teremos que criar certificados para cada solicitação da mesma forma que criámos os certificados para desenvolvimento e produção.
Neste ponto, com o App ID, os certificados e os perfis de aprovisionamentos criados, podemos começar a trabalhar na nossa aplicação iOS. Precisamos de instalar os certificados e os perfis de aprovisionamento na nossa ferramenta de desenvolvimento e configurar o nosso projeto com as imagens para os icones e ecrãs splash, tanto em iOS como em Android e noutras plataformas.
Já podemos ir ao iTunes Connect e criar a ficha da nossa aplicação. O iTunes Connect agrupa todas as funcionalidades associadas à venda e divulgação das apps no iTunes. Podemos ver a evolução de utilização, de vendas, de gestão de pagamentos e de impostos pagos.
Dentro da secção “As minhas Apps” criamos uma nova App e inserimos os dados base, indicando o App ID criado anteriormente.
Temos que introduzir a informação base, os chamados metadados, definição de preços, screenshots de um iPhone 5,5” e de um iPad de 12,9”, uma conta demonstração e dados de contacto para pedidos de informação e dúvidas na validação da app pela Apple.
Neste processo, o mais invulgar é a impossibilidade do upload do binário, ao contrário da Google ou Microsoft, em que realizamos o upload do binário final diretamente na ficha. Esse upload, no caso da Apple, é obrigatoriamente feito de um Mac, com o XCode ou o Application Loader. Não há outra forma de enviar binários para o iTunes Connect. Para quem não possui um Mac, serviços como o MacInCloud são bem vindos e resolvem bem o problema.
Submetemos o binário. Esperamos uns minutos para este ser processado e voltamos ao iTunes Connect onde já teremos a possibilidade de escolha do ficheiro submetido. Finalizamos a ficha, gravando, e, quando tiverrmos tudo pronto, enviamos para revisão. Respondemos às últimas perguntas sobre publicidade, criptografia e outros itens legais e, se tudo estiver conforme as políticas editoriais da Apple, a aplicação entra no estado “Aguardar Revisão”. O tempo médio de espera para início da revisão é de dois/três dias e cada revisão costuma demorar umas horas entre o seu início e a sua finalização. Como tudo na vida, a primeira vez que submetemos uma app na Apple Store sofremos de ansiedade até receber o tão desejado email com a menção de “Pronta para Venda”, sinal de que tudo correu bem e que esta passou pelo crivo da Apple.
Nota: Sempre que houver revisões, é necessário esperar pela realização de todo o processo de verificação da Apple. Por este motivo, recomenda-se uma boa política de testes e qualidade antes de enviar o que quer que seja. Muito dificilmente poderá “falar com alguém” para acelerar este processo.
Nos outros ecossistemas, a publicação de aplicações é um processo bem mais simples. Criamos a ficha da app onde inserimos todos os dados pedidos, id’s, metadados, definição de preços, descrição e previews em vários tamanhos predeterminados. Carregamos o binário final e submetemos para publicação. Se tivermos inserido toda a informação necessária e aceitado os termos de publicação e o binário enviado tiver sido aceite com sucesso, teremos em questão de horas a aplicação publicada.
As revisões são igualmente simples. Submetemos um novo binário. Inserimos um descritivo sobre as mudanças introduzidas e, quando submetido com sucesso, este substituirá a versão actual.
Termino por aqui. Há mais por dizer. Como, por exemplo, políticas de privacidade que devem ser consideradas com cuidado.
Boas submissões.
André P. Muga
www.apmuga.com