Recentemente, iniciei aqui uma série para falar sobre os embates do mundo mobile. Este artigo aqui mostra a nossa concepção sobre o uso de web (ou mobile web) versus aplicativos. No texto de hoje, pretendo diferenciar aplicativos nativos e híbridos ou cross-platform. Lembrando que, como já disse no artigo anterior, 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 artigo 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 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, em 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, que 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 a 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, independentemente 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 SPAs 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, independentemente da sua opção de ferramenta para construção do seu produto, e em 2016 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, era 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, como CocoaPods 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 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ê? Este artigo 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!

***

Artigo publicado originalmente em http://blog.concretesolutions.com.br/2016/03/nativo-x-hibrido/