Nativo ou multiplataforma: como decidimos

Uma das primeiras perguntas técnicas em um novo app é se devemos desenvolvê-lo duas vezes, uma para cada plataforma, ou uma única vez com um framework multiplataforma. Há opiniões fortes dos dois lados. Não começamos com um favorito. Começamos com algumas perguntas sobre o produto e sobre as pessoas que cuidarão dele.

As opções

Nativo significa criar o app para iOS em Swift e o app para Android em Kotlin, cada um com as ferramentas e os frameworks de interface da própria plataforma. Frameworks multiplataforma como React Native e Flutter permitem que uma única base de código rode em ambos. O Kotlin Multiplatform fica no meio do caminho: lógica de negócios compartilhada, com interfaces que podem ser compartilhadas ou escritas nativamente em cada lado.

Quando o nativo compensa o custo

O nativo faz sentido quando o app depende muito da plataforma: uso avançado de câmera ou áudio, widgets e apps para relógio, links diretos para recursos do sistema ou gráficos exigentes. Também ajuda quando o app precisa parecer totalmente natural em cada plataforma e usar novos recursos do sistema assim que forem lançados. O custo são duas bases de código, o que geralmente significa mais pessoas, mais tempo ou ambos.

Quando o multiplataforma vale a pena

O multiplataforma faz sentido quando a maior parte do app é composta por telas, formulários, listas e chamadas de rede, o que descreve muitos apps corporativos. Uma única base de código significa um único conjunto de funcionalidades para criar e testar, e ambas as plataformas são lançadas juntas. Se a equipe já escreve em TypeScript para a web, o React Native permite reaproveitar essas habilidades e parte desse código.

Olhe para a equipe, não apenas para o app

A melhor tecnologia é aquela que a sua equipe consegue manter após o lançamento. Se o app for transferido para uma equipe interna, construa com o que eles conhecem ou para o que podem contratar. Um framework que ninguém na equipe entende vira um risco na primeira vez que algo quebrar de um jeito não abordado na documentação.

Considere o trabalho nativo de qualquer forma

Multiplataforma raramente significa nenhum código de plataforma. Notificações push, compras no app, tarefas em segundo plano e alguns recursos do dispositivo ainda exigem configuração nativa, e cada loja tem seu próprio processo de lançamento. Reserve orçamento para algum trabalho nativo em todo projeto multiplataforma e garanta que alguém na equipe consiga fazê-lo.

Mantenha a lógica de negócios portátil

Qualquer que seja o caminho escolhido, mantenha as regras do produto, como preços, permissões e cálculos, separadas das telas e no servidor onde isso fizer sentido. Isso torna o app mais fácil de testar, mantém a consistência entre as plataformas e torna uma futura mudança de abordagem muito menos dolorosa.

Em resumo

Escolha o nativo quando o app depender da plataforma e o multiplataforma quando depender principalmente de telas e dados. De qualquer forma, escolha algo que a equipe possa manter por anos. A escolha importa menos do que fazer bem-feito.