Aplicações mobile: Web ou Nativa?
Postado em 30. ago, 2012 por André Silva em Mobile
Na semana passada a notícia de que o Facebook abandonou sua aplicação Web Mobile para lançar uma versão totalmente nativa com iOS, reascendeu a discussão sobre construir aplicações mobile usando linguagens nativas (Android, iOS, Windows Phone, outros) ou Web. Vale lembrar que outros já fizeram o caminho contrário: o Finantial Times chegou a ter sua aplicação removida da App Store para ter como única opção a versão web.
Quando devemos construir uma aplicação com web ou nativa? Diversos posts e artigos abordam essa questão.
Se escolher construir uma aplicação com Web teremos como vantagens e desvatagens:
- A aplicação que pode rodar em múltiplas plataformas.
- Atualização rápida e abrangente. Não é necessário passar por Apple/Play Store ou ter que esperar o usuário baixar uma versão nova.
- Por atender várias plataformas mobiles diferentes, a UX do aplicativo não terá o tom característico do dispositivo.
Já uma aplicação nativa:
- Necessita de tempo para desenvolver código diferente para cada plataforma.
- UX mais específica
- SDK pode facilitar o desenvolvimento e teste dos aplicativos.
- A atualização do aplicativo depende de Apple/Play Store e do usuário.
Essa resposta depende da definição do aplicativo. Olhando para os pontos positivios e negativos conseguimos ter uma idéia do melhor caminho a seguir.
No QConSP de 2012, Martin Fowler abordou esse tema em sua palestra, chegando a discutir a criação de aplicações híbridas que usam a linguagem nativa com HTML 5. Aliás, esse era o caso do Facebook, onde uma casca em iOS envelopava uma aplicação HTML5.
Mas às vezes é até difícil dizer o que é ou não uma aplicação. Quais critérios você utiliza para essa decisão? Qual aplicação voce acha que deveria ser transformada de nativa para web ou vice-versa? Não deixe de comentar.
A Editora Casa do Código publicou recentemente o primeiro livro em português sobre Web Design Responsivo, recomendado para quem quer iniciar nesse mundo.
Se você tem interesse em se aprofundar na web, saiba mais do nosso curso Desenvolvimento Web com HTML, CSS e JavaScript. Se quer aprender a criar uma aplicacação nativas, conheça nosso curso de desenvolvimento móvel com Android e desenvolvimento móvel com iOS.
ASSINE NOSSO RSS
Rodrigo Facholi
30. ago, 2012
Oi André, muito bom o artigo! (Curti muito os links)
Eu só senti falta de mais alguns pontos positivos e negativos para os ambos, como por exemplo a integração da aplicação com as features do aparelho(como vibra, acelerômetro, câmera…).
[]‘s
Renan Lobo
30. ago, 2012
e sobre o firefox os, vai ser possível o html5 interagir com chamadas, vibra, câmera, e outras coisas do hardware?
Luiz Aguiar
30. ago, 2012
Acho que aquela clássica palavra/resposta também se encaixa aqui… “depende”! =)
Para alguns projetos que participei de apps nativos, era nítido que seria muito vantajoso se fosse em HTML5, principalmente projetos que eram basicamente levar o mesmo conteúdo de uma site/portal para um devise, seja telefone ou tablet.
Outros projetos o fato de ser nativo lhe dava um grande diferencial, tanto em usar recursos nativos de hardware e integração com o sistema, uso variados de gestos que bem aplicados ajudam o usuário e dão uma impressão de uso muito boa, melhor experiência de uso que muitas vezes o próprio SDK já te proporciona com componentes prontos e customizáveis.
No caso específico mais recente da App Store, a Apple tem sido mais chata com relação aos aplicativos “cascas”, isso pode ser algo que a curto/medio prazo influencie muito na hora de começar um novo projeto se ela aumentar o rigor com isso exigindo maior integração nativa nos apps.
Embora tenhamos o exemplo do app do Google+ que tem uma bela interface, hoje ainda vejo a maioria dos apps em HTML com interface não tão bem “acabada” como os nativos e em boa parte da vezes com “performance de uso” pior, isso deve melhorar gradativamente com o tempo.
Bom artigo, é algo que gosto muito e estou bem envolvido nessas discuções.
[]s
Paulo Silveira
30. ago, 2012
Pra quem está falando da desvantagem da versão web pura não ter acesso ao giroscópio, acelerometro, câmera, etc… isso não é bem assim. Via JavaScript já dá para acessar através de APIs bem definidas. Só não sei como anda a adoção delas por parte de cada browser. Sergio Lopes e outros podem falar melhor
Mike Dias
30. ago, 2012
Aqui tem um post interessante sobre o assunto:
http://thinkmobile.appcelerator.com/blog/bid/211263/The-Great-Mobile-App-Debate-Native-vs-HTML5
André Tagliati
30. ago, 2012
Taí o phonegap com seu javascript que não nos deixa mentir. Aplicações locais teriam a vantagem de não depender de conectividade.
Aquela app que você tanto precisa pra calcular uma determinada taxa e você não pode usar pois está em modo avião… ( ok… forçado mas fica de bônus a lembrança que depender de conectividade é arriscado até mesmo quando se tem conexão de forma abundante o que não é o nosso caso )
Paulo Luan
31. ago, 2012
Minhas experiencias apontam que alternativas como
http://www.codenameone.com/
http://www.appcelerator.com/ e
http://www.mosync.com/
São as melhores tecnologias, pois fazem com que a aplicaçao seja nativa, porem com uma mesma base de código compiladas pra diferentes plataformas.
Laerio Guerço Rodrigues
31. ago, 2012
Acho que se for em HTML5, temos duas questões:
1- Sabemos que a compatibilidade varia muito de browser para browser. ai já temos mais de uma aplicação ou adaptação.
2- Aplicativos nativos e residentes, solucionam a falta de conexão Web, permitindo, quando restabelecida, transferir dados da base embarcada para o servidor.
Não agredito em uma solução única, a considerar a capacidade desconectada, por exemplo, dos SmartFone.
Paulo Silveira
31. ago, 2012
Oi Laercio
Acho que essas duas questões não são mais tão pesadas. APIs como jQuery permitem que seu código seja agnóstico ao browser. Além disso, a API appcache permite você trabalhar offline e sincronizar dados quando online, da mesma maneira que você cita com uma aplicação nativa.
mauricio
31. ago, 2012
No caso de uma app nativa voltamos para o tempo que precisavamos desenvolver aplicacoes para win e linux ja no caso do html 5 ficamos com muita dificuldade de integrar a app com o hardware especifico conforme o pessoal ja citou resumindo caimos na decisao conforme as necessidades do projeto.
João Reis
03. set, 2012
Tenho estudado isso desde o QCon e a resposta pra mim ainda é o velho “depende” como já citado aqui.
Trabalho em uma empresa muito grande, cujo negócio não está vinculado a TI. temos um centro de desenvolvimento imenso, porém teriamos que montar uma outra estrutura para disponibilizar algumas apps mobile. Aqui acho que a grande sacada é aproveitar o Know-how da galera e criar apps “web-mobile”…a casquinha nativa e o restante em html5, js e css3 mesmo.
A desvantagem da aparência caracteristica de cada aparelho, pode ser resolvida com um bom trabalho de css e um javascriptzinho “maroto” que da o “look and fell” de acordo com o aparelho…fica 100%? não!! mas no meu caso aqui, fica mais barato..e isso faz toda diferença!
Sérgio Lopes
05. set, 2012
Pra mim, o comentário do João resume tudo: “fica 100%? não! mas fica mais barato e isso faz toda a diferença”.
A questão da Web não é ser igual ou melhor que o nativo. No Desktop não é assim, no mobile também não. Nativo sempre vai ser melhor em aparência, performance etc.
A questão é ser *bom o suficiente*. Google Docs é melhor que MS Office? Não mesmo. Mas, pra *muita* gente, é bom o suficiente.
Se você consegue performance, aparência etc bons o suficientes na Web, aí as vantagens de Web se destacam: multiplataforma, independência de loja, custo mais baixo, integrado com todos os outros sites e serviços do mundo, etc.
Pedro Brigatto
11. set, 2012
Eu sinceramente não entendo como “colou” essa mentira deslavada de que app híbrida é mais barata que app nativa, no tocante à confecção. Isso é uma mentira!
Componentização + Modularização + OO responsável + Patterns + UX profissional = experiência única e custo até mais baixo que aquele obtido em desenvolvimento híbrido.
Facebook, Wunderlist e outras .. toda empresa que busca uma solução decente para o usuário final foge de experiências híbridas. Motivo principal: respeito ao usuário de smartphone e tablet, que paga caro para ter experiência plena.
Não sou contra web app (que tem sim seu espaço), mas pensar em híbrido como bala de prata é no mínimo um grande exagero, uma barbaridade. E tem muita empresa pensando exatamente isso (empresas de nome, inclusive), e contando esse papo furado de custo para seus clientes!
Ah, e híbrido fica cross-platform né? Outra balela que vivem defendendo no mercado. Roda um app Phonegap ou Titanium (ou até usando Sencha como framework de UI) num BlackBerry Curve 9300, 8520, que é só o que se vê no mercado nacional em termos de RIM, e vejam a experiência obtida. Tentem num Torch também, será sofrível igual. É digna de jogar o aparelho na parede. E o que falar do WIndows Phone, que, se pegar no mercado nacional, trará mais um motor de renderização para complicar a história?
Mas enfim … é um tema polêmico, não se esgotará nunca. Eu fico com a ideia de que, se você é um desenvolvedor mobile, deve sim respeitar a escolha do seu cliente por este ou aquele aparelho, e trabalhar com técnicas e abordagens de trabalho que permitam que você reduza seus custos e continue entregando para eles a melhor experiência possível nas plataformas-alvo. Temos MDA, DDD, componentização, padrões de projeto, Agile, de tudo um pouco para atender com excelência o nosso público. Não vejo porque abrir espaço para gambiarras.
Nesken
11. set, 2012
“A questão é ser *bom o suficiente*. Google Docs é melhor que MS Office? Não mesmo. Mas, pra *muita* gente, é bom o suficiente.”
Falou tudo.
Alexandre Gama
12. set, 2012
+1 “A questão é ser *bom o suficiente*. Google Docs é melhor que MS Office? Não mesmo. Mas, pra *muita* gente, é bom o suficiente.”
Ainda não gosto da ideia de ter q manter equipes diferentes trabalhando para Android, outra pra iOS, Windows Phone, etc, etc enquanto(na medida do possível como já falaram) posso ter uma app não nativa.
Bom início de discussão André. Vamos ver como o Facebook vai se comportar agora que estão querendo com todas as forças o mercado Mobile (e querendo ignorar o HTML5, que segundo eles foi um erro grande)
http://tecnologia.terra.com.br/noticias/0,,OI6146828-EI12884,00-Nosso+maior+erro+foi+apostar+em+HTML+diz+Zuckerberg.html
Abs pessoal!
André Silva
13. set, 2012
Galera muito interessantes os comentários.
Mas vale lembrar que cada a caso é um caso.
O Facebook poderia seria melhor como uma app nativa? Acredito que sim. Já o Financial Times é melhor ser uma Web App.
Nós temos que olhar para o projeto e escolher o que vamos usar avaliando os pontos de cada lado.
João Reis
18. set, 2012
Para os adeptos das apps “web-mobile”,
vale mais a pena Levando em consideração experiência com usuario, facilidade de manutenção e promoção da app para aumentar numero de usuarios :
1-ter uma versão 100% na web,
2- criar uma versão com phonegap ( ou outro) ,
3- criar apenas uma casquinha nativa com um webviewr funcionando como um “gate”, mas, mantendo sua app toda na web.
4- alguma outra ideia?
Danilo
16. abr, 2013
No meu ponto de vista, a curva de aprendizado de um app web puro é muito maior, somando o tempo de desenvolvimento (apenas uma plataforma), e considerando que a cada dia a concorrência cresce exponencialmente, focar no desenvolvimento de soluções que explorem as funcionalidades dos dispositivos com HTML5 seria a melhor solução!! Mas como eu disse… “é meu ponto de vista”.
Studio Nasus