Eu construí um Progressive Web App e o publiquei em 3 lojas de aplicativos. Aqui está o que aprendi.

Um mês de trabalho, várias centenas de dólares e muita burocracia.

Recentemente, publiquei Chavah Messianic Radio, um reprodutor de música parecido com o Pandora, como um Progressive Web App e o enviei para as 3 lojas de aplicativos (Google Play, iOS App Store, Windows Store).

O processo foi doloroso e esclarecedor. Aqui está o que aprendi.

Por quê?

Primeiro, você pode se perguntar: “Por que colocar seu aplicativo nas lojas de aplicativos? Apenas viva na web aberta! ”

A resposta, em poucas palavras, é porque é onde os usuários estão . Treinamos uma geração de usuários para encontrar aplicativos em lojas de aplicativos proprietárias, não na web gratuita e aberta.

Para meu aplicativo da web, houve dois grandes motivos para entrar na app store:

  1. Demanda do usuário
  2. Restrições de aplicativos da web por plataformas móveis hostis da Apple

Demanda do usuário: meus usuários me perguntam há anos: “Existe um aplicativo para Chavah? Não vejo na loja. ”

Eles perguntam isso porque treinamos os usuários para procurar aplicativos em lojas de aplicativos proprietárias.

Minha resposta aos meus usuários até agora tem sido,

“Aww, você não precisa de um aplicativo - basta acessar o site no seu telefone! Funciona!"

Mas eu estava meio que mentindo.

Os aplicativos reais da web funcionam apenas meio que no celular. O que me leva ao segundo motivo: restrições de aplicativos da web por plataformas móveis hostis da Apple.

Fornecedores de plataformas móveis, como a Apple, são totalmente legais com aplicativos que usam seu telefone ao máximo. Acesse sua localização, reproduza áudio de fundo, obtenha suas coordenadas de GPS, reproduza mais de uma coisa por vez e muito mais.

A Apple está totalmente tranquila com isso.

Mas apenas se você pagar à Apple $ 99 / ano pelo privilégio.

Se você quiser fazer qualquer uma dessas coisas em um aplicativo da web antigo normal, bem, nossa, a Apple não vai apenas negar essas coisas, ela impede que você até mesmo peça permissão .

Para meu aplicativo reprodutor de música parecido com o Pandora, essa horrível destruição apareceu de várias maneiras.

De coisas menores como “iOS Safari não permite que você reproduza áudio sem primeiro interagir com a página” a coisas maiores e paralisantes como “iOS Safari não permite que você toque a próxima música se seu aplicativo estiver em segundo plano ou se sua tela estiver desligada. ”

Ah, além de anomalias visuais estranhas, como digitar em uma caixa de texto e ver seu texto aparecer em outro lugar na tela.

Então, para tornar meu aplicativo de música HTML5 realmente funcional e funcionando nos dispositivos móveis das pessoas, foi necessário transformar meu PWA em um aplicativo na app store.

Barreiras à entrada

No mundo ideal, publicar seu aplicativo da web nas lojas de aplicativos seria assim:

  • Seu host da Web / nuvem ou provedor de integração contínua
  • Você publicou um Progressive Web App. Publicar em lojas de aplicativos?

☑ iOS App Store

☑ Google Play

☑ Windows Store

(Ou, alternativamente, conforme a Microsoft está experimentando, seu PWA aparecerá automaticamente na loja de aplicativos conforme o Bing o rastreia.)

Mas, infelizmente, não vivemos neste mundo ideal. Em vez disso, temos que lidar com todos os tipos de BS nativa proprietária para colocar nossos aplicativos da web nas lojas.

Cada uma das lojas de aplicativos tem uma barreira de entrada: quão difícil é pegar um aplicativo da web existente e colocá-lo na loja de aplicativos.

Eu listo algumas das barreiras abaixo.

Custo

  • Apple : $ 99 / ano para ter seu aplicativo listado na loja de aplicativos iOS.
  • Google: Taxa única de $ 25 para listar seu aplicativo na Google Play Store.
  • Microsoft: Grátis!

Não me obrigue a pagar a você para disponibilizar meu aplicativo aos seus usuários. Meu aplicativo enriquece sua plataforma. Sem bons aplicativos, sua plataforma será abandonada.

A Apple costumava entender isso. Quando apresentou o iPhone pela primeira vez, Steve Jobs estava convencido de que o HTML5 era o futuro e que os aplicativos serão simplesmente aplicativos da web. Não havia SDK nativo do iPhone para terceiros. Desde então, a Apple abandonou essa visão.

O Google pediu uma taxa única simbólica de US $ 25. Provavelmente para evitar spammers e diminuir a entrada de aplicativos realmente inúteis na loja.

A Microsoft parece determinada a apenas aumentar o número total de aplicativos em sua loja de aplicativos, independentemente da qualidade.

Vencedor: Microsoft. É difícil vencer de graça.

Adicionando recursos nativos

Em um mundo ideal, eu não teria que escrever uma única linha extra de código para meu aplicativo da web se integrar ao sistema operacional. Ou, como Steve Jobs disse em 2007,

“O motor Safari completo está dentro do iPhone. E assim, você pode escrever incríveis aplicativos Web 2.0 e Ajax que se parecem exatamente e se comportam exatamente como os aplicativos do iPhone. E esses aplicativos podem se integrar perfeitamente com os serviços do iPhone. Eles podem fazer uma chamada, podem enviar um e-mail, podem procurar um local no Google Maps. ” -Steve Jobs, 2007

Para mim, isso significa que meu aplicativo da web reproduz áudio de fundo usando áudio HTML5 padrão; que funciona bem em todos os sistemas operacionais.

Meu aplicativo da web declara qual áudio está sendo reproduzido e os sistemas operacionais detectam isso, exibindo informações da música atualmente em reprodução na tela de bloqueio.

Meu aplicativo controla o áudio usando a API de áudio HTML5 padrão; o sistema operacional detecta isso e fornece controles de reprodução / pausa / próxima / volume / barra de controle na tela de bloqueio.

Mas, infelizmente, não vivemos neste mundo ideal. Todas as coisas listadas acima não funcionam totalmente fora da caixa em todas as 3 plataformas.

Meu aplicativo da web precisa reproduzir áudio em segundo plano. E carregue URLs do meu CDN. Parece razoável, certo? E bônus, que tal mostrar informações sobre a música que está tocando na tela de bloqueio? E controlar o áudio (reproduzir / pausar / avançar, etc.) na tela de bloqueio? Quão difícil é isso?

Três abordagens muito diferentes tomadas aqui:

  • Apple : Não oferecemos aos aplicativos da web uma maneira de declarar esses recursos; você precisará escrever um wrapper nativo (por exemplo, com Cordova) para interagir com o sistema operacional.
  • Google : Web FTW! Vamos criar um novo padrão da web que mostra áudio e controles da tela de bloqueio. Áudio de fundo? Claro vá em frente!
  • Microsoft: Vamos injetar nossa API proprietária, window.Windows. *, Em seu namespace global JavaScript e você pode usar isso para fazer as coisas que deseja fazer.

Entrando em mais detalhes aqui para cada loja:

Para a loja de aplicativos iOS, seu aplicativo da web precisa reproduzir áudio em segundo plano? Use um plugin Cordova. Precisa mostrar a música atualmente em reprodução na tela de bloqueio? Use um plugin Cordova. Precisa controlar a música que está tocando na tela de bloqueio? Use um plugin Cordova. Você entendeu a ideia. Basicamente, Cordova faz com que a Apple pense que você é um aplicativo nativo. E como você não é um aplicativo da web nojento, a Apple permite que você faça todas as coisas que os aplicativos nativos podem fazer. Você só precisa de truques nativos - plug-ins Cordova - para deixá-lo fazer isso.

Para o Google Play, é bom que eu possa apenas escrever código JS para fazer isso funcionar; nenhum plug-in Cordova necessário aqui. Claro, esse JS não funcionará em qualquer lugar exceto Chrome no Android ... mas hey, talvez um dia (em um mundo ideal!) Todos os navegadores móveis implementarão essas APIs da web ... e o mundo viverá como um só. Estou quase pronto para lançar algumas músicas utopias hippie de John Lennon.

Para a Windows Store, você deseja reproduzir o áudio de fundo? Desculpa! Isto é, a menos que você declare suas intenções em nosso arquivo de manifesto de recursos proprietários (fácil) E você implemente essa interface de mídia proprietária usando window.Windows.SystemMediaTransportControls (não é tão fácil). Caso contrário, silenciaremos você quando seu aplicativo entrar em segundo plano.

Vencedor : Google. Eu quero ser capaz de apenas escrever JavaScript e deixar o sistema operacional pegar dicas do meu aplicativo.

Vice-campeão : Windows. Ainda posso escrever JavaScript simples, mas preciso falar com uma API JS do Windows proprietária que foi injetada em meu processo durante a execução no Windows. Não é terrível.

Perdedor : Apple. Eles não se importam com aplicativos da web. Na verdade, é pior do que isso. Parece que eles são realmente hostis aos aplicativos da web. iOS Safari é o novo Internet Explorer 6. Ele ficou para trás em quase todos os padrões da web, especialmente em relação aos Progressive Web Apps. Provavelmente, por motivos de negócios: os aplicativos da web atrapalham sua raquete de compras de $ 99 / ano + 33% no aplicativo. Portanto, para fazer meu aplicativo da web funcionar na plataforma deles, basicamente tenho que fingir que sou um aplicativo nativo.

Registro na App Store

O envio de seu PWA para a loja de aplicativos requer registro, verificação comercial e mais burocracia. Veja como as 3 lojas de aplicativos se saíram:

  • Apple : Você deve provar que é uma empresa legal e registrada. Essa verificação não é feita por nós, mas por terceiros, que podem ou não saber sobre sua empresa.
  • Google : Você quer seu aplicativo em nossa loja? Legal por nós.
  • Microsoft : Você quer seu aplicativo em nossa loja? Legal por nós.

O maior problema para mim foi ser verificado como uma empresa legal pela Apple.

Primeiro, fui ao site e me registrei no Programa de Desenvolvedores da Apple. Preenchi meu nome e informações da empresa. (À parte: acho que a Apple não permitirá que você envie um aplicativo, a menos que você tenha uma empresa legal registrada?)

Eu clico próximo.

“As informações inseridas não correspondem ao seu perfil D&B.”

Meu o quê?

Um pouco de pesquisa no Google mostrou que o “perfil D&B” é Dun e Bradstreet. Nunca tinha ouvido falar desse grupo antes, mas descobri que a Apple os está usando para verificar os detalhes legais de sua empresa.

E, aparentemente, meu perfil D&B não correspondia ao que coloquei no meu registro do Apple Dev.

Procuro no Google um pouco mais e encontro os fóruns de desenvolvimento da Apple cheios de postagens semelhantes. Ninguém teve uma boa resposta.

Entro em contato com o suporte Apple Dev. 24 horas depois, sou contatado por e-mail dizendo que devo entrar em contato com a D&B.

Eu decido contatá-los ... mas a Apple diz que vai levar alguns dias para que eles respondam.

Neste ponto, estou pensando em abandonar toda a ideia.

Enquanto aguardo o retorno do suporte da D&B, decido ir ao site da D&B, verificar minha identidade e atualizar as informações da minha empresa que, suponho, eles retiraram dos registros do governo.

Eu mencionei como isso é horrível? Eu só quero listar meu aplicativo da web existente na loja. Plz help.

Vou à D&B para atualizar meu perfil de negócios. Surpresa! Eles têm um bug de JavaScript em sua lógica de validação que me impede de atualizar meu perfil.

Felizmente, sou um desenvolvedor proficiente. Eu clico em colocar um ponto de interrupção em seu JavaScript, clico em enviar, altero o sinalizador isValid para true e pronto! Eu atualizei meu perfil D&B.

De volta ao Apple Dev -> vamos tentar novamente. Cadastre minha empresa ...

“Erro: as informações inseridas não correspondem ao seu perfil D&B.”

ESTÁ VOCÊ ESTÁ ME LIGANDO.

Fale com a Apple novamente. “Oh, pode levar de 24 a 48 horas para que as informações atualizadas da D&B entrem em nosso sistema.”

Você sabe, porque as informações digitais podem levar 2 dias para viajar do servidor A para o servidor B. Sigh.

Dois dias depois, tento me inscrever ... finalmente funciona! Agora estou no programa Apple Developer e posso enviar aplicativos para análise.

Vencedor : Google e Microsoft; ambos levaram 5 minutos para se registrar.

Perdedor : o registro do desenvolvedor da Apple foi lento e doloroso. Demorou cerca de uma semana para realmente se registrar no programa de desenvolvedor. Isso exigiu que eu contatasse o suporte de 2 empresas diferentes. E isso exigiu que eu depurasse em tempo de execução o código JavaScript em um site de terceiros apenas para que pudesse superar sua validação do lado do cliente com erros, para que minhas informações fluíssem para a Apple, para que eu pudesse enviar meu aplicativo para a loja. Wow apenas wow.

Se há alguma graça salvadora aqui para a Apple, é que eles têm um programa 501c3 sem fins lucrativos, onde as organizações sem fins lucrativos podem ter sua taxa anual de $ 99 dispensada. Eu tirei vantagem disso. E talvez essa etapa extra complique as coisas.

Empacotamento, criação e envio de aplicativos

Depois de ter um aplicativo da web, você precisa executar um pouco de mágica nele para transformá-lo em algo que você possa enviar para análise na App Store.

  • Apple : primeiro, compre um Mac; você não pode construir um aplicativo iOS sem um Mac. Instale o XCode e essas ferramentas e estruturas de construção, adquira um certificado de nosso programa de desenvolvedor, crie um perfil em um site separado chamado iTunes Connect, vincule-o ao certificado gerado no Apple Dev Center e envie usando XCode. Fácil como um, dois, três ... trinta e sete ...
  • Google : Faça download do Android Studio, gere um certificado de segurança por meio dele e empacote-o usando o Studio. Faça upload do pacote no site do desenvolvedor Android.
  • Microsoft : Gere um pacote .appx usando essas ferramentas de linha de comando gratuitas ou Visual Studio. Faça upload para o site do Microsoft Dev Center.

A boa notícia é que existe uma ferramenta gratuita para fazer a mágica de transformar seu aplicativo da web em pacotes de aplicativos . Essa incrível ferramenta gratuita é chamada PWABuilder. Ele analisa um URL, informa o que você precisa fazer (por exemplo, talvez adicionar alguns ícones da tela inicial ao seu manifesto da Web do PWA). E em um assistente de 3 etapas, ele permite que você baixe pacotes que contêm toda a magia:

  • Para Windows, ele realmente gera o pacote .appx. Você pode literalmente pegar isso e enviá-lo no site do Windows Dev Center.
  • Para o Google, ele gera um aplicativo Java wrapper que contém seu aplicativo da web PWA. No Android Studio, você constrói esse projeto, que gera o pacote Android que pode ser carregado no site Android Dev Center.
  • Para a Apple, ele gera um projeto XCode que pode ser construído com XCode. O que requer um Mac.

Mais uma vez, a Apple foi a mais dolorosa de todas essas. Eu não tenho um Mac. Mas você não pode construir o projeto XCode para seu PWA sem um Mac.

Não quero pagar vários milhares de dólares para publicar meu aplicativo gratuito na loja de aplicativos da Apple. Não quero pagar pelo privilégio de enriquecer a plataforma iOS da Apple.

Felizmente, o MacInCloud custa cerca de US $ 25 / mês e eles fornecem uma máquina Mac com o XCode já instalado. Você pode acessar remotamente usando a Área de Trabalho Remota do Windows ou até mesmo por meio de uma interface da web.

Não foi suficiente apenas construir o projeto XCode e enviar. Tive de gerar um certificado de segurança no site do desenvolvedor da Apple e, em seguida, criar um novo perfil de aplicativo em um site separado, iTunes Connect, onde você realmente envia o pacote.

E não foi só: como a Apple é hostil aos aplicativos da web, tive que instalar alguns frameworks especiais e adicionar plug-ins Cordova que permitem que meu aplicativo faça coisas como reproduzir áudio em segundo plano, adicionar a música atual à tela de bloqueio, controlar o volume da música e o status de reprodução na tela de bloqueio e muito mais.

Levei pelo menos uma semana de esforços para que meu aplicativo funcionasse antes que eu pudesse enviá-lo à loja de aplicativos.

Vencedor : Microsoft. Imagine o seguinte: você pode ir a um site que gera um pacote de aplicativo para seu aplicativo da web. E se isso não for seu, você pode baixar ferramentas de linha de comando que farão o trabalho. Pessoa GUI? O Visual Studio gratuito funcionará.

Vice-campeão : Google. Requer o Android Studio, mas é grátis, executa todos e era bastante simples.

Perdedor : Apple. Eu não deveria ter que comprar um computador proprietário - um Mac de vários milhares de dólares - para construir meu aplicativo. O Apple Dev Center -> O emaranhado do iTunes Connect parece uma tentativa de um gerente fora do alcance de empurrar o iTunes para os desenvolvedores. Deve simplesmente fazer parte do site Apple Developer Center.

Teste de aplicativos

Depois de finalmente fazer todos os encantamentos mágicos para transformar seu aplicativo da web existente em um pacote de aplicativo móvel, você provavelmente desejará enviá-lo aos testadores antes de lançar seu aplicativo nas massas não lavadas.

  • Apple : para testar, peça aos testadores que instalem o Test Flight em seus dispositivos iOS. Em seguida, você adiciona o e-mail do testador no iTunes Connect. O testador receberá uma notificação e pode testar seu aplicativo antes de estar disponível na app store.
  • Google : no Android Dev Center, você adiciona endereços de e-mail de testadores. Depois de adicionados, eles podem ver sua versão alfa / beta na App Store.
  • Microsoft : Eu realmente não usei isso, então não vou comentar sobre isso.

Vencedor : Jogue fora. O aplicativo Test Flight da Apple é simples e otimizado. Você pode controlar a expiração alfa / beta simplesmente no lado do administrador. O Google não estava muito atrás; foi bastante indolor, nem mesmo exigindo um aplicativo separado.

Avaliação do aplicativo

Quando seu aplicativo estiver pronto para o horário nobre, você o envia para revisão. A revisão é feita usando uma lista de verificação programática (por exemplo, você tem um ícone de inicialização?) E por pessoas reais (“seu aplicativo é um clone do X, nós o rejeitamos”)

  • Apple : Antes do envio, o XCode avisa sobre possíveis problemas durante a compilação. A revisão humana do aplicativo leva cerca de 24 a 48 horas.
  • Google : tem alguém em casa? O Android Studio não me informou sobre nenhum problema em potencial e meu aplicativo foi aprovado minutos após o envio. Eu não acho que um ser humano de verdade olhou para o meu aplicativo.
  • Microsoft : Após o envio, uma revisão programática rápida detectou um problema relacionado a formatos de ícone incorretos. Depois de passar, um humano revisou meu aplicativo em 4 dias.

Vencedor : Apple.

Claro, como desenvolvedor, gosto do fato de que meu aplicativo foi instantaneamente na Google Play Store. Mas isso só porque, eu suspeito, não foi realmente revisado por um humano.

A Apple teve o tempo de resposta mais rápido para uma revisão humana real. As atualizações também foram aprovadas na revisão em 24 horas.

A Microsoft foi um sucesso ou um fracasso aqui. A revisão inicial demorou 3 ou 4 dias. Uma atualização posterior levou 24 horas. Em seguida, outra atualização, onde adicionei a plataforma XBox, levou mais 3 a 4 dias.

Conclusão

É doloroso e custa dinheiro pegar um PWA existente e torná-lo funcional em plataformas móveis e listado na App Store.

Vencedor : Google. Eles tornaram mais fácil entrar na app store. Isso tornou mais fácil a integração com a plataforma nativa, tentando padronizar APIs da web que as plataformas do sistema operacional podem pegar (olá, adorável navigator.mediaSession)

Vice-campeão : Microsoft. Eles tornaram mais fácil polvilhar seu aplicativo da web com magia, transformando-o em um pacote que pode ser enviado à loja deles. (Pode ser feito gratuitamente usando o site PWABuilder!) A integração com sua plataforma significa usar o namespace window.Windows. * JavaScript injetado automaticamente. Não é ruim.

Perdedor : Apple. Não exija que eu compre um Mac para construir um aplicativo iOS. Não me force a usar wrappers nativos para integração com sua plataforma. Não exija que eu mexa com certificados de segurança; deixe suas ferramentas de construção criá-los para mim e armazene-os automaticamente na minha conta do Dev Center. Não me obrigue a usar 2 sites diferentes: Apple Dev Center e iTunes Connect.

Considerações finais: A web sempre vence. Ele derrotou o Flash. Isso matou Silverlight. Ele destruiu aplicativos nativos no desktop. O navegador é a plataforma rich client. O sistema operacional é apenas um iniciador de navegador e comunicador de hardware.

A web também vencerá no celular. Os desenvolvedores não querem construir três aplicativos separados para as plataformas principais. As empresas não querem pagar pelo desenvolvimento de 3 aplicativos.

A resposta para tudo isso é a web. Podemos construir aplicativos da web ricos - Progressive Web Apps - e empacotá-los para todas as lojas de aplicativos.

A Apple, em particular, tem um incentivo perverso para impedir o progresso da web. É o mesmo incentivo que a Microsoft teve no final dos anos 90 e início dos anos 2000: ela quer ser a plataforma para bons aplicativos. Os PWAs minam isso; eles correm em todos os lugares.

Minha sabedoria de software é esta: os PWAs irão eventualmente vencer e ultrapassar os aplicativos móveis nativos. Em 5 a 10 anos, os aplicativos iOS nativos serão tão comuns quanto os aplicativos Win32 C. A Apple vai chutar e gritar, mantendo o iOS Safari atrás da curva, bloqueando o progresso do PWA onde eles podem. (Até mesmo o “suporte” recente para PWAs no iOS Safari 11.1 na verdade prejudica os PWAs.)

Minha sugestão para plataformas de aplicativos móveis é abraçar o inevitável e adicionar automaticamente PWAs de qualidade à sua loja de aplicativos ou permitir que os desenvolvedores facilmente (por exemplo, gratuitamente e com 3 cliques ou menos) enviem um PWA para sua loja.

Leitores, espero que tenha sido útil dar uma olhada nos PWAs nas App Stores em 2018.

Você enviou um PWA para uma loja de aplicativos? Eu adoraria ouvir sua experiência na seção de comentários. E você pode ler mais postagens do meu blog no meu blog.