Escreva uma vez, implante em todos os lugares (WODE) tem sido a promessa de muitos frameworks 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 alto custo inicial, ao impacto na equipe de desenvolvimento e à impossibilidade de reversão.

Soluções híbridas, como Iônico alavancar tecnologias da web para renderizar aplicativos em plataformas, mas muitas vezes, o produto final fica aquém das expectativas do usuário de um nativo aparência e sensação.

No entanto, até mesmo o termo 'nativo' foi recentemente turvado por estruturas que compilam para o código nativo (por exemplo, React Native , Xamarin , etc.).

Este artigo analisa os prós e os 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 Escreva uma vez, implante em qualquer lugar refere-se à capacidade de uma equipe de desenvolvimento de escrever um aplicativo uma vez - usando uma única pilha de desenvolvimento, abstrato da (s) plataforma (s) em que o aplicativo será implantado - e ainda manter a capacidade de implantar o aplicativo em todas as plataformas desejadas, por exemplo , Android, iOS, Windows, etc. Idealmente, isso é realizado sem sacrificar a capacidade de manutenção, desempenho ou 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
• Linha do tempo necessária 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, este 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 alto nível, os diferentes caminhos de desenvolvimento móvel podem ser colocados em duas categorias: nativo ou WODE, ou seja, nativo ou tudo o mais. Simplificando, ou alguém escreve um aplicativo nativo ou não. A categoria WODE é subdividida em dois grupos:

• Estruturas híbridas - aqueles que aproveitam as tecnologias da web para renderizar aplicativos em várias plataformas.
• Estruturas não híbridas - aqueles que usam componentes de IU 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 as estruturas híbridas fazem.

A maioria dos frameworks WODE são híbrido ; no entanto, para melhorar o desempenho e as limitações de UX dos frameworks híbridos, ao mesmo tempo em que fornece os benefícios de um framework WODE, a tendência atual é de não híbrido . Devido a essa tendência, frameworks 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 analisa os prós e contras de cada caminho de desenvolvimento móvel ao considerar as 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 você paga ”Se aplica, portanto, se o custo for mais importante do que a experiência dos clientes, 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 certa, 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 propósito de escolher um não-nativo caminho de desenvolvimento em primeiro lugar.

Além disso, mesmo se esse custo for pago, o produto final baseado em WODE sempre entregará um UX inferior em comparação com sua contraparte nativa. Como resultado, 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 central da plataforma fornecida. 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 . Uma vez que cada aplicativo é escrito utilizando componentes nativos, a única limitação para customização é a interface com as estruturas subjacentes, e às vezes nem isso. Como a maioria dos engenheiros de desenvolvimento nativos atestará, geralmente há uma maneira de realizar uma determinada tarefa, apesar de uma interface limitada.

Uma simples prova 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 inteira, acima de todos os elementos externos da interface do usuário, por exemplo, um Barra de abas , barra de navegação, etc. Conforme mostrado em figura 1 , isso normalmente está fora do escopo da camada de IU normal que está sendo apresentada no momento. Como tal, para ter uma sobreposição de tela inteira, ela deve ser adicionada à camada oculta acima da barra de guias na pilha de exibição. Esse tipo de personalização normalmente só é possível em aplicativos nativos.

Maior 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, eles são executados mais lentamente do que um aplicativo nativo.

Mais fácil de manter . Os sistemas operacionais mudam constantemente. Período. Quando o fizerem, dependendo se foram feitas alterações significativas, 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 o momento em que a mudança é disponibilizada para os usuários e um aplicativo é atualizado, melhor. Esse tempo é minimizado quando não há dependências que precisem ser atualizadas para dar suporte a esse novo SO, o que ocorre quando se trabalha 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 requer 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 no que diz respeito ao suporte e colaboração.

Ciclo de desenvolvimento mais lento . Os 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.

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

Nota: Em geral, isso se aplica a todos caminhos da estrutura (nativos, híbridos e não híbridos). Se os engenheiros que estão desenvolvendo um aplicativo não tiverem habilidades suficientes para o que estão tentando fazer, o aplicativo resultante provavelmente não atenderá aos requisitos de design nem será bem aceito pelos usuários.

Aplicações Híbridas

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 - de preferência, usando um Estrutura JavaScript MVC, como AngularJS . O uso de uma estrutura como 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 por AngularJS, que é finalmente convertida e renderizada em uma visualização da web na plataforma desejada usando PhoneGap e Cordova. Obviamente, esse tipo de estrutura WODE tem um 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 idioma; no entanto, como gerente de projeto, a escolha de usar JavaScript em uma pilha técnica móvel não deve ser feita levianamente. 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 nativo do React

Prós

Equipe mínima de desenvolvimento . As estruturas 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 um gerente de projeto mantenha sua equipe pequena, bem como elimine a necessidade de sua equipe aprender as linguagens nativas e estruturas para plataformas múltiplas.

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 implementar em várias plataformas, uma vez que 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 camada de visualização única é que resta uma camada de visualização única. Isso pode resultar em uma UX pobre, uma vez que uma abordagem de tamanho único para o design da IU 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 embutida na IU, pode dar aos usuários a impressão de que 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 instância, na retenção.

Caro personalizar . Melhorar a UX com o design de UIs personalizadas para cada plataforma resulta em estruturas de UI complexas e exclusivas que podem ser caras de criar e difíceis de manter ao longo do tempo. Além disso, a fim de 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 de usuário de alto nível em algo que a estrutura de nível inferior , como Cordova, vai entender. Em geral, quanto mais personalizamos e aprimoramos a UX de um aplicativo híbrido, mais isso diminui o benefício de um ciclo de design rápido e barato.

Desempenho inferior . Uma vez que os aplicativos híbridos renderizam as visualizações do aplicativo em uma webview, há um grande potencial para cometer erros de implementação ao lidar com estruturas de sistema operacional (por exemplo, rede, Bluetooth, contatos no dispositivo, etc.), o que resulta em desempenho muito degradado. Também é importante notar que, mesmo que muito cuidado seja tomado com relação ao desempenho, já que tudo é exibido por meio de uma webview, o desempenho máximo dos aplicativos híbridos sempre será um pouco menor do que seus equivalentes nativos.

Gerenciamento não trivial de plugins . Lembra-se daqueles recursos personalizados que a equipe de design passou semanas aprimorando, seguidos por mais algumas semanas enquanto a equipe de desenvolvimento criava os componentes de ponte necessários para que 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 própria equipe o cria ou um plug-in de terceiros adequado precisa ser encontrado para fazer o trabalho. Infelizmente, na maioria das vezes, a opção dois não existe. Como resultado, requer tempo de desenvolvimento adicional para criar os plug-ins customizados, seguido por esforço de suporte de construção - ao longo do tempo - para gerenciar a biblioteca crescente de plug-ins Cordova exigidos pelo aplicativo. É claro que, quando ocorrem atualizações do Cordova, há uma grande probabilidade de que esses plug-ins também precisem ser atualizados.

Atraso de suporte do sistema operacional . O problema do componente de ponte em cascata / plug-in Cordova mencionado anteriormente é ainda mais exacerbado quando o sistema operacional muda a funcionalidade principal. Depois que Cordova, PhoneGap e Ionic foram atualizados para suportar as mudanças, é 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 um tempo adicional durante o qual o aplicativo não oferece suporte aos usuários finais que atualizaram para o novo sistema operacional. Este, é claro, é o pior cenário em que alterações interrompidas e não compatíveis com versões anteriores são feitas pela Apple ou Google, o que nunca acontece ... certo? Em geral, qualquer estrutura intermediária que está fora do controle do desenvolvedor e que deve ser atualizada primeiro serve apenas para atrasar o processo. Finalmente, confiar em uma estrutura intermediária pode ser uma dor de cabeça para os gerentes de projeto planejarem, uma vez que o tempo dessas estruturas é desconhecido.

Aplicativos não híbridos

Os aplicativos não híbridos começam a vida como seus equivalentes híbridos - 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 termina a semelhança. Os aplicativos não híbridos são compilados em código nativo e renderizam o aplicativo usando componentes nativos da plataforma em vez de renderizar por meio de um webview. Isso resulta em uma estrutura WODE que, pelo menos na superfície, tem o melhor dos dois mundos.

Conforme discutido anteriormente, a escolha de usar JavaScript não deve ser uma decisão tomada levianamente e pode ser um obstáculo para uma equipe de desenvolvimento que não deseja aprender ou não tem interesse em usar JavaScript.

Prós

Maior desempenho do que híbridos . Como se poderia esperar, os não híbridos têm inerentemente um desempenho superior do que os aplicativos híbridos devido à sua capacidade de renderizar o aplicativo usando componentes de UI nativos (botões, visualizações, gerenciadores de layout, etc.) em vez de depender de uma visualização da web incorporada. É claro que os desenvolvedores ainda estão livres para escrever um aplicativo com desempenho notável ou horrível. O benefício dos 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 mínima de desenvolvimento . Semelhante a estruturas híbridas, os não híbridos 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 a equipe de aprender os idiomas nativos e estruturas para plataformas múltiplas.

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

Iterações mais rápidas (React) . A estrutura React fornece um recurso poderoso que permite que as alterações no aplicativo sejam renderizadas em tempo real: sem 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 personalizar . Muito parecido com sua contraparte híbrida, quando os aplicativos não híbridos exigem que a UX seja aprimorada com o design de 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 de elemento nativo da estrutura. Como os híbridos, esse custo diminui o benefício de um ciclo de design rápido e barato, mas, ao contrário dos aplicativos híbridos, os componentes da ponte são escritos para cada plataforma desejada em sua língua nativa . Isso significa que, em vez de aplicativos não híbridos serem uma alternativa flexível para 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 da estrutura (por exemplo, JSX ou C #), mas também a linguagem nativa de cada plataforma (Java, Obj-C ou Swift).

Dependências de terceiros . Essa limitação assume duas formas diferentes. No caso do React Native, assume a forma de numeroso dependências, ou seja, cerca de 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 sistema operacional, há uma grande probabilidade de que a maioria ou todas essas dependências precisem ser atualizadas. A possível graça salvadora é que o Facebook usa React, de modo que se terá o gorila de 300 libras ao seu lado.

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 utilitária chamada Sharpie. O objetivo da ferramenta é ajudar com parte da integração, mas, infelizmente, o Sharpie freqüentemente 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 sucesso a integração.

Atraso de suporte do sistema operacional . Os aplicativos não híbridos são afetados pelo mesmo problema que os híbridos. Qualquer estrutura intermediária que está fora do controle do desenvolvedor e que deve ser atualizada primeiro serve apenas para atrasar o processo de atualização de um aplicativo para oferecer suporte a usuários de ponta. Além disso, como afirmado antes, confiar em uma estrutura intermediária pode ser uma dor de cabeça para os gerentes de projeto planejarem, uma vez que o tempo dessas estruturas é 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 esse é um risco baixo, já que a empresa utiliza seu próprio framework para seus aplicativos móveis, mas vale a pena fazer uma pausa para qualquer gerente de projeto considerar porque o Facebook se recusou a comentar sobre o assunto.

Escolhendo a abordagem certa

Quando o custo não é uma consideração primária, 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 web e uma UX personalizada é necessária, é melhor ter alguns membros da equipe mudando de chapéu ou adicionar alguns membros da equipe para tornar seus aplicativos nativos. Realmente não há uma opção de estrutura viável e sustentável se um aplicativo requer elementos personalizados, o que muitos aplicativos fazem.

No entanto, se um UX customizado não for necessário, dependendo da programação de lançamento, pode ser melhor ir com Ionic ou React. Se a equipe não tem tempo para aprender JSX, então Ionic é a escolha certa . Caso contrário, é melhor escolher React, pois 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 é uma preocupação principal, normalmente, a composição da equipe existente se torna menos prioritária, já que a primeira etapa seria colocar a equipe adequada no local para executar o plano do projeto para o custo projetado. Como mostrado em Figura 3 , os aplicativos nativos têm um custo inicial mais alto do que seus equivalentes WODE, mas também um UX potencial mais alto. Além disso, os aplicativos WODE sempre serão limitados em sua UX, independentemente de quanto dinheiro e recursos são aplicados no projeto.

Espero que este artigo tenha esclarecido os prós e os contras de vários caminhos de desenvolvimento para dispositivos móveis, bem como ajudado na ponderação da 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 deveriam ser procurados, mas sim que, embora existam casos de uso válidos para não se tornarem nativos, deve-se entender completamente as ramificações de fazer isso.

Compreender o básico

O que é uma estrutura de aplicativo móvel híbrido?

Uma estrutura WODE que não compila para o código nativo. Normalmente gera um aplicativo baseado em HTML / CSS renderizado em uma visualização da web no aplicativo.

Qual é a melhor estrutura para aplicativos móveis?

Depende principalmente de duas coisas: composição da equipe e requisitos de aplicação.

Qual é a melhor estrutura móvel híbrida?

Todas as estruturas móveis híbridas são inferiores em comparação ao desenvolvimento nativo ou não híbrido.

Qual é a diferença entre nativo e híbrido?

O híbrido é mais fácil de desenvolver, o custo geral do desenvolvimento do híbrido tende a ser menor, mas isso tem um preço, pois o desempenho e o UX são degradados.

Um aplicativo nativo é melhor do que um híbrido?

O desempenho aprimorado e a UX aprimorada têm o custo de aumentar o tempo de desenvolvimento e membros da equipe especializados.