Nativo, React Native ou web app: como escolher de verdade

A resposta curta é esta. Escolha pela distribuição e pela necessidade de hardware, não pela moda. Se o usuário chega por link ou QR code e não deve instalar nada, construa para a web. Se você precisa de presença real nas duas lojas de aplicativos e quer um time só mantendo um código só, construa com React Native. Se o produto depende de acesso profundo ao hardware, de relógio ou de integrações de saúde, construa nativo. Todo o resto deste guia é o raciocínio por trás dessas três frases.

A pergunta que decide

A maioria dos debates sobre tecnologia de apps começa no lugar errado: na tecnologia. O ponto de partida útil são duas perguntas sobre o seu produto. Primeira: como o usuário chega? Tocando num link que alguém compartilhou, escaneando um código na mesa, buscando numa loja de aplicativos ou abrindo algo já instalado na tela inicial? Segunda: o que o app realmente precisa do aparelho? Uma tela e uma conexão com a internet, ou a câmera, armazenamento offline, notificações push, localização em segundo plano, um relógio pareado?

Responda essas duas com honestidade e a escolha de plataforma quase se faz sozinha. O resto é orçamento e prazo, e os dois também decorrem das mesmas duas respostas.

Web e PWAs: o padrão subestimado

Se o usuário chega por link ou QR code, qualquer etapa de instalação é um muro entre ele e o seu produto. Ninguém em pé na mesa de um restaurante vai baixar um app para ler o cardápio. É por isso que o Smart Menu, o produto de cardápio digital da Cazullo, é um web app: o cliente escaneia o código e o cardápio simplesmente aparece, no idioma dele, com fotos, em segundos. Uma loja de aplicativos adicionaria atrito e subtrairia usuários.

A web moderna também vai mais longe do que muitos compradores imaginam. Um progressive web app, um PWA, pode ser fixado na tela inicial, funcionar offline e sincronizar quando a conexão volta. Um time de vendas em campo consegue rodar o dia inteiro num PWA offline-first sem ninguém tocar em loja de aplicativos, e a empresa publica atualizações na hora, sem fila de revisão e sem esperar o usuário atualizar. Para produtos que vivem num momento de navegador, a web não é a opção barata. É a opção correta.

React Native: um time, duas lojas

Às vezes a presença na loja é o produto. Um app de comércio comunitário que as pessoas buscam pelo nome, mantêm na tela inicial e abrem toda semana merece o lugar de app instalado. O problema clássico é o custo: construir o mesmo produto duas vezes, uma em Swift para iOS e outra em Kotlin para Android, significa dois times, dois códigos e cada funcionalidade paga em dobro.

O React Native resolve exatamente isso. Um código só, escrito por um time só, compila em apps de verdade para as duas lojas. É assim que a Cazullo Platform funciona: os apps white-label de comércio local são construídos com React Native e Expo, e um único código publica vários apps de marca, cada um com o próprio nome, na App Store e no Google Play. Quando uma funcionalidade sai, o app de cada marca recebe. Essa economia é impossível com dois códigos nativos e desnecessária para produtos que não levam o hardware ao limite.

Nativo: quando ele justifica o custo

O desenvolvimento totalmente nativo, Swift nas plataformas Apple ou Kotlin no Android, é o caminho mais caro, e às vezes vale cada centavo. O sinal é a profundidade da integração. Se o produto precisa de um app para Apple Watch, lê e grava dados de saúde pelo HealthKit ou depende de recursos da plataforma assim que são anunciados, uma camada multiplataforma vira atrito em vez de alavanca.

A Cazullo constrói em Swift nativo quando o produto nasce para o ecossistema Apple: quando o relógio, os dados de saúde e a integração fina com o aparelho são o produto, não um extra. Nessa situação, nativo não é símbolo de status. É a única ferramenta que alcança aquilo que você está vendendo.

Os motivos errados

• Escolher nativo por status: "empresa séria tem app nativo" é lógica de branding aplicada a uma decisão de engenharia, e pode dobrar o orçamento sem nenhum benefício visível para o usuário
• Escolher web só porque é mais barato, quando ser encontrado na loja de aplicativos É o plano de marketing: se o usuário busca a loja pelo nome, economizar não estando lá não é economia
• Reconstruir um produto web que funciona bem como app instalado sem nenhuma necessidade de aparelho por trás: um app que podia ter continuado site adiciona atrito de instalação, ciclos de revisão e atraso de atualização por nada

Checklist

• Como o usuário chega: por link e QR code, ou buscando numa loja de aplicativos?
• Uma etapa obrigatória de instalação perderia o usuário exatamente no momento em que ele queria você?
• O produto precisa de hardware que o navegador não alcança: relógio, dados de saúde, sensores em segundo plano?
• Você precisa estar presente e ser encontrado nas duas lojas desde o primeiro dia?
• Quantos códigos o seu time e o seu orçamento conseguem, honestamente, manter por anos?
• Com que frequência você vai publicar atualizações, e consegue tolerar a demora da revisão das lojas?
• O app precisa funcionar offline, e com que profundidade?
• Um PWA cobriria as necessidades de offline e tela inicial sem loja nenhuma?

Nossa recomendação final é simples. Comece pela web e fique nela enquanto servir ao seu usuário. Vá para React Native quando a presença na loja e a relação de app instalado importarem de verdade, e deixe um código só carregar as duas plataformas. Reserve o nativo para os produtos em que o próprio aparelho é o ponto. A melhor plataforma não é a mais impressionante. É aquela em que o seu usuário nunca precisa pensar.