O debate sobre apps para dispositivos móveis
Introdução
Os apps para dispositivos móveis e o HTML5 são duas das tecnologias mais populares no momento, e há muita sobreposição. Os apps da Web são executados em navegadores para dispositivos móveis e também podem ser reempacotados como apps nativos nas várias plataformas móveis. Com a grande variedade de plataformas com suporte, combinada com o poder dos navegadores para dispositivos móveis, os desenvolvedores estão recorrendo ao HTML5 como uma solução "escreva uma vez, execute muitas". Mas será que é realmente viável? Ainda há motivos convincentes para usar apps nativos, e muitos desenvolvedores estão seguindo esse caminho. Este artigo é um debate sobre nativo versus a Web.
Riqueza de recursos
Ponto: o nativo pode fazer mais
Podemos dividir a funcionalidade para dispositivos móveis em duas dimensões: a experiência do próprio app e a maneira como ele se conecta ao ecossistema do dispositivo. Por exemplo, no Android, seriam recursos como widgets e notificações. O nativo se destaca em ambas as dimensões.
Em termos de experiência do app, os apps nativos podem fazer mais. Eles podem receber eventos de deslize, até mesmo multitoque, para plataformas que oferecem suporte a isso. Eles normalmente podem agir em teclas físicas pressionadas, como o botão de pesquisa e os controles de volume do Android. Eles também podem acessar hardware, como GPS e câmera. Com a permissão do usuário, algumas plataformas oferecem acesso irrestrito ao sistema operacional. Tente detectar quanta bateria resta com HTML5.
No entanto, é mais do que a experiência no app. Um sistema operacional como o Android oferece diferentes maneiras para os apps interagirem com os usuários e, de fato, com outros apps. Você tem widgets ativos na página inicial. Você tem notificações que aparecem na barra de status do dispositivo. E você tem intents, que permitem que seu app se anuncie como fornecedor de um serviço geral que outros apps podem exigir ocasionalmente.
Contra-argumento: os recursos nativos podem ser aumentados, e a Web está alcançando
É verdade que muitos recursos no app estão simplesmente fora do alcance de um app HTML5. Não importa o quão boas sejam suas habilidades de web-fu, se o app estiver preso em uma caixa de areia sem uma API de câmera, ele não vai tirar fotos tão cedo. Felizmente, você não precisa estar nessa caixa de areia. Se você realmente precisar que seu app da Web tire uma foto, crie um app nativo, um com uma visualização da Web incorporada que forneça a maior parte da interface do usuário. É assim que a estrutura de código aberto do PhoneGap funciona: ela preenche a lacuna expondo recursos nativos como serviços da Web, que a visualização da Web chama usando uma API de rede padrão. Ao criar um app híbrido como esse, você também pode se conectar a recursos de plataforma como widgets, notificações e intents.
Criar um app híbrido (nativo e da Web) não é uma solução ideal. Ele adiciona complexidade e se aplica apenas a apps da Web empacotados como apps nativos, em vez de sites tradicionais acessados em um navegador para dispositivos móveis. Mas isso pode não ser necessário por muito tempo. Os padrões da Web estão evoluindo rapidamente, e os navegadores modernos para dispositivos móveis estão acompanhando o ritmo. O armazenamento off-line, a geolocalização, os gráficos de tela e a reprodução de vídeo/áudio têm suporte generalizado entre os smartphones modernos, por exemplo. Até mesmo a câmera está começando a ser compatível. No Android 3.1, é possível capturar fotos e vídeos usando padrões da Web. E o navegador iOS mais recente oferece suporte ao WebSocket para streaming bidirecional, bem como detecção de orientação do dispositivo.
No geral, os dispositivos móveis estão evoluindo. Mas a Web também está evoluindo, e rápido. Somente entre os navegadores para computadores, há cinco principais fornecedores de navegadores que evoluem os padrões e adicionam recursos em um ritmo acelerado. Embora não seja um processo trivial para portar esses recursos para dispositivos móveis, muitos deles já chegaram aos navegadores para dispositivos móveis.
O nativo é um alvo em movimento rápido, mas a Web está diminuindo a lacuna.
Desempenho
Ponto: o nativo é executado mais rápido
Os apps nativos não têm a barreira de tempo de execução da Web. Eles são executados perto do hardware e podem aproveitar os recursos de desempenho, como aceleração de GPU e multithreading.
Contra-argumento: os tempos de execução da Web são muito mais rápidos hoje em dia, e a maioria dos apps não precisa da velocidade
Seria um eufemismo dizer que a Web ficou mais rápida nos últimos anos. O V8, o mecanismo JavaScript que acompanha o Chrome, foi um grande desenvolvimento no desempenho da Web quando foi lançado e, desde então, só ficou mais rápido:
Os mecanismos de renderização gráfica também aceleraram a Web, e agora a aceleração de hardware está começando a acontecer. Confira o aumento de velocidade fornecido pela tela acelerada por hardware:
Além disso, a nova API Web Workers possibilita o multithreading, e os desenvolvedores da Web modernos também podem usar uma variedade de bibliotecas otimizadas para desempenho e técnicas de otimização de desempenho bem pesquisadas. Embora a maioria delas tenha começado na Web para computadores, elas ainda são relevantes para dispositivos móveis, e há maior atenção aos dispositivos móveis. Por exemplo, o guru de desempenho Steve Souders tem uma página dedicada a ferramentas de desempenho para dispositivos móveis.
Nem todos os avanços para computadores chegaram a todas as plataformas para dispositivos móveis, mas as tendências indicam que estão a caminho. Também é importante observar que a maioria dos apps para dispositivos móveis não são jogos 3D de ponta, mas são fundamentalmente baseados em informações: notícias, e-mails, horários, redes sociais etc. Acesse alguns sites no seu dispositivo móvel, por exemplo, Gmail, Amazon, Twitter, e você poderá confirmar que o desempenho da Web para dispositivos móveis é mais do que adequado. Quanto aos jogos, os básicos já são viáveis com a tela 2D, e o WebGL está começando a aparecer em dispositivos móveis. Consulte o Firefox 4. Até que seja generalizado, há uma família crescente de estruturas que compilam apps WebGL para apps nativos que podem aproveitar o OpenGL, por exemplo, o ImpactJS.
Experiência do desenvolvedor
Ponto: o nativo é mais fácil de desenvolver
Os apps nativos usam linguagens de programação robustas (por exemplo, Java, Objective C, C++) que foram projetadas para o desenvolvimento de aplicativos complexos e têm um histórico comprovado. As APIs foram projetadas do zero para oferecer suporte à plataforma em questão. É possível depurar apps facilmente em emuladores de computador que fornecem uma representação próxima do dispositivo de destino.
O que torna o desenvolvimento da Web particularmente problemático é a enorme diversidade de navegadores e tempos de execução. Quando o app é executado, não há garantia de que o recurso X estará disponível. E mesmo que esteja, como o navegador vai implementá-lo? Os padrões estão abertos à interpretação.
Contra-argumento: a Web geralmente é mais fácil de desenvolver, especialmente se o destino for vários dispositivos
Vamos abordar primeiro a tecnologia principal. É verdade que os padrões da Web foram originalmente concebidos em uma época em que a Web era fundamentalmente sobre documentos, não apps, com JavaScript criado e implantado em apenas 10 dias. Mas eles se mostraram muito mais capazes do que o imaginado. Os desenvolvedores da Web aprenderam a aproveitar as partes boas e a controlar as partes ruins, com padrões agora compreendidos para design escalonável. Além disso, os padrões não estão parados, e esforços como HTML5, CSS3 e EcmaScript Harmony estão melhorando a experiência do desenvolvedor. Se você prefere C++, Java ou JavaScript é uma questão de debate religioso e também depende da sua base de código legada. Mas certamente podemos incluir o JavaScript como um concorrente sério atualmente.
O outro lado da fragmentação do navegador/tempo de execução é o fato de que todos esses ambientes existem em primeiro lugar. Desenvolva um app Android em Java e você terá uma porta completa para o Objective C para oferecer suporte ao iOS. Desenvolva um app da Web uma vez e ele será executado no Android e no iOS, sem mencionar o WebOS, o BlackBerry, o Windows Mobile e… bem, essa é a teoria. Na prática, você precisará ajustar as coisas para cada plataforma se realmente quiser ter a experiência certa. Mas você também teria que fazer isso no nativo, para a maioria dos sistemas operacionais para dispositivos móveis. Há versões e dispositivos diferentes.
A boa notícia é que a "fragmentação" sempre foi assim na Web, e há técnicas conhecidas para lidar com ela. Mais importante ainda, o princípio do aprimoramento progressivo incentiva os desenvolvedores a segmentar um dispositivo básico primeiro e adicionar camadas de recursos específicos da plataforma quando disponíveis. O mantra da detecção de recursos também ajuda e, atualmente, temos suporte de biblioteca de empresas como a Modernizr para oferecer suporte ao design responsivo da Web. Com o uso criterioso dessas técnicas, você pode expandir seu alcance para a grande maioria dos dispositivos, até mesmo "feature phones" antigos, até mesmo formatos como relógios e TVs, independentemente da marca e do SO. Confira nossa demonstração de várias interfaces no Google I/O 2011, em que segmentamos formatos distintos (telefone básico, smartphone, tablet, computador, TV) com uma base de código comum de lógica e marcação.
Aparência
Ponto: o nativo se ajusta à aparência da plataforma
Um dos recursos definidores de qualquer plataforma é a aparência. Os usuários esperam que os controles sejam apresentados de forma consistente e manipulados da mesma maneira. Há certas expressões idiomáticas que variam de plataforma para plataforma, por exemplo, o que acontece quando o usuário realiza uma "pressão longa" (mantém um elemento pressionado por vários segundos)? As plataformas têm expressões idiomáticas padrão para essas coisas, e não é possível satisfazer todas elas com um único app HTML5.
Além disso, a aparência da plataforma é orquestrada pela biblioteca de software nativa da plataforma, cujos widgets encapsulam o tipo de aparência que os usuários esperam. Você recebe muito da aparência esperada "sem custo financeiro" apenas usando o kit de ferramentas nativo.
Contra-argumento: a Web tem sua própria aparência, e você também pode personalizar a interface da Web para as plataformas mais importantes
Conforme explicado na seção anterior, a maneira de desenvolvimento da Web é escrever uma versão básica "tamanho único" e, em seguida, aprimorá-la progressivamente. Embora o aprimoramento seja normalmente baseado em recursos, você também pode aprimorá-lo segmentando as plataformas mais importantes. Esse é um tipo de "detecção de navegador", que às vezes é mal visto pela comunidade da Web, principalmente porque há muitos navegadores possíveis. Mas se você visualizar duas ou três plataformas com uma prioridade muito alta e estiver disposto a fazer um esforço extra para se destacar em relação às alternativas nativas, esse pode ser o caminho a seguir.
Quanto à versão de linha de base, a Web tem sua própria aparência, e podemos até dizer que cada plataforma para dispositivos móveis tem sua própria "aparência da Web" estabelecida pelo navegador padrão e pelo tempo de execução da Web. A "aparência da Web" pode ser adequada para seus usuários e, na verdade, permite que você alcance um maior grau de consistência com a experiência de navegação para computadores, bem como em outros dispositivos que o usuário possa estar usando. Além disso, há muitos apps bem-sucedidos que não oferecem suporte à aparência nativa. Isso certamente é verdade para jogos (seu jogo favorito para dispositivos móveis segue a aparência do SO para dispositivos móveis?) e até mesmo para apps mais convencionais. Por exemplo, confira os clientes nativos mais populares do Twitter na plataforma de sua preferência e você verá uma ampla variedade de mecanismos de interface do usuário em funcionamento.
Facilidade de ser descoberto
Ponto: os apps nativos são mais fáceis de descobrir
Os mecanismos de distribuição de apps, como o Market do Android e a App Store da Apple, têm sido extremamente populares nos últimos anos e são uma das principais forças motrizes de todo o setor de dispositivos móveis. Qualquer desenvolvedor pode enviar o app nativo para o marketplace, em que os usuários podem descobri-lo por meio de uma combinação de navegação, pesquisa e recomendações. Além disso, se você fez seu trabalho corretamente, as classificações e os comentários positivos vão convencer os usuários a clicar no botão de instalação.
Contra-argumento: na verdade, os apps da Web são mais fáceis de descobrir
A Web é, sem dúvida, o meio mais fácil de descobrir já criado. No humilde URL, temos (pelo menos em teoria) um identificador exclusivo para tudo o que já foi publicado na Web, incluindo apps publicados em sites padrão. Os mecanismos de pesquisa facilitam a descoberta desse conteúdo, e outros sites podem criar links para ele, incluindo catálogos de apps da Web semelhantes a marketplaces para dispositivos móveis. Na verdade, qualquer pessoa pode compartilhar apps da Web com os amigos apenas criando um link para eles em e-mails e mensagens de redes sociais. Os links também podem ser enviados por SMS, em que os usuários de dispositivos móveis podem clicar no link e iniciar o app no navegador do dispositivo.
Ainda não temos os mesmos marketplaces em que os usuários podem classificar e comentar apps, mas isso também está mudando. Continue lendo…
Monetização
Ponto: o nativo pode ser monetizado
"Criança de 6 anos cria app durante o horário de almoço e vende um zilhão de cópias a US $3 cada". Você vê essa manchete com frequência hoje em dia, então não é de admirar que desenvolvedores grandes e pequenos estejam procurando os marketplaces para dispositivos móveis para monetização. As plataformas para dispositivos móveis oferecem várias maneiras para os desenvolvedores cobrarem diretamente pelos apps. A mais simples é o pagamento único para desbloquear o app para sempre. Também há mecanismos de pagamento e assinatura no app oferecidos em algumas plataformas, e eles são integrados de forma consistente e segura. Essas novas formas de pagamento permitem que os desenvolvedores convertam um app de sucesso em um fluxo de receita de longo prazo.
Além dos pagamentos de apps, você pode monetizar com modelos tradicionais da Web, como publicidade e patrocínio.
Contra-argumento: sempre foi possível monetizar na Web, e as oportunidades estão crescendo
A Web não seria o motor da indústria moderna se não houvesse muitas oportunidades de ganhar dinheiro. Embora os mecanismos diretos de "pagamento por uso" ainda não tenham prosperado, há vários nichos em que as soluções de "software como serviço" baseadas em assinatura se tornaram viáveis. Os exemplos incluem o Google Apps, a linha de produtos da 37Signals e versões premium de vários serviços de e-mail. Além disso, os pagamentos diretos não são a única maneira de lucrar com apps da Web. Há publicidade on-line, links de afiliados, patrocínios, promoção cruzada para outros produtos e serviços.
Dito isso, é perfeitamente razoável que um desenvolvedor da Web leia as manchetes e sinta um pouco de inveja de pagamento. Não é possível enviar um URL da Web para os marketplaces nativos. O que um desenvolvedor da Web pode fazer? O que você faz é criar um "app wrapper" nativo. Para cada plataforma que você quer segmentar, crie um app nativo vazio que contenha apenas uma visualização da Web. A visualização da Web é onde você incorpora o app real. Em seguida, basta enviar esses apps para os vários marketplaces (e, com sorte, assistir o dinheiro entrar!). Provavelmente há centenas, senão milhares, de apps com tecnologia da Web nos principais marketplaces hoje em dia, alguns deles tão habilmente assimilados que nem sequer conhecemos os apps da Web.
A desvantagem é o ônus da compilação cruzada para cada plataforma. É aqui que uma estrutura existente, como o PhoneGap, pode ajudar. Melhor ainda, há serviços da Web como o PhoneGap Build e o Apparatio em desenvolvimento. Aponte esses sites para seu repositório de código, e um app Android, um app iOS e assim por diante… estarão prontos para você enviar às respectivas lojas. Não é necessário instalar SDKs nativos na sua máquina. Tudo o que você precisa para criar todos esses apps nativos é um editor de código e um navegador da Web.
Os marketplaces vão oferecer suporte a apps da Web diretamente, sem toda a sobrecarga de envolvê-los nativamente? Ainda não está claro. Sabemos que o Google lançou a Chrome Web Store no ano passado e, embora ela se aplique apenas ao computador, a loja despertou o interesse de outros fornecedores de navegadores e, no geral, faz parte de uma tendência em direção a catálogos de apps da Web, incluindo algumas tentativas específicas para dispositivos móveis. Ainda é cedo para o conceito de uma loja da Web, mas os sinais são promissores.
Conclusões
Seria bom declarar um vencedor aqui, mas, no momento, não há um vencedor claro. Alguns apps são mais adequados para nativos e outros para a Web. A pilha da Web tem mais impulso, mas, em termos de recursos e qualidades de execução, os apps nativos também estão avançando rapidamente. E, a menos que chegue um momento em que as tecnologias da Web sejam um cidadão de primeira classe na maioria dos SOs para dispositivos móveis, o nativo sempre será uma consideração importante.
Uma técnica mencionada neste artigo são os apps híbridos, e esse pode ser o melhor compromisso para alguns desenvolvedores: visualização da Web onde for possível e componentes nativos específicos da plataforma onde não for.
Se você escolher o caminho da Web, fique atento aos padrões da Web e ao princípio do aprimoramento progressivo. A Web é uma tecnologia que sabe como segmentar as multidões de dispositivos e sistemas operacionais. Se você optar por chamar de "fragmentação" ou "diversidade", a Web a abraça, e os desenvolvedores podem se beneficiar de toda a anterioridade.