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 usadas atualmente, e há muita sobreposição entre elas. 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 ampla gama de plataformas compatíveis, combinada com o poder dos navegadores para dispositivos móveis, os desenvolvedores estão recorrendo ao HTML5 como uma solução de "escrever uma vez, executar muitas". Mas será que isso é viável? Ainda há motivos convincentes para usar o desenvolvimento nativo e, claramente, muitos desenvolvedores estão seguindo esse caminho. Este artigo é um debate sobre nativo versus 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 app em si e a forma como ele se conecta ao ecossistema do dispositivo. Por exemplo, no Android, isso inclui recursos como widgets e notificações. Os nativos se destacam em ambas as dimensões.
Em termos de experiência no app, os apps nativos podem fazer mais. Eles podem facilmente acessar eventos de deslizar, até mesmo multitoque, para as plataformas que oferecem suporte. Normalmente, eles podem agir quando teclas físicas são pressionadas, como o botão de pesquisa e os controles de volume do Android. Eles também podem acessar o hardware, como o GPS e a câmera. E, com a permissão do usuário, algumas plataformas oferecem acesso irrestrito ao sistema operacional. Tente detectar quanta bateria resta com o HTML5!
Mas não é só a experiência no app. Um sistema operacional como o Android oferece diferentes maneiras para os apps interagirem com os usuários e 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 um serviço geral que outros apps podem exigir em algumas ocasiões.
Contraponto: os recursos nativos podem ser ampliados, e a Web está se atualizando de qualquer maneira
É verdade que muitos recursos no app estão simplesmente fora do alcance de um app HTML5. Não importa o quanto suas habilidades de web-fu sejam boas, se o app estiver preso em um sandbox sem API de câmera, ele não vai tirar fotos tão cedo. Felizmente, você não precisa estar nesse sandbox. Se você realmente precisa que seu app da Web tire uma foto, pode criar um app nativo com uma visualização da Web incorporada que forneça a maior parte da interface do usuário. É assim que o framework de código aberto PhoneGap funciona: ele 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 da plataforma, como widgets, notificações e intents.
Criar um app híbrido (nativo e da Web) não é a solução ideal. Isso adiciona complexidade e se aplica apenas a apps da Web encapsulados como apps nativos, em vez de sites tradicionais acessados em um navegador para dispositivos móveis. Mas talvez não seja necessário por muito tempo. Os padrões da Web estão evoluindo rapidamente, e os navegadores para dispositivos móveis modernos estão acompanhando o ritmo. Por exemplo, armazenamento off-line, geolocalização, gráficos de tela e reprodução de vídeo/áudio são amplamente compatíveis com smartphones modernos. Até mesmo a câmera está começando a ser compatível. No Android 3.1, é possível tirar fotos e gravar vídeos usando padrões da Web. E o navegador iOS mais recente oferece suporte ao WebSocket para streaming bidirecional, além de 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 computador, há cinco grandes fornecedores que estão evoluindo os padrões e adicionando recursos em um ritmo acelerado. Embora não seja um processo trivial portar esses recursos para dispositivos móveis, muitos deles já foram incorporados aos navegadores para dispositivos móveis.
O desenvolvimento nativo é um alvo em constante movimento, mas a Web está diminuindo a distância.
Desempenho
Ponto: o nativo é mais rápido
Os apps nativos não têm a barreira do ambiente de execução da Web para lidar. Eles são executados perto do metal e podem aproveitar os impulsionadores de desempenho, como aceleração de GPU e multithreading.
Contraponto: os ambientes de execução da Web são muito mais rápidos hoje, e a maioria dos apps não precisa dessa velocidade de qualquer maneira
Dizer que a Web ficou mais rápida nos últimos anos seria um eufemismo. 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 proporcionado pela tela acelerada por hardware:
Além disso, a nova API Web Workers possibilita o multithreading, e os desenvolvedores 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 deles tenha começado na Web para computadores, eles ainda são relevantes para dispositivos móveis, e há uma atenção maior voltada para 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 móveis, mas as tendências indicam que eles estão a caminho. Também é importante observar que a maioria dos apps para dispositivos móveis não são jogos 3D de última geração, mas fundamentalmente baseados em informações: notícias, e-mails, horários, redes sociais etc. Acesse alguns sites no seu dispositivo móvel, como 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 o canvas 2D, e o WebGL está começando a aparecer em dispositivos móveis. Confira o Firefox 4. Até que ele seja amplamente usado, há uma família crescente de frameworks que compilam apps WebGL em apps nativos que podem aproveitar o OpenGL, por exemplo, o ImpactJS.
Experiência do desenvolvedor
Ponto: o desenvolvimento nativo é mais fácil
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. É fácil depurar apps em emuladores de computador que oferecem uma representação aproximada do dispositivo de destino.
O que torna o desenvolvimento da Web particularmente problemático é a enorme diversidade de navegadores e ambientes de execução. Quando o app é executado, não há garantia de que o recurso X estará disponível. E mesmo que seja, como o navegador vai implementar isso? Os padrões estão abertos a interpretações.
Contraponto: a Web costuma ser mais fácil de desenvolver, especialmente se o público-alvo usa vários dispositivos
Vamos começar com 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 o JavaScript criado e implantado em apenas 10 dias. Mas elas se mostraram muito mais capazes do que o imaginado. Os desenvolvedores Web aprenderam a aproveitar as partes boas e domar as ruins, com padrões agora compreendidos para um 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. A preferência por C++, Java ou JavaScript é uma questão de debate religioso e também depende da sua base de código legada. Mas hoje em dia, o JavaScript é um forte concorrente.
O outro lado da fragmentação de navegadores/ambientes de execução é o fato de que todos esses ambientes existem. Desenvolva um app Android em Java e você vai precisar fazer uma portabilidade completa para 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 quiser que a experiência seja realmente boa. Mas você também teria que fazer isso em nativo, para a maioria dos sistemas operacionais móveis, já que existem 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. O mais importante é que 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 onde estiverem disponíveis. O mantra da detecção de recursos também ajuda, e hoje em dia temos suporte de bibliotecas como o Modernizr para dar suporte ao Web design responsivo. Com o uso criterioso dessas técnicas, é possível ampliar seu alcance para a grande maioria dos dispositivos, até mesmo "telefones básicos" antigos, formatos como relógios e TVs, independentemente da marca e do SO. Assista à nossa demonstração de várias interfaces no Google I/O 2011, em que segmentamos diferentes formatos (telefone básico, smartphone, tablet, computador, TV) com uma base de código comum de lógica e marcação.
Aparência
Ponto: o formato nativo se adapta à aparência da plataforma
Uma das características que definem qualquer plataforma é a aparência. Os usuários esperam que os controles sejam apresentados de forma consistente e manipulados da mesma maneira. Existem certas expressões idiomáticas que variam de plataforma para plataforma, por exemplo, o que acontece quando o usuário realiza um "toque longo" (mantém o toque em um elemento por vários segundos)? As plataformas têm expressões padrão para essas coisas, e não é possível atender a todas elas com um único app HTML5.
Além disso, a aparência da plataforma é orquestrada pela biblioteca de software nativa da plataforma, com widgets que 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.
Contraponto: a Web tem uma aparência própria, e você também pode personalizar a interface da Web para as plataformas mais importantes para você.
Como explicado na seção anterior, o desenvolvimento web consiste em escrever uma versão básica "universal" e, em seguida, aprimorá-la progressivamente. Embora a melhoria geralmente seja baseada em recursos, você também pode melhorar o app segmentando as plataformas mais importantes para você. Esse é um tipo de "detecção de navegador", que às vezes é mal vista pela comunidade da Web, principalmente porque existem muitos navegadores possíveis. Mas se você tem duas ou três plataformas com prioridade muito alta e quer fazer um esforço extra para competir com as alternativas nativas, essa pode ser a melhor opção.
Quanto à versão de referência, a Web tem uma aparência própria, e podemos até dizer que cada plataforma para dispositivos móveis tem uma "aparência da Web" estabelecida pelo navegador padrão e pelo ambiente 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 em navegadores para computador, bem como em outros dispositivos em que o usuário possa estar trabalhando. Além disso, há muitos apps de sucesso que não dão suporte à aparência nativa. Isso é 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 conhecidos do Twitter na plataforma de sua escolha e você verá uma ampla variedade de mecanismos de interface do usuário em funcionamento.
Detectabilidade
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 grande força motriz para todo o setor de dispositivos móveis. Qualquer desenvolvedor pode enviar o app nativo para o marketplace, onde os usuários podem descobri-lo por meio de uma combinação de navegação, pesquisa e recomendações. Além disso, se você tiver feito seu trabalho corretamente, as avaliações e os comentários positivos vão convencer os usuários a clicar no botão de instalação, que é o mais importante.
Contraponto: na verdade, os apps da Web são mais fáceis de descobrir
A Web é, sem dúvida, o meio mais detectável já criado. No URL simples, 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 aos marketplaces para dispositivos móveis. Na verdade, qualquer pessoa pode compartilhar apps da Web com os amigos, basta enviar o link por e-mail 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 avaliar e comentar sobre os apps, mas isso também está mudando. Continue lendo…
Monetização
Ponto: o formato nativo pode ser monetizado
"Criança de 6 anos cria app durante o almoço e vende um milhão de cópias por US $3 cada". Essa manchete é muito comum hoje em dia, então não é surpresa que desenvolvedores de todos os portes estejam buscando monetização nos mercados de dispositivos móveis. As plataformas para dispositivos móveis oferecem várias maneiras de os desenvolvedores cobrarem diretamente pelos apps. A mais simples é o pagamento único, para desbloquear o app para sempre. Também há mecanismos de pagamento integrado ao aplicativo e assinatura em algumas plataformas, que são totalmente integrados em um mecanismo consistente e seguro. Essas novas formas de pagamento permitem que os desenvolvedores transformem um app de sucesso em um fluxo de receita de longo prazo.
Além dos pagamentos no app, é possível gerar receita com modelos tradicionais da Web, como publicidade e patrocínio.
Contraponto: 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 amplas oportunidades de ganhar dinheiro. Embora os mecanismos diretos de "pagamento por uso" ainda não tenham se desenvolvido, há vários nichos em que as soluções de "software como serviço" baseadas em assinatura se tornaram viáveis. Exemplos incluem o Google Apps, a gama 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 web leia as manchetes e sinta uma pontinha de inveja. Não é possível enviar um URL da Web para os marketplaces nativos. Então, o que um desenvolvedor web deve fazer? O que você faz é criar um "app wrapper" nativo: para cada plataforma que você quer segmentar, crie um app nativo vazio que simplesmente contenha 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, ver o dinheiro entrar!). Provavelmente, existem centenas, se não milhares, de apps baseados na Web nos principais mercados atualmente, alguns deles tão bem assimilados que nem sabemos que são apps da Web.
A desvantagem é o ônus da compilação cruzada para cada plataforma. É aqui que um framework 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 etc. vão aparecer, prontos para você enviar às respectivas lojas. Não é preciso instalar SDKs nativos na sua máquina. Para criar todos esses apps nativos, você só precisa de um editor de código e um navegador da Web.
Os marketplaces vão oferecer suporte direto a apps da Web, sem toda a sobrecarga de envolvê-los de forma nativa? 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 faz parte de uma tendência geral de catálogos de apps da Web, incluindo algumas tentativas específicas para dispositivos móveis. O conceito de uma loja na Web ainda está no início, 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 dispositivos nativos, e outros para a Web. A pilha da Web provavelmente tem mais impulso, mas em termos de recursos e qualidades de execução, os apps nativos também estão se movendo rapidamente. E, a menos que as tecnologias da Web se tornem um cidadão de primeira classe na maioria dos SOs para dispositivos móveis, o desenvolvimento nativo sempre será uma consideração importante.
Uma técnica mencionada neste artigo são os apps híbridos, que podem ser a melhor opção para alguns desenvolvedores: visualização da Web onde possível e componentes nativos específicos da plataforma onde não é.
Se você escolher o caminho da Web, lembre-se dos padrões da Web e do princípio do aprimoramento progressivo. A Web é uma tecnologia que sabe como segmentar as multidões de dispositivos e sistemas operacionais por aí. Seja "fragmentação" ou "diversidade", a Web aceita isso, e os desenvolvedores podem se beneficiar de toda a anterioridade existente.