Concrete Logo
Hamburger button

Nativo x Híbrido – A Discussão Final! (Parte 1)

  • Blog
  • 16 de Março de 2016
Share

Na semana passada, iniciei aqui uma série para falar sobre os embates do mundo mobile. Esse post aqui mostra a nossa concepção sobre o uso de web (ou mobile web) versus aplicativos. No post de hoje, pretendo diferenciar aplicativos nativos e híbridos ou cross-platform. Lembrando que, como já disse na semana passada, não estamos entrando em uma competição da qual apenas um será ganhador. Estamos tratando de trade-offs e prós e contras, e a resposta final para a sua decisão deve ser baseada no seu cenário específico. Vamos lá?

Nativo x Híbrido ou Cross-platform

Uma vez que, eu espero, a discussão sobre web versus apps tenha sido apaziguada dentro dos nossos corações no post passado, podemos discutir uma questão mais central do problema, o embate entre apps nativos e híbridos ou cross-platforms. Mas, antes disso, é legal especificarmos o que é cada um deles. Concorda?

O que é um aplicativo mobile nativo? É um aplicativo desenvolvido para uma

plataforma específica, utilizando todo o potencial de funcionalidades da plataforma para a qual ele foi feito. Normalmente isso implica em linguagens de programação, ferramentas e processos de distribuição específicos (mas não restritos) daquela plataforma. Para um aplicativo nativo para o sistema operacional iOS, por exemplo, você precisaria utilizar um Mac, usaria o XCode como IDE e desenvolveria em Objetive-C ou Swift.  Por sua vez, um aparelho que tenha como sistema operacional o Android poderíamos ser mais flexíveis quanto ao computador, mas provavelmente usaríamos Java como linguagem e o Android Studio como IDE.

E o que é um aplicativo mobile híbrido ou cross-platform? Em primeiro lugar é importante dizer que as definições não são tão claras quanto gostaríamos, e que ainda não existe muito consenso na comunidade em geral, mas de qualquer jeito, um aplicativo híbrido e/ou cross-platform é aquele que possui uma parte suficientemente grande (ou todo ele) feita em uma tecnologia que não é a específica daquela plataforma, ou que não seja a mais comumente utilizada. Como exemplo podemos citar um app feito em HTML5 rodando em cima de uma webview do sistema operacional.

Uma variação são os aplicativos chamados cross-platform. Esses são aqueles que você desenvolve em uma linguagem específica e um gerador cria versões nativas para cada uma das plataformas que são o seu target. Outra variação do mesmo tema de cross-platform é quando você desenvolve em alguma linguagem em comum e de alguma forma uma ponte entre a sua linguagem e as bibliotecas nativas do sistema operacional é estabelecida de forma a permitir chamarmos componentes nativos, de user interface por exemplo. De uma forma ou de outra, a Xamarin, a Phonegap e a Kony, por exemplo, oferecem variações desse tipo de solução.

Concordamos com essas definições? Perfeito. Então vamos partir para os pontos ligados à essa batalha.

Complexidade e custo de desenvolvimento

Os principais argumentos a favor de aplicações híbridas são a redução de custo do desenvolvimento e a complexidade de desenvolver para múltiplas plataformas. Afinal, se eu tenho que desenvolver um site web, um app iOS e um app Android, eu provavelmente precisaria de três profissionais ou times diferentes para atender especificamente cada uma dessas plataformas. A solução para isso seria ter um time desenvolvendo parte da aplicação em HTML, CSS e JS (parte essa que poderia ser reutilizada para a web) e utilizando, por exemplo, o Phonegap. Assim, eu poderia ter o meu app e o meu site sendo desenvolvidos a partir de uma mesma equipe, bem enxuta. Além disso, fazer um app nativo é mais complexo e custoso do que outro tipo de software de natureza similar.

Será mesmo? Sobre esse ponto, é importante ressaltar que para a maioria dos aplicativos mobile a maior complexidade do ponto de vista de regra de negócio deveria estar dentro de uma API. Um design desse tipo evita a duplicação de código entre as plataformas (web incluída) e garante que as alterações sejam feitas em único ponto e estejam disponíveis para todos os canais, independente da natureza do seu processo de desenvolvimento. Como essa é uma regra bem comum e plausível do desenvolvimento de software, os aplicativos, em sua maioria, deveriam ser camadas de apresentação relativamente simples.

Entretanto, desenvolver produtos digitais é algo complexo, custoso e caro, e como a tecnologia evolui constantemente é importantíssimo que os próprios desenvolvedores continuem evoluindo. Um time “padrão” para desenvolver um produto digital web seria constituído de sete papéis, caso usasse metodologias ágeis: Product Owner, Scrum Master, User Experience Designer, Quality Assurance Professional, DevOps, Front-end developer e Back-end developer. Se esse produto fosse desenvolvido em iOS e Android, deveríamos acrescentar mais dois perfis de profissionais nesse pool de talentos: iOS developer e Android developer. Ou seja, considerando o esforço necessário para construir um produto digital com vários canais, é muito importante lembrar que a maioria dos papéis ainda serão necessários (e muitas vezes compartilhados).

Sobre a complexidade de desenvolvimento, devemos dizer que desenvolver qualquer produto digital é complexo. Mesmo que ele seja todo escrito em Javascript (usando alguma solução para SPA’s e Phonegap) e Node.js no back-end, por exemplo, teríamos que passar pelo processo de separação de configuração por ambientes, gestão de pacotes e dependências e garantir o desenvolvimento de testes unitários, testes funcionais, integração contínua, deployment ou delivery contínuo, instrumentação dos aplicativos de acordo com a necessidade (performance, uso, crashes/falhas, performance em redes de anúncio) e testes em diversos dispositivos físicos. Tudo isso é complexo, custa caro e leva tempo, independente da sua opção de ferramenta para construção do seu produto, e em 2015 não é mais admissível que você produza produtos digitais sem levar em consideração esses processos. O que me leva à pergunta: do ponto de vista de senioridade do profissional que garanta que todos esses quesitos sejam atendidos durante o desenvolvimento de um aplicativo, existe realmente muita diferença no custo salarial ou no treinamento?

É razoável assumir que um desenvolvedor sênior em iOS está ganhando marginalmente o mesmo que um desenvolvedor sênior em Java, e o mesmo se aplica para um ninja em Javascript. Fazer código em Javascript de qualidade é algo trabalhoso, assim como em qualquer outra linguagem.

Se analisarmos a quantidade de código necessário para fazer, por exemplo, a interface do Grooveshark na web como Single Page Application, temos algo em torno de 21 mil linhas de código entre HTML, CSS e JS. A versão responsiva da home da Globo.com em meados de novembro de 2015 é formada por assustadoras 54 mil linhas de código Javascript (minificadas), distribuídas em 23 arquivos Javascript, sem contar toda a complexidade de HTML e CSS necessária para suportar os diversos tamanhos de dispositivos. Pode ser que nem todos os scripts tenham sido feitos dentro da Globo.com, mas esse caso apenas explicita o quão complexo é fazer algo, mesmo garantindo o reuso entre as plataformas. Ou seja, não é evitando o problema de saber fazer produtos digitais direito que vamos conseguir endereçar o problema de complexidade.

Além disso, com o passar do tempo, a própria comunidade criou ferramentas que ajudam a simplificar o desenvolvimento nativo, comoCocoaPods e o Gradle, assim como os diversos repositórios disponíveis no Github. Ainda existem vários cursos, tanto oficiais das próprias plataformas quanto não oficiais, que ensinam e estimulam o conhecimento sobre desenvolvimento nativo.

O principal ponto ignorado quando a discussão sobre apps nativas versus híbrida ou web ocorre é que o software está comendo o mundo, e nos próximos 20 anos a maioria dos segmentos serão disruptados por inovações tecnológicas que envolvem a produção, manutenção e evolução de software. Nesse contexto, a discussão sobre qual ferramenta utilizar para atingir um propósito de produto é quase irrelevante. Em vez disso, deveríamos estar discutindo sobre como eliminar os silos dentro da sua empresa, aproximando as áreas de negócio e tecnologia (se possível transformando-as em uma só equipe multidisciplinar) e se preocupando o mais rápido possível em como se tornar uma empresa capaz de pensar e executar produtos digitais de forma efetiva.

E aí? Já decidiu qual é o melhor formato para você? Esse post não termina aqui. Na semana que vem, pretendo falar sobre Experiência do Usuário e Performance, outros pontos que também são significativos no embate entre apps nativos e híbridos. Fique atento! Se você ficou com alguma dúvida ou tem algo a acrescentar, aproveite os campos abaixo. Até semana que vem!