O debate sobre aplicativos móveis
Introdução
Aplicativos móveis e HTML5 são duas das tecnologias mais usadas no momento, e há bastante sobreposição. Os aplicativos 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 compatíveis, combinadas com o poder absoluto dos navegadores para dispositivos móveis, os desenvolvedores estão adotando o HTML5 como uma solução do tipo "escreva o primeiro, execute vários". Mas isso é mesmo viável? Ainda há motivos convincentes para se tornar nativo e, claramente, muitos desenvolvedores estão de fato seguindo esse caminho. Este artigo é um debate sobre nativo e Web.
riqueza de recursos
Importante: os anúncios nativos podem fazer mais
Podemos dividir a funcionalidade de dispositivos móveis em duas dimensões: a experiência do próprio app e a forma como ela se conecta ao ecossistema do dispositivo. Por exemplo, para Android, seriam recursos como widgets e notificações. O formato nativo se destaca nas duas dimensões.
Em termos de experiência, os apps nativos podem fazer mais. Eles podem conseguir facilmente eventos de deslizar e até mesmo multitoque nas plataformas compatíveis. Normalmente, eles podem agir ao pressionar teclas rígidas, como o botão de pesquisa do Android e os controles de volume. Eles também podem acessar hardware, como GPS e câmera. Além disso, com a permissão do usuário, algumas plataformas oferecem acesso irrestrito ao sistema operacional. Tente detectar quanto de bateria resta com o HTML5!
Mas vai além da experiência no app. Um sistema operacional como o Android oferece maneiras diferentes para os apps interagirem com os usuários e, até mesmo, 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 o app anuncie que ele fornece um serviço geral que outros apps podem exigir em alguns casos.
Contraponto: os recursos nativos podem ser ampliados, e a Web está se aproximando
É verdade que muitos recursos no app estão fora do alcance de um app HTML5. Não importa o quanto suas habilidades de fu da Web sejam, se o app ficar preso em um sandbox sem API de câmera, ele não conseguirá tirar fotos tão cedo. Felizmente, você não precisa estar nesse sandbox. Se você realmente precisar que seu app da Web tire uma foto, crie um app nativo, com uma visualização da Web incorporada que ofereç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 esses recursos da plataforma, como widgets, notificações e intents.
Criar um app híbrido, nativo e Web, não é a solução ideal. Ela aumenta a complexidade e se aplica apenas a apps da Web unidos como aplicativos nativos, em vez de sites tradicionais acessados em um navegador para dispositivos móveis. Mas pode não ser necessário por muito tempo. Os padrões da Web estão evoluindo rapidamente, e os navegadores móveis modernos estão acompanhando esse ritmo. O armazenamento off-line, a geolocalização, os gráficos de tela e a reprodução de vídeo/áudio têm amplo suporte entre os modelos modernos, por exemplo. Até a câmera está começando a ser compatível. A partir do Android 3.1, é possível capturar fotos e vídeos usando padrões da Web. E o navegador iOS mais recente é compatível com WebSocket para streaming bidirecional, bem como detecção de orientação de dispositivo.
De modo geral, os dispositivos móveis estão evoluindo. Mas a web também está evoluindo e rápida. Somente entre os navegadores para computadores, há cinco principais fornecedores de navegadores que estão sempre melhorando os padrões e adicionando recursos. A portabilidade desses recursos para dispositivos móveis não é um processo trivial, mas muitos deles já estão disponíveis em navegadores para dispositivos móveis.
Os anúncios nativos têm um desempenho dinâmico, mas a Web está oferecendo novos recursos.
Desempenho
Ponto: o anúncio nativo é mais rápido
Os apps nativos não precisam lidar com a barreira do ambiente de execução da Web. Eles são executados perto do metal e podem aproveitar os impulsionadores de desempenho, como a aceleração de GPU e o multithreading.
Contraponto: atualmente, os ambientes de execução na Web são muito mais rápidos e a maioria dos apps não precisa da velocidade
Seria um equívoco dizer que a Web ficou mais rápida nos últimos anos. Quando lançado, o V8, o mecanismo JavaScript que acompanha o Chrome, foi um grande desenvolvimento em desempenho na Web e, desde então, 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 bump de velocidade fornecido pelo hardware Accelerated Canvas:
Além disso, a nova API Web Workers possibilita o uso de várias linhas de execução, e os desenvolvedores da Web modernos também podem usar uma variedade de bibliotecas otimizadas de 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 a eles. Por exemplo, o guru de performance Steve Souders tem uma página dedicada a ferramentas de performance para dispositivos móveis (link em inglês).
Nem todos os avanços relacionados à área de trabalho chegaram a todas as plataformas móveis, mas as tendências indicam que eles estão a caminho. Também é importante notar que a maioria dos apps para dispositivos móveis não são jogos 3D de última geração, mas essencialmente baseados em informações: notícias, e-mail, horários, redes sociais etc. Acesse alguns sites pelo seu dispositivo móvel, como Gmail, Amazon e Twitter, para 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 se espalhe, há uma família cada vez maior de frameworks que compilam apps WebGL para apps nativos que podem aproveitar o OpenGL, por exemplo, ImpactJS.
Experiência do desenvolvedor
Importante: o formato 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. Você pode depurar apps facilmente 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 for executado, não garantirá que o recurso X esteja disponível. E mesmo que seja, como o navegador a implementará? Os padrões estão abertos a interpretações.
Contraponto: muitas vezes é mais fácil desenvolver a Web, especialmente ao segmentar vários dispositivos
Vamos abordar primeiro a tecnologia central. É verdade que os padrões da Web foram concebidos originalmente em uma era em que a Web era basicamente baseada em documentos, não em aplicativos, com JavaScript criado e implantado em apenas 10 dias. No entanto, elas se mostraram muito mais capazes do que imaginado: os desenvolvedores da Web aprenderam a aproveitar as partes boas e dominar 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. Escolher C++, Java ou JavaScript é uma questão de controvérsia e também depende da sua base de código legada. Mas certamente podemos incluir o JavaScript como um grande obstáculo hoje em dia.
Por outro lado, a fragmentação do navegador/tempo de execução é o fato de que todos esses ambientes existem. Desenvolva um app Android em Java e tenha acesso a uma porta completa para o Objective-C a fim de oferecer suporte ao iOS. Desenvolva um app da Web que será executado no Android e no iOS, sem mencionar como WebOS, BlackBerry, Windows Mobile e... bem, essa é a teoria de qualquer maneira. Na prática, você vai precisar ajustar as coisas para cada plataforma se quiser realmente a experiência certa. Mas você também teria que fazer isso no formato nativo, para a maioria dos sistemas operacionais móveis, existem diferentes versões e diferentes dispositivos.
A boa notícia é que a "fragmentação" sempre foi assim na Web, e existem técnicas conhecidas para lidar com isso. Mais importante, o princípio do aprimoramento progressivo incentiva os desenvolvedores a primeiro buscar um dispositivo básico e adicionar camadas de qualidade específica da plataforma quando disponível. O mantra da detecção de recursos também ajuda, e, atualmente, temos suporte de biblioteca de empresas como a Modernizr para dar suporte ao Web design responsivo. Com o uso criterioso dessas técnicas, você pode expandir o alcance para a grande maioria dos dispositivos, até mesmo "celulares com recursos" tradicionais, até mesmo formatos como relógios e TVs, independentemente da marca e do sistema operacional. Confira nossa demonstração de várias interfaces no Google I/O 2011, em que segmentamos formatos distintos (smartphones, smartphones, tablets, computadores e TVs) com uma base de código comum de lógica e marcação.
Aparência
Ponto: o anúncio nativo se adapta à aparência da plataforma
Um dos recursos que definem qualquer plataforma é a aparência. Os usuários esperam que os controles sejam apresentados de maneira consistente e manipulados da mesma maneira. Existem certos idiomas que variam de plataforma para plataforma, por exemplo, o que acontece quando o usuário realiza uma "retenção longa" (mantém tocando em um elemento por vários segundos)? As plataformas têm expressões padrão para essas coisas, e não é possível satisfazer todas elas com um único aplicativo 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ê tem uma grande quantidade de aparências "sem custo financeiro" esperadas apenas usando o kit de ferramentas nativo.
Contraponto: a Web tem uma aparência única, e você também pode personalizar a interface para as plataformas que mais importam.
Conforme explicado na seção anterior, o desenvolvimento da Web é escrever uma versão básica de tamanho único e depois aprimorá-la progressivamente. Embora a melhoria geralmente seja baseada em recursos, você também pode aprimorá-la segmentando as plataformas que são mais importantes para você. Esse é um tipo de "detecção de navegador", que às vezes é desapontado pela comunidade da Web, principalmente porque existem tantos navegadores possíveis por aí. No entanto, se você visualizar duas ou três plataformas com prioridade muito alta e quiser se esforçar mais para se comparar com as alternativas nativas, talvez esse seja o caminho a seguir.
Em relação à versão de referência, a Web tem a própria aparência, e podemos até dizer que cada plataforma para dispositivos móveis tem o próprio "aparência da Web" estabelecido pelo navegador e ambiente de execução padrão. A "aparência na Web" pode ser adequada para seus usuários e, na verdade, permite que você alcance um grau maior de consistência com a experiência de navegação na área de trabalho e em outros dispositivos com os quais o usuário possa estar trabalhando. Além disso, há muitos apps bem-sucedidos que não oferecem suporte à aparência nativa. Isso com certeza se aplica a jogos (seu jogo para dispositivos móveis favorito segue a aparência do SO para dispositivos móveis) e até mesmo vale para apps mais convencionais (por exemplo, confira os clientes nativos do Twitter mais conhecidos na plataforma de sua escolha) para ver uma grande variedade de mecanismos de interface do usuário em ação.
Facilidade de descoberta
Importante: é mais fácil descobrir apps nativos
Mecanismos de distribuição de apps, como o Android's Market e a App Store da Apple, foram predominantemente famosos nos últimos anos e são um grande motivador 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 com uma combinação de navegação, pesquisa e receber recomendações. Não apenas isso, mas, se você tiver feito seu trabalho corretamente, classificações e comentários brilhantes convencerão os usuários a pressionar o importante botão de instalação.
Contraponto: na verdade, é mais fácil descobrir apps da Web
A web é possivelmente o meio mais detectável já criado. No modesto URL, temos (teoricamente, pelo menos) um identificador exclusivo para tudo o que já foi publicado na Web, que inclui qualquer app publicado em sites padrão. Os mecanismos de pesquisa facilitam a descoberta de que o conteúdo e outros sites podem ter links para ele, incluindo catálogos de apps da Web semelhantes aos mercados para dispositivos móveis. Qualquer indivíduo pode compartilhar aplicativos da Web com amigos simplesmente inserindo links para eles em e-mails e mensagens de redes sociais. Os links também podem ser enviados por SMS, onde os usuários de dispositivos móveis poderão clicar no link e iniciar o app no navegador do dispositivo.
Ainda não temos os mesmos mercados em que os usuários podem classificar e comentar em apps, mas isso também está mudando. Continue lendo...
Monetização
Ponto: anúncios nativos podem gerar receita
"Uma criança de 6 anos faz o app na hora do almoço e vende um zilhão de cópias por US $3 cada". Esse título é muito comum hoje em dia, então não é surpreendente que desenvolvedores grandes e pequenos estejam buscando monetização nos mercados de dispositivos móveis. As plataformas para dispositivos móveis oferecem várias maneiras para os desenvolvedores cobrarem diretamente pelos apps. O mais simples é o pagamento único, para desbloquear o app por toda a eternidade. Também há mecanismos de pagamento no app e de assinatura oferecidos em algumas plataformas, que são bem integrados em um mecanismo consistente e seguro. Essas novas formas de pagamento permitem que os desenvolvedores convertam um grande app em um fluxo de receita de longo prazo.
Além dos pagamentos de apps, é possível gerar receita com modelos tradicionais da Web, como publicidade e patrocínio.
Contraponto: sempre foi possível gerar receita na Web, e as oportunidades estão aumentando
A Web não seria o motor da indústria moderna se não houvesse muitas oportunidades de lucrar. Embora os mecanismos diretos de "pagamento por uso" ainda não tenham desenvolvido, há vários nichos em que as soluções de "software como serviço" baseadas em assinatura se tornam viáveis. Por exemplo, Google Apps, 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 e promoção cruzada com outros produtos e serviços.
Dito isso, é perfeitamente razoável que um desenvolvedor da Web leia os títulos e sinta um pouco de inveja de pagamentos. Não é possível enviar um URL da Web para os mercados nativos. Então, o que um desenvolvedor da Web deve fazer? O que você precisa fazer é criar um "app de wrapper" nativo. Para cada plataforma a ser segmentada, crie um aplicativo 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 mercados e esperar o dinheiro entrar. Provavelmente, existem centenas, se não milhares, de apps com tecnologia da Web nos principais mercados hoje, alguns deles tão bem assimilados que nem sequer conhecemos os apps da Web deles.
A desvantagem é a necessidade de compilação cruzada para cada plataforma. É aqui que um framework 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 iOS etc. serão exibidos, prontos para você enviar às respectivas lojas. Não é preciso instalar SDKs nativos na sua máquina. Tudo o que você precisava para criar todos esses apps nativos era um editor de código e um navegador da Web.
Os mercados vão oferecer suporte direto a apps da Web, sem todo o trabalho de envolvê-los de forma nativa? Ainda não está claro. Sabemos que o Google introduziu a Chrome Web Store no ano passado e, embora ela se aplique apenas aos computadores, a loja despertou o interesse de outros fornecedores de navegador e é parte geral de uma tendência em relação a catálogos de apps da Web, incluindo algumas tentativas específicas para dispositivos móveis. O conceito de loja on-line 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 conteúdo nativo e outros para a Web. É claro que a pilha da Web tem mais momento, mas em termos de recursos e qualidades de execução, os apps nativos também estão se movendo rápido. E a menos que haja um momento em que as tecnologias da Web sejam cidadãs de primeira classe na maioria dos sistemas operacionais móveis, os nativos sempre serão uma consideração importante.
Uma técnica mencionada neste artigo são os apps híbridos, e essa pode ser o melhor comprometimento para alguns desenvolvedores: visualização da Web, quando possível, e componentes nativos específicos da plataforma, quando não é.
Se você escolher o caminho da Web, considere os padrões da Web e o princípio do aprimoramento progressivo. A Web é uma tecnologia que sabe como segmentar a multidão de dispositivos e sistemas operacionais ao redor. Se você escolher chamar isso de "fragmentação" ou "diversidade", a Web a aproveita e os desenvolvedores podem se beneficiar de todas as artes anteriores disponíveis.