Desenvolvimento de aplicativos multiplataforma em 2020: as melhores estruturas a serem consideradas

Em seus 12 anos de existência, os aplicativos móveis percorreram um longo caminho.

Em 2008, havia apenas 500 deles. Hoje, há mais de cinco milhões. (1)

Independentemente de o comercial da Apple de 2009 “Há um aplicativo para isso” ser um mantra de marketing ou uma profecia real, uma coisa é certa: a maneira como nos comunicamos e vivenciamos o mundo ao nosso redor mudou completamente na última década; uma mudança de estilo de vida em grande parte atribuída aos pequenos quadrados organizados em nossas telas.

Tanto que, na verdade, essa vida orientada por aplicativos que passamos a levar nos faz verificar nossos telefones 58 vezes por dia, sendo que 90% desse tempo é gasto no uso de aplicativos. (2, 3)

Naturalmente, empresas grandes e pequenas seguiram de perto a tendência móvel, entendendo que um aplicativo próprio aumenta sua visibilidade, cultiva a fidelidade do cliente e melhora seus resultados.

Em todo o mundo, projeta-se que a receita de aplicativos móveis (downloads pagos, compras no aplicativo e publicidade) chegue perto de US$ 600 bilhões, com expectativa de aumento, já que ter um aplicativo comercial está se tornando uma norma para qualquer empresa em ascensão. (4)

Portanto, os aplicativos não são apenas muito procurados, mas podem ser altamente lucrativos. No entanto, quando se trata de criar um aplicativo nativamente para Android e iOS, os altos custos de desenvolvimento e os lentos tempos de implementação podem exercer uma enorme pressão até mesmo sobre as equipes mais ambiciosas.

A boa notícia é que há uma maneira de contornar isso.

Uma base de código para governar todos eles: prós e contras do desenvolvimento móvel multiplataforma

Se você está de olho no cenário de desenvolvimento de aplicativos, já deve ter ouvido falar deles: Xamarin, React Native, Flutter, Cordova e similares.

Ao longo dos anos, essas estruturas satisfizeram os desejos das empresas que queriam alcançar os usuários de smartphones das plataformas iOS e Android (que representam 98% do mercado de sistemas operacionais móveis), sem realmente desenvolver dois aplicativos separados para cada sistema operacional. (5, 6)

Ao fazer isso, eles conseguiram se beneficiar:

• A mesma acessibilidade com metade do esforço. Um dos maiores benefícios que o desenvolvimento de aplicativos entre plataformas oferece é a facilidade de reutilização do código. Em vez de lançar vários aplicativos nativos para cada plataforma, você pode reutilizar uma quantidade significativa de código e ter o mesmo aplicativo implantado em várias plataformas.
• Redução de custos. Como o código é escrito uma única vez, a equipe de desenvolvimento terá que se esforçar metade do tempo, o que se traduz em custos reduzidos de produção, manutenção e contratação. A necessidade de aprender uma linguagem específica de plataforma também é reduzida, pois a fluência em JavaScript, C++, C# e HTML5 será suficiente, na maioria dos casos, para o desenvolvimento entre plataformas.
• Menor tempo de lançamento no mercado. Menos trabalho também significa tempos de implementação mais rápidos. Consequentemente, menos tempo gasto no desenvolvimento significa que você pode agregar valor aos seus clientes mais rapidamente e ajustar seus aplicativos de acordo com o feedback deles mais cedo.
• Sensação quase nativa. Apesar das diferenças substanciais de UX e UI entre o iOS e o Android, os aplicativos multiplataforma podem emular a sensação nativa ao lidar com as incompatibilidades de design e navegação por padrão.

Esses benefícios parecem bons demais para ser verdade. Por que alguém seguiria o caminho nativo e criaria dois aplicativos separados para ambas as plataformas quando você poderia obter a mesma acessibilidade fazendo metade do trabalho?

Acontece que há vários motivos, inclusive:

• Barreira do idioma. Um dos principais desafios do desenvolvimento de aplicativos multiplataforma é o fato de os desenvolvedores estarem escrevendo um aplicativo em uma linguagem não nativa. Isso significa que eles não terão o mesmo acesso aos componentes nativos simplesmente porque o código foi escrito em uma linguagem de nível superior. Para fazer a ponte entre os dois, eles precisam contar com bibliotecas de terceiros específicas para cada estrutura e, quanto mais nova for a estrutura, mais escassa será a biblioteca.
• Discrepância de UX. Como o Android e o iOS têm interfaces gráficas de usuário muito específicas (navegação, botões, menus etc.), é necessário mais esforço para obter uma sensação nativa para cada plataforma. Às vezes, o trabalho necessário para que isso aconteça supera os benefícios listados acima.
• Problemas de desempenho. O desempenho é outro problema conhecido e, embora as diferenças sejam, em sua maioria, mínimas, o desenvolvimento de um jogo para celular com o Flutter ou o React Native não será compatível com a tecnologia nativa.
• Tamanho. Dependendo da estrutura, a vinculação de código e os plug-ins de terceiros podem quase dobrar o tamanho do arquivo do seu aplicativo multiplataforma. E, como você pode imaginar, os aplicativos maiores não são tão apreciados quanto seus equivalentes mais leves. Eles não apenas exigem mais espaço de armazenamento no dispositivo do usuário, mas também levam mais tempo e dados para serem baixados. De fato, o Google Play Apps & Games publicou um relatório mostrando que um aplicativo de 100 MB receberá cerca de 30% menos downloads do que um aplicativo que pesa cerca de 10 MB.
• Seu público-alvo. Por fim, talvez você só precise atender a usuários do Android ou do iOS e, nesse caso, a opção nativa faria todo o sentido. A linguagem de programação agora é totalmente compatível com a plataforma e o dispositivo, o que significa que o seu desenvolvedor não precisará buscar o plug-in de giroscópio para o Cordova.

Você pode ver agora como o desenvolvimento de plataforma cruzada não é um mar de rosas. Muita coisa pode dar errado e cabe a você decidir se essa é uma abordagem válida para o seu projeto.

Ainda assim, para a grande maioria das empresas (como Facebook, Google e eBay), a abordagem de desenvolvimento entre plataformas provou ser um método econômico e confiável para a criação de aplicativos.

Vamos avaliar algumas das principais estruturas em 2020 e ver onde elas se destacam e onde ficam aquém.

React Native: escreva uma vez, implemente em qualquer lugar

Fundado pelo Facebook em 2015, o React Native se consolidou rapidamente como uma das estruturas de desenvolvimento multiplataforma mais populares entre os desenvolvedores.

O principal fator por trás de seu uso em larga escala é a linguagem de programação da estrutura, JavaScript, que é usada em 95% dos 1,7 bilhão de sites do mundo. (7, 8)

Isso significa que um desenvolvedor que já tenha criado um site usando JavaScript não enfrentará uma curva de aprendizado acentuada ao trabalhar em um aplicativo multiplataforma no React Native.

Outra grande vantagem do React Native é sua capacidade de imitar com sucesso a sensação nativa de um aplicativo. Embora não inclua muitos componentes de interface do usuário prontos para uso, há uma abundância de componentes de terceiros que proporcionam uma experiência nativa suave.

O problema é que, quando você depende muito de bibliotecas externas, pode estar trocando uma sensação nativa por um desempenho mais lento. Como o React Native requer uma ponte para seus wrappers nativos, você pode acabar com um aplicativo que tem muitas chamadas nativas, causando problemas de desempenho.

Cordova: o WebView vale a pena?

Assim como o React Native, o Cordova é uma opção atraente para os desenvolvedores da Web que se convenceram da ideia de reutilizar suas habilidades existentes em HTML, CSS e JS para criar um aplicativo para Android e iOS.

No papel, o Cordova parece um sonho. Há várias ferramentas e bibliotecas que facilitam a sua vida – o Ionic, por exemplo, é ótimo para lidar com a interface do usuário e integrar serviços adicionais, como biometria de impressões digitais e processamento de pagamentos, ao seu aplicativo.

Mas tenha cuidado antes de você entrar no vagão do Cordova. Se você não estiver ciente dos limites da estrutura (e dos seus próprios limites), esse sonho pode rapidamente se transformar em um pesadelo.

Em primeiro lugar, não faria sentido escrever um jogo sério ou um aplicativo pesado com o Cordova. Ao contrário do React Native, que chama as funcionalidades nativas por meio de uma ponte, o Cordova renderiza o código em um WebView, e a execução de um aplicativo dessa forma não só pode causar uma perda significativa de desempenho, como também torna o aplicativo propenso a ataques XSS.

É provável que você também gaste algum tempo em soluções alternativas para bugs específicos da plataforma. Às vezes, esse processo envolve uma boa dose de frustração, pois as funcionalidades nativas que você sempre considerou garantidas agora precisam ser corrigidas com plug-ins que exigem personalização ou, pior, desenvolvimento do zero.

Para aplicativos pequenos e simples, o Cordova é uma opção que vale a pena para você. Aplicativos de estilo de vida, notícias, eventos, educacionais e de mensagens, por exemplo, foram e podem ser facilmente criados com o Cordova, que, no momento em que este artigo foi escrito, ocupava 7,88% do mercado. ocupa 7,88% da participação no mercado de aplicativos.

Mas se você estiver desenvolvendo um jogo com muitas animações, considere usar a abordagem nativa. Você perderá mais tempo descobrindo as soluções alternativas relacionadas do que economizando ao escrever uma única base de código.

Xamarin: o OG de plataforma cruzada

O Xamarin foi um dos primeiros frameworks de código aberto lançados com o objetivo de unir plataformas nativas e tornar o desenvolvimento móvel menos dispendioso.

E, embora a Xamarin tenha sido lançada em 2011, foi somente após sua aquisição pela Microsoft em 2016 que a comunidade de desenvolvimento finalmente começou a lhe dar alguma credibilidade e tração.

Hoje, ele é uma das estruturas de desenvolvimento entre plataformas mais usadas, com mais de 60.000 colaboradores de mais de 3.700 empresas. (9)

Baseado em C#, uma linguagem de programação orientada a objetos, o Xamarin é considerado por muitos como mais difícil de aprender do que o React Native, embora o código funcione perfeitamente em várias plataformas, incluindo Android, iOS, tvOS, watchOS, macOS e Windows.

Além disso, os desenvolvedores estão equipados com todas as ferramentas necessárias para criar seu aplicativo multiplataforma por meio do .NET, incluindo APIs, pacotes e XAML específicos da plataforma.

Agora, você pode escolher entre dois caminhos ao criar um aplicativo no Xamarin, sendo que ambos permitem níveis de desempenho quase nativos.

1. O Xamarin Native oferece uma abordagem de baixo nível para a criação de aplicativos separados para cada plataforma com as bibliotecas Xamarin.iOS e Xamarin.Android. É uma base para expor algumas funcionalidades nativas ao Xamarin Forms chamando APIs específicas da plataforma.
   
2. O Xamarin.Forms é uma estrutura sobre o Xamarin Native com todas as funcionalidades do Xamarin. É uma opção melhor para quem está começando a usar o Xamarin, pois os desenvolvedores podem reutilizar até 96% do código e os proprietários de produtos podem dimensionar e manter seus aplicativos com mais facilidade.

Flutter: o novo garoto do pedaço

Ao contrário do React Native e do Xamarin, o Flutter é uma estrutura que existe há apenas alguns anos.

No entanto, apesar de ser um novato no mercado, o Flutter causou um choque na comunidade desde seu lançamento pelo Google em 2018, provando ser um concorrente confiável e inovador.

Sua linguagem de programação, Dart, pode não ser tão popular quanto o JavaScript, mas é relativamente fácil de aprender; por um lado, grande parte da sintaxe é semelhante à do Swift, Kotlin e Java, o que significa que os desenvolvedores com experiência em C/C++ não terão muita dificuldade em mudar para essa forma orientada a objetos de criar aplicativos.

E mesmo que você encontre alguns obstáculos no caminho, o Flutter fornece uma extensa documentação para apoiar sua transição.

Em seguida, vem a arquitetura do Flutter, que, em comparação com o React Native, não depende do JavaScript Bridge para traduzir as chamadas para a API nativa. O código escrito em Dart é compilado em código de máquina nativo, resultando em um desempenho mais suave e aprimorado do aplicativo e em uma melhor experiência do usuário.

No entanto, a maneira do Flutter de se comunicar diretamente com a plataforma usando sua própria biblioteca de componentes incorporados não é ideal. É difícil encontrar plug-ins de terceiros e as APIs específicas de hardware não são tão abundantes quanto as do React Native, o que torna o Flutter uma opção inferior para aplicativos dependentes de hardware.

Também vale a pena mencionar o fato de que o mecanismo C/C++ e o Dart são bastante volumosos e, embora os aplicativos criados no Flutter possam ser executados melhor, eles ocuparão muito espaço.

Ainda assim, os widgets que você recebe prontos para uso são totalmente personalizáveis e, combinados com o recurso de hot reloading, fazem do Flutter uma estrutura ideal para desenvolver um aplicativo MVP com uma interface de usuário personalizada e perfeita em termos de pixels.

Qual estrutura você deve escolher?

Bem, a resposta a essa pergunta dependerá em grande parte das metas que você definiu para alcançar com seu aplicativo, bem como do tempo e do orçamento que você pode alocar para sua produção e manutenção.

Seja qual for a abordagem que você escolher – nativa, multiplataforma ou até mesmo uma combinação das duas -, o celular não vai a lugar nenhum. Pelo contrário, espera-se que passemos uma média de 3,7 horas em nossos smartphones por dia este ano, um aumento de 10% em relação ao ano anterior e um crescimento de 35% em relação a 2017. (10)

Seja qual for a maneira que você decidir criar seu aplicativo, tenha certeza de que o Microblink estará lá para apoiá-lo quando você precisar de uma solução de digitalização poderosa e perfeita integrada a ele.