Escreva uma vez, implante em todos os lugares: quando se tornar nativo?

Write Once, Deploy Everywhere (WODE) tem sido a promessa de muitas estruturas de desenvolvimento na última década, cujo objetivo é aliviar a dor de escrever vários aplicativos nativos. Determinar qual caminho seguir é uma das decisões mais críticas que um gerente de projeto deve tomar devido ao seu alto custo de inicialização, impacto sobre a equipe de desenvolvimento e potencial inviabilidade de reverter.

As soluções híbridas, como a Ionic, aproveitam as tecnologias da Web para renderizar aplicativos entre plataformas, mas, muitas vezes, o produto final fica aquém das expectativas do usuário de uma aparência nativa .

No entanto, mesmo o termo “nativo” foi recentemente confundido por estruturas que compilam para código nativo (por exemplo, React Native, Xamarin, etc.).

Este artigo detalha os prós e contras de vários caminhos de desenvolvimento móvel e os compara com a composição da equipe, custo e experiência do usuário em um esforço para capacitar os gerentes de produto a tomar uma decisão mais informada.

Escreva uma vez, implante em qualquer lugar

O conceito de Write Once, Deploy Everywhere refere-se à capacidade de uma equipe de desenvolvimento de escrever um aplicativo uma vez - usando uma única pilha de desenvolvimento, resumo da(s) plataforma(s) em que o aplicativo será implantado - e ainda manter a capacidade de implantar o aplicativo para todas as plataformas desejadas, por exemplo, Android, iOS, Windows, etc. Idealmente, isso é feito sem sacrificar a capacidade de manutenção, o desempenho ou a experiência do usuário (UX).

O método alternativo - e histórico - de desenvolvimento de aplicativos móveis envolve o processo direto de simplesmente escrever um aplicativo separado para cada plataforma, o que, é claro, traz consigo seu próprio alto custo potencial de tempo e recursos.

Em geral, os fatores a serem considerados ao escolher um caminho de desenvolvimento incluem:

• Idade do projeto
• Composição e tamanho da equipe de desenvolvimento
• Plataforma(s) desejada(s) para distribuição
• Cronograma necessário para o mercado
• Largura de banda disponível para mudar para outro caminho se for necessário

Infelizmente, aplicar cada um desses fatores a cada um dos caminhos disponíveis, bem como percorrer a miríade de opiniões disponíveis sobre o assunto, pode ser bastante assustador. Além disso, esse processo muitas vezes deixa o gerente de projeto com uma sensação de incerteza sobre qual caminho é o melhor para atender aos requisitos do aplicativo.

Em um nível alto, os diferentes caminhos de desenvolvimento móvel podem ser colocados em duas categorias: nativo ou WODE, ou seja, nativo ou tudo mais. Simplificando, um escreve um aplicativo nativo ou não. A categoria WODE é dividida em dois grupos:

• Estruturas híbridas - aquelas que aproveitam as tecnologias da Web para renderizar aplicativos em várias plataformas.
• Estruturas não híbridas - aquelas que usam componentes de interface do usuário nativos (por exemplo, botões, campos de texto e até gerenciadores de layout) em vez de renderizar uma visualização da Web dentro de um aplicativo, como fazem as estruturas híbridas.

A maioria das estruturas WODE são híbridas ; no entanto, para melhorar o desempenho e as limitações de experiência do usuário de estruturas híbridas e ainda fornecer os benefícios de uma estrutura WODE, a tendência atual é não híbrida . Devido a essa tendência, estruturas como React Native, Xamarin e Appcelerator estão ganhando popularidade.

Cada um desses caminhos — nativo, híbrido e não híbrido — tem diferentes pontos fortes e fracos e, como resultado, cada um tem diferentes casos de uso para os quais é mais adequado. O restante deste artigo detalha os prós e contras de cada caminho de desenvolvimento móvel ao considerar prioridades concorrentes, como composição da equipe, custo do projeto e UX. Com exceção de alguns casos de uso especializados, escrever aplicativos nativos maximiza a experiência do usuário a um custo um pouco mais alto.

Em geral, o ditado “ você recebe o que paga ” se aplica, portanto, se o custo importa mais do que a experiência do cliente, o nativo pode não ser a escolha certa. No entanto, uma vez que o UX se torna vital, os aplicativos nativos se tornam a escolha clara, pois, para melhorar o UX, os aplicativos baseados em WODE incorrem em um custo considerável na forma de tempo ou experiência nativa, o que anula o objetivo de escolher um não nativo. caminho de desenvolvimento em primeiro lugar.

Além disso, mesmo que esse custo seja pago, o produto final baseado em WODE sempre fornecerá um UX inferior quando comparado ao seu equivalente nativo. Como resultado, o nativo é quase sempre a escolha certa para a maioria das equipes de desenvolvimento e para a maioria dos projetos.

Aplicativos nativos

Os aplicativos nativos são escritos na linguagem principal da plataforma em questão. Por exemplo, os aplicativos Android são escritos em Java, enquanto os aplicativos iOS são escritos em Obj-C ou Swift. Eles exigem que o engenheiro de desenvolvimento entenda a linguagem, bem como as nuances específicas da plataforma, que incluem, por exemplo, integração de pacotes de terceiros, gerenciamento de layout, interação do sistema operacional (SO) e assim por diante.

Prós

Altamente personalizável . Como cada aplicativo é escrito utilizando componentes nativos, a única limitação para customização é a interface com os frameworks subjacentes e, às vezes, nem mesmo assim. Como a maioria dos engenheiros de desenvolvimento nativos atestará, geralmente há uma maneira de realizar uma determinada tarefa apesar de uma interface limitada.

Uma prova simples dessa ideia pode ser encontrada navegando nas comunidades de suporte de uma determinada plataforma. Encontraremos vários exemplos de como realizar uma tarefa que pode estar “fora da reserva”, apesar das limitações das estruturas subjacentes.

Um exemplo concreto do iOS de uma tarefa aparentemente simples pode ser mostrar uma sobreposição de tela cheia, acima de todos os elementos de interface do usuário externos, por exemplo, uma barra de guias, barra de navegação etc. Conforme mostrado na Figura 1 , isso normalmente está fora do escopo do camada de interface do usuário normal que está sendo apresentada no momento. Assim, para ter uma sobreposição de tela cheia, ela deve ser adicionada à camada oculta acima da barra de guias na pilha de visualização. Esse tipo de personalização normalmente só é possível em aplicativos nativos.

O mais alto desempenho . Como esperado, um aplicativo nativo define a referência de desempenho. Como a maioria dos outros tipos de estrutura adiciona uma ou mais camadas intermediárias, elas são executadas inerentemente mais lentamente do que um aplicativo nativo.

Mais sustentável . Os sistemas operacionais mudam constantemente. Período. Quando isso acontece, dependendo se foram feitas alterações importantes, um aplicativo deve ser atualizado em tempo hábil para não perder a parte da base de usuários que atualiza para o sistema operacional mais recente. Obviamente, quanto menos tempo passar entre a disponibilização da alteração para os usuários e a atualização de um aplicativo, melhor. Esse tempo é minimizado quando não há dependências que precisem ser atualizadas para dar suporte a esse novo SO, como é o caso de trabalhar em um aplicativo nativo.

Contras

Recursos adicionais . Ao escrever aplicativos para várias plataformas, uma equipe de desenvolvimento normalmente consiste em um ou mais engenheiros de software móvel para cada plataforma suportada. Isso, é claro, aumenta inerentemente o tamanho e o custo de uma equipe de desenvolvimento. Também exige que a equipe de engenheiros tenha uma variedade de habilidades, em vez de ter uma base de habilidades homogênea. Isso tem o potencial de fragmentar uma equipe em relação ao suporte e à colaboração.

Ciclo de desenvolvimento mais lento . Aplicativos nativos têm o potencial de ter um ciclo de desenvolvimento mais lento simplesmente porque um aplicativo separado deve ser escrito para cada plataforma desejada. O caso extremo é quando há um único engenheiro de desenvolvimento móvel na equipe, pois cada aplicativo é essencialmente escrito em série.

Baixo desempenho . Pode parecer estranho ter desempenho tanto como pró e contra. Por um lado, os aplicativos nativos dão ao desenvolvedor espaço suficiente para criar um aplicativo de alto desempenho e bem ajustado. Por outro lado, no entanto, eles também dão ao desenvolvedor corda suficiente para se enforcar. Se eles não souberem o que estão fazendo, no final, acabarão com um aplicativo abaixo da média.

Observação: em geral, isso se aplica a todos os caminhos de estrutura (nativos, híbridos e não híbridos). Se os engenheiros que estão desenvolvendo um aplicativo tiverem habilidades insuficientes para o que estão tentando, o aplicativo resultante provavelmente não atenderá aos requisitos do projeto nem será bem aceito pelos usuários.

Aplicativos híbridos

Os aplicativos híbridos são normalmente escritos usando HTML/CSS/LESS para projetar a interface do usuário: o “V” no padrão de projeto MVC. O “C”, ou controlador, é normalmente escrito em JavaScript - idealmente, usando uma estrutura JavaScript MVC, como AngularJS. O uso de um framework como o AngularJS permite uma melhor separação de classes e responsabilidades do que normalmente é possível usando apenas jQuery.

Um exemplo desse tipo de pilha de estrutura híbrida seria uma camada de visualização Ionic apoiada pelo AngularJS, que é convertida e renderizada em uma visualização da Web na plataforma desejada usando PhoneGap e Cordova. Obviamente, esse tipo de estrutura WODE tem o custo de complexidade adicional.

Além disso, o uso de JavaScript traz consigo suas próprias limitações baseadas em design e problemas baseados em linguagem. O objetivo deste artigo não é debater os méritos ou falhas de qualquer linguagem; no entanto, como gerente de projeto, a escolha de usar JavaScript em sua pilha técnica móvel não deve ser feita de ânimo leve. A seguir estão apenas alguns exemplos de artigos bem escritos sobre por que o JavaScript deve ser evitado, se possível:

• O problema do JavaScript
  
• Por que não sou um desenvolvedor React Native

Prós

Equipe de desenvolvimento mínima . As estruturas híbridas permitem que uma pequena equipe de desenvolvimento – e principalmente uma cuja base de conhecimento principal seja o desenvolvimento da Web – produza rapidamente aplicativos simples em várias plataformas. Isso permite que um gerente de projeto mantenha sua equipe pequena e elimine a necessidade de sua equipe aprender as linguagens e estruturas nativas para várias plataformas.

Ciclo de desenvolvimento mais rápido . Além de uma equipe menor, as estruturas híbridas proporcionam um ciclo de desenvolvimento mais rápido ao implantar em várias plataformas, pois apenas uma única camada de visualização precisa ser projetada usando tecnologias da web.

Contras

UX potencialmente ruim . A desvantagem de ter que escrever apenas uma única camada de visualização é que fica com uma única camada de visualização. Isso pode resultar em uma UX ruim, pois uma abordagem de tamanho único para o design de interface do usuário falha em dar ao aplicativo uma aparência confortável e familiar para os usuários em todas as plataformas. Além disso, como os aplicativos híbridos são essencialmente uma visualização da Web incorporada à interface do usuário, eles podem dar aos usuários a impressão de que eles estão realmente visualizando uma página da Web em vez de interagir com um aplicativo nativo. Essa experiência quase sempre tem um impacto negativo na satisfação do usuário e, em última análise, na retenção.

Caro para personalizar . Aprimorar a UX projetando UIs personalizadas para cada plataforma resulta em estruturas de UI complexas e exclusivas que podem ser caras para criar e difíceis de manter ao longo do tempo. Além disso, para criar elementos de interface do usuário que ajudarão a destacar o aplicativo (por exemplo, animação, visualizações personalizadas etc.), componentes de ponte personalizados devem ser criados para traduzir o design de interface do usuário de alto nível em algo que a estrutura de nível inferior , como Cordova, vai entender. Em geral, quanto mais se personaliza e melhora o UX de um aplicativo híbrido, mais diminui o benefício de um ciclo de design rápido e barato.

Desempenho inferior . Como os aplicativos híbridos renderizam as visualizações do aplicativo em uma visualização da Web, há um grande potencial de cometer erros de implementação ao lidar com estruturas de SO (por exemplo, rede, Bluetooth, contatos no dispositivo etc.), o que resulta em um desempenho muito degradado. Vale ressaltar também que, mesmo tomando muito cuidado com relação ao desempenho, já que tudo é exibido via webview, o desempenho máximo dos aplicativos híbridos será sempre um pouco menor do que seus equivalentes nativos.

Gerenciamento de plugins não trivial . Lembre-se daqueles recursos personalizados que a equipe de design passou semanas polindo, que foi seguida por mais algumas semanas enquanto a equipe de desenvolvimento criava os componentes de ponte necessários para que o Cordova pudesse trabalhar com eles? Bem, eles não funcionarão a menos que haja um plug-in Cordova de suporte para o que a equipe está tentando alcançar. Isso significa uma de duas coisas: ou a equipe o cria por conta própria ou um plug-in de terceiros adequado precisará ser encontrado para fazer o trabalho. Infelizmente, na maioria das vezes, a opção dois não existe. Como resultado, requer um tempo de desenvolvimento adicional para criar os plugins personalizados, seguido por um esforço de suporte de compilação – ao longo do tempo – para gerenciar a crescente biblioteca de plug-ins do Cordova exigida pelo aplicativo. Obviamente, quando ocorrem atualizações do Cordova, há uma alta probabilidade de que esses plugins também precisem ser atualizados.

Atraso no suporte do SO . O problema do componente de ponte em cascata / plug-in Cordova mencionado anteriormente é ainda mais exacerbado quando o sistema operacional altera a funcionalidade principal. Depois que Cordova, PhoneGap e Ionic forem atualizados para suportar as alterações, é possível que os plug-ins personalizados e os componentes de ponte também precisem ser atualizados. Independentemente da ordem de magnitude que esse trabalho exigiria, isso resulta em tempo adicional durante o qual o aplicativo não oferece suporte a usuários finais que atualizaram para o novo sistema operacional. Este, é claro, é o pior cenário em que alterações incompatíveis e não compatíveis com versões anteriores são feitas pela Apple ou pelo Google, o que nunca acontece... certo? Em geral, qualquer framework intermediário que está fora do controle do desenvolvedor e que deve ser atualizado primeiro serve apenas para atrasar o processo. Finalmente, contar com uma estrutura intermediária pode ser uma dor de cabeça para os gerentes de projeto planejarem, já que o tempo dessas estruturas é tão desconhecido.

Aplicativos não híbridos

As aplicações não híbridas começam a vida como suas contrapartes híbridas - uma camada de interface do usuário projetada em uma linguagem de plataforma não nativa: React Native usa HTML/CSS apoiado por JavaScript ou Xamarin, que é baseado em C# devido às suas raízes .NET.

No entanto, é aí que a semelhança termina. Aplicativos não híbridos compilam para código nativo e renderizam o aplicativo usando componentes nativos da plataforma em vez de renderizar por meio de uma visualização da web. Isso resulta em uma estrutura WODE que, pelo menos na superfície, tem o melhor dos dois mundos.

Conforme discutido anteriormente, escolher usar JavaScript não deve ser uma decisão tomada de ânimo leve e pode ser um fator decisivo para uma equipe de desenvolvimento que não deseja aprender ou não tem interesse em usar JavaScript.

Prós

Desempenho superior aos híbridos . Como se poderia esperar, os não-híbridos têm inerentemente um desempenho mais alto do que os aplicativos híbridos devido à sua capacidade de renderizar o aplicativo usando componentes de interface do usuário nativos (botões, visualizações, gerenciadores de layout, etc.) em vez de depender de uma visualização da Web incorporada. Claro, os desenvolvedores ainda são livres para escrever um aplicativo que tenha um desempenho notável ou horrível. O benefício de aplicativos não híbridos é simplesmente que eles têm uma linha de base de desempenho mais alta quando comparados a aplicativos híbridos semelhantes.

Equipe de desenvolvimento mínima . Semelhante às estruturas híbridas, as não híbridas permitem que uma pequena equipe de desenvolvimento – e particularmente aquela cuja base de conhecimento principal é o desenvolvimento da Web – produza rapidamente aplicativos simples em várias plataformas. Isso permite que os gerentes de projeto mantenham sua equipe pequena e impeçam que a equipe aprenda as linguagens e estruturas nativas para várias plataformas.

Ciclo de desenvolvimento mais rápido . Além de uma equipe menor, os frameworks não híbridos proporcionam um ciclo de desenvolvimento mais rápido ao implantar em várias plataformas, pois apenas uma única camada de visualização precisa ser projetada.

Iterações mais rápidas (React) . O framework React fornece um recurso poderoso que permite que as alterações no aplicativo sejam renderizadas em tempo real: não há necessidade de recompilar, reconstruir, etc. Como resultado, o emulador React é uma ferramenta de desenvolvimento incrivelmente poderosa que reduz drasticamente a duração de cada implementação ciclo.

Contras

Caro para personalizar . Muito parecido com sua contraparte híbrida, quando aplicativos não híbridos exigem que o UX seja aprimorado projetando UIs personalizadas para cada plataforma, isso resulta em componentes de UI complexos e exclusivos que podem ser caros para criar e difíceis de manter ao longo do tempo. Isso também significa escrever componentes de ponte personalizados para complementar as lacunas no suporte a elementos nativos da estrutura. Como os híbridos, esse custo diminui o benefício de um ciclo de design rápido e barato, mas, diferentemente dos aplicativos híbridos, os componentes de ponte são escritos para cada plataforma desejada em seu idioma nativo . Isso significa que, em vez de aplicativos não híbridos serem uma alternativa flexível a uma equipe composta principalmente por desenvolvedores da Web, as equipes que escolhem o caminho não híbrido precisam aprender não apenas a linguagem específica do framework (por exemplo, JSX ou C#), mas também também o idioma nativo de cada plataforma (Java, Obj-C ou Swift).

Dependências de terceiros . Essa limitação assume duas formas diferentes. No caso do React Native, ele assume a forma de inúmeras dependências, ou seja, aproximadamente 650. O resultado é que há uma chance muito boa em qualquer momento específico de que uma ou mais dessas dependências estejam desatualizadas. Isso também significa que, no caso de uma grande alteração no nível do SO, há uma alta probabilidade de que a maioria ou todas essas dependências precisem ser atualizadas. A graça salvadora potencial é que o Facebook usa React, então um terá o gorila de 300 libras em seu canto.

No caso do Xamarin, o problema de dependência de terceiros é simplesmente que é extremamente difícil integrá-los em primeiro lugar. O Xamarin está ciente desse problema e fornece uma ferramenta de utilitário chamada Sharpie. O objetivo da ferramenta é ajudar em parte da integração, mas, infelizmente, o Sharpie muitas vezes tenta compilar e vincular recursos incorretos, o que força o desenvolvedor a realizar a tarefa demorada de modificar manualmente os parâmetros de compilação de baixo nível para concluir com êxito a integração.

Atraso no suporte do SO . Os aplicativos não híbridos são afetados pelo mesmo problema que os híbridos. Qualquer framework intermediário que está fora do controle do desenvolvedor e que deve ser atualizado primeiro serve apenas para atrasar o processo de atualização de um aplicativo para suportar usuários de ponta. Além disso, como dito anteriormente, confiar em uma estrutura intermediária pode ser uma dor de cabeça para os gerentes de projeto planejarem, já que o tempo dessas estruturas é tão desconhecido.

Suporte de longo prazo (React Native) . Esse problema é específico do React Native e se refere ao estranho fato de que, até o momento, o Facebook não se comprometeu com um plano de suporte de longo prazo para sua estrutura. Pode-se dizer que este é um risco baixo, já que a empresa utiliza seu próprio framework para seus aplicativos móveis, mas vale uma pausa para qualquer gerente de projeto considerar por que o Facebook se recusou a comentar o assunto.

Escolhendo a abordagem certa

Quando o custo não é a principal consideração, a Figura 2 mostra que escrever aplicativos nativos é quase sempre a melhor escolha ao aproveitar a composição da equipe de desenvolvimento em relação aos requisitos do aplicativo. Quando há menos engenheiros de desenvolvimento do que o número de plataformas desejadas, fica um pouco mais interessante. Nesse caso, usar o React é a escolha correta se a equipe estiver com um cronograma de lançamento muito apertado; caso contrário, tornar-se nativo ainda é a melhor opção.

Quando a equipe é principalmente uma equipe de desenvolvimento da Web e é necessário um UX personalizado, é melhor que alguns membros da equipe mudem de chapéu ou adicionem alguns membros da equipe para tornar os aplicativos nativos. Não há realmente uma opção de estrutura viável e sustentável se um aplicativo exigir elementos personalizados, o que muitos aplicativos exigem.

No entanto, se um UX personalizado não for necessário, dependendo do cronograma de lançamento, pode ser melhor usar o Ionic ou o React. Se a equipe não tem tempo para aprender JSX, então o Ionic é a escolha certa. Caso contrário, é melhor escolher o React, pois ele já requer muitas dependências de terceiros e adicionar mais não afetará o ciclo de desenvolvimento de alguém.

Uma vez que o custo do projeto é a principal preocupação, normalmente, a composição da equipe existente torna-se menos prioritária, pois o primeiro passo seria colocar a equipe adequada para executar o plano do projeto para o custo projetado. Conforme mostrado na Figura 3 , os aplicativos nativos têm um custo inicial mais alto do que seus equivalentes WODE, mas também um UX de maior potencial. Além disso, os aplicativos WODE sempre serão limitados em seu UX, independentemente de quanto dinheiro e recursos sejam aplicados ao projeto.

Espero que este artigo tenha lançado alguma luz sobre os prós e contras de vários caminhos de desenvolvimento móvel, bem como ajudado a avaliar a composição da equipe em relação aos requisitos do aplicativo e ao custo do projeto. Sua mensagem não era transmitir que os frameworks WODE são inferiores e nunca devem ser procurados, mas sim que, embora existam casos de uso válidos para não se tornar nativo, deve-se entender completamente as ramificações de fazê-lo.