Desenvolvimento

10 mai, 2016

Nativo x Híbrido – A discussão final – Parte 02

Publicidade

Há alguns dias, eu comecei a falar sobre alguns embates existentes no mundo mobile. Se você não acompanhou, o primeiro artigo foi sobre web e mobile web x aplicativos, depois eu comecei a falar sobre apps híbridos e nativos x cross-platform, evidenciando os pontos relacionados à complexidade e custo de desenvolvimento. Hoje, vou falar um pouco sobre como a experiência do usuário, performance e plataforma influenciam também nessa questão. Vamos lá?

A experiência do usuário

Um ponto essencial a ser abordado nessa discussão de nativo versus híbridos ou cross-platform é a experiência do usuário. A Apple, por exemplo, é a empresa que efetivamente iniciou o movimento de facilitar a usabilidade em smartphones e sempre prezou pela experiência e design centrados no usuário. Seus produtos sempre foram classificados em alta estima, afinal o iPhone é um dos produtos tecnológicos mais complexos desse século e vem sem manual de uso.

A adoção em larga escala desses dispositivos pelo público em geral mostra que é necessária a simplificação e facilitação da experiência que o usuário tem com os aplicativos. Pequenos cuidados devem ser levados em consideração, tanto no modelo híbrido como no modelo nativo, com a qualidade da experiência quando a conexão deixa de estar disponível ou como lidar com aplicativos muito grandes.

Outro ponto polêmico relativo à experiência do usuário e à interface do usuário no seu aplicativo, seja híbrido ou não, é se devemos aderir ou não aos guidelines específicos da plataforma (iOS, Android ou Windows Phone). Nesse contexto, atualmente existem três variações e tendências aceitas pelo mercado:

1. Abordagem orientada à marca

Se o seu produto ou marca é grande, você provavelmente tem peso o suficiente para ter os seus próprios guidelines, identidades visuais e outros artifícios para fortalecer o seu posicionamento online e offline. Essa costuma ser uma abordagem eficiente do ponto de vista de design, mas tem impactos fortes no processo de desenvolvimento, muitas vezes culminando em componentes customizáveis que tendem a aumentar o TCO do produto no médio/longo prazo. Os aplicativos do Itaú seguem esse modelo, por exemplo, assim como o Instagram.

2. Abordagem orientada à plataforma

Nessa abordagem, os apps para uma plataforma são bastante distintos das outras. É o caso do aplicativo da Apple Music para Android e do seu irmão mais velho, o Apple Music para iOS.  Outro player que segue o mesmo modelo é o Telegram ou o Whatsapp. O aplicativo usa e é baseado nos guidelines de ambas as plataformas. As vantagens são a familiaridade que o usuário já possui com a experiência nativa do seu dispositivo, o reuso de componentes nativos do sistema e a garantia de consistência de uso entre diversos aplicativos no celular do seu usuário.

3. Abordagem mista

Aqui a experiência e o design dos apps utilizam um pout pourri do que é melhor e mais conveniente em ambos os approaches anteriores e acaba criando uma experiência com elementos familiares, mas não restritos. Soundcloud, Facebook, AirBnb e outros seguem essa abordagem.

E o que híbrido versus nativo tem a ver com isso tudo? É que até muito pouco tempo atrás era muito difícil garantir, de forma consistente, a liberdade para ajustar a experiência do seu produto usando desenvolvimento híbrido e atender todas as necessidades do seu negócio e do usuário. Entretanto, frameworks como Ionic endereçam esse problema, e devemos ver muita evolução nesse sentido nos próximos anos.

Uma parte pertinente desse tema é o seu impacto na taxa de conversão. Afinal, uma experiência menos otimizada inevitavelmente leva a uma taxa de conversão menor. Se a sua ferramenta de escolha para o desenvolvimento potencialmente pode impedir a sua capacidade de otimizar a sua taxa de conversão, esse assunto deve ser bem discutido, principalmente se a sua estratégia de produto depender disso.

Performance, performance, performance…

Outro ponto importante, tanto tecnicamente quanto do ponto de vista de produto, é a performance. Enquanto aplicativos nativos podem utilizar em sua integridade a capacidade dos hardwares, aplicativos híbridos baseados em webviews ainda são penalizados por questões técnicas dos padrões HTML e suas principais engines.

Enquanto o seu produto estiver pelo menos uma camada distante, a sua efetividade em obter mais performance e melhorar a taxa de conversão sempre vai estar atrelada à performance oferecida por uma webview ou à velocidade de parsear um DOM HTML.

Plataforma

Se vamos falar de desenvolvimento nativo é importante pontuar que a batalha pela soberania em termos de plataforma mobile já não existe mais. Temos dois claros ganhadores, um runner-up e algumas apostas para o futuro. Ou seja, quando você pensa em dispositivos smartphones, o mercado está claramente dividido entre iOS e Android, sendo que esse último cobre de 75% a 80% do mercado, o primeiro está entre 10% e 15% e o restante é dividido entre outros. O segundo lugar entre as plataformas mais populares no smartphone é ocupado pela web, e em terceiro temos os outros sistemas operacionais, encabeçados pelo Windows Phone da Microsoft.

As duas principais plataformas são suportadas por dois grandes players (Apple e Google), ambas com muito dinheiro para garantir que o seu desenvolvimento e evolução continuem de forma constante no médio prazo, o que significa que temos poucos indicativos de que elas desapareçam em um futuro próximo. Tanto quanto, ou mais importante ainda, é observar que ambas têm sido a força motriz da inovação em mobile nos últimos dez anos.

Outro ponto importante é que é a partir dessas plataformas que a maior parte dos usuários tem acesso às lojas de aplicativos, o que posiciona a Apple e o Google como gatekeepers de diversas iniciativas mobile. Quer fazer um aplicativo para concorrer com o Apple Pay? Primeiro você precisa garantir que ele vai ser aceito pela própria Apple em sua loja de aplicativos. Os motivos para rejeição são vários, mas o ponto é que, como a Apple e o Google são donos da maior parte do processo, eles podem legislar conforme sua vontade e seus objetivos de negócio.

Além disso, podemos dizer que Apple e Google estão ditando o futuro do mercado mobile quando decidem entrar no mercado de smartwatches e de carros, e é importante lembrar que eles possuem interesses distintos e bem específicos sobre o que significa desenvolver para as suas plataformas. O Android Wear, por exemplo, não permite o uso de webview, enquanto falta simplesmente o Safari para o Apple Watch. O próximo questionamento lógico está relacionado às novidades relacionadas a casas inteligentes, por exemplo, e o que significa estar “uma camada acima da plataforma” nesse sentido. Lembrando que as webviews são parte integrante de ambos os sistemas operacionais desde os seus primeiros releases e estão em constante evolução desde então.

Conclusão

Em resumo, nós na Concrete Solutions acreditamos que apenas o mindset de produto com equipes multidisciplinares, entregando valor para o usuário final de forma constante, rápida e eficiente vai garantir o seu lugar no mundo digital nos próximos anos.

Nós vimos essa mesma discussão acontecer quando a adoção de Flash para desenvolvimento de sites chegou às alturas e depois foi substituída pelo então “desenvolvimento nativo” usando HTML, com browsers mais potentes e maior padronização entre os navegadores, quando a briga entre as plataformas acalmou. Isso aconteceu também com a briga de flavours de sistemas UNIX, e o POSIX passou a ser adotado em diversos sistemas operacionais, garantindo alguma interoperabilidade. Acreditamos que estamos passando pelo mesmo no mundo mobile agora, e inevitavelmente teremos o resultado previsível.

Ufa! E assim terminamos a nossa série sobre os embates mobile. Já tomou sua decisão? Se você concorda com a gente, deixe seu comentário abaixo. Se não, deixe também! Vamos fomentar esse debate com argumentos relevantes.

Até a próxima!