5
rafael
2 min de leitura ·

Shopify está saindo do React Native de volta para o Nativo (Swift e Kotlin)

A Shopify usa o React Native desde 2020, e muita coisa mudou desde então. Conforme a declaração no blog deles: "agentes de codificação mudaram o custo de desenvolvimento de aplicativos móveis em dobro", e resolveram sair do React Native para usar diretamente Swift e Kotlin.

O post tem vários detalhes, e a declaração acima não foi uma surpresa pra mim (na verdade é óbvio, já vimos outros casos como o Bun reescrito em Rust), mas tem algumas coisas que chamaram minha atenção, como o que a Shopify chamou de Helix.

O desenvolvedor aponta o Helix para uma tela. O Helix lê o código React Native e propõe uma sequência de checkpoints (pequenos segmentos ordenados do trabalho) que podem ser revisados​em minutos. Em seguida, avança checkpoint a checkpoint: cada um deve comprovar seu comportamento por meio de testes, corresponder ao aplicativo em execução em uma revisão visual, passar pelo crivo de dois revisores de código (atuando de forma crítica) e receber a aprovação humana antes de ser consolidado (commit) e de o próximo passo começar. O feedback de cada revisão é armazenado, tornando o processo mais autônomo à medida que a migração avança.

Desenvolvimento com o Helix: duas telas de celular lado a lado

Tem outros pontos interessantes no artigo.

Assim como uma grande empresa usar um framework/biblioteca é bom para essa ferramenta, deixar de usá-la pode ser ruim. No post tem três exemplos de bibliotecas que a Shopify desenvolvia/apoiava e o que vai acontecer com elas. Talvez outras empresas sigam o sinal e saíam de React Native e Flutter também.

Vale destacar, a IA ainda não roubou todos os empregos:

Se você quer ajudar a construir a próxima geração de aplicativos móveis da Shopify, estamos contratando engenheiros mobile, engenheiros de infraestrutura e desenvolvedores que atuam na intersecção entre IA e engenharia de software.

Carregando publicação patrocinada...
2

Com a chegada de modelos de inteligência artificial mais potentes, a maioria das ferramentas perderam seu propósito.

Quem é dev sabe que existe uma quantidade massiva de "glue" no código apenas porquê era chato de lidar, ou porquê era/é popular. Enfim, dependência sem uma necessidade real...

Eu penso que nativo é sempre melhor, e acrescentar uma dependência apenas em casos exepcionais. Por exemplo o serde é uma dependência essencial para o ecossistema Rust, bem como tokio projetos assíncronos, porém no caso de tokio, ainda vale considerar de threads não é o suficiente mesmo que custe um pouco (custo esse que pode ser reduzidos de 8 megabyte ~ 3 megabyte dependendo do context).

2

Isso de "roubar" emprego é complicado, acho que as pessoas estão considerando que a IA substitui o trabalho técnico, e não é verdade. Ela é uma ferramenta e quem é responsável por ela é um CPF, se esse CPF não tem conhecimento técnico o bastante, ela vai eventualmente tomar decisões ruins e gerar code smells, problemas de segurança, desempenho etc. A IA pode gerar 90% de código, mas esses 90% precisam de revisão e os 10% precisam de ajuste. Estou acompanhando aqui migrações de projeto com IA, e em nenhum caso os devs responsáveis foram demitidos, talvez deixou de contratar novos, mas todo processo foi somente acelerado pela IA.

1

Ah, certamente. É um debate a parte, meu último parágrafo foi apenas uma brincadeira porque a Shopify disse que está contratando.

Pela minha própria experiência com IA, acredito que um desenvolvedor hoje faz o trabalho de mais de um sem IA (comparando com alguns anos atrás). Mas isso é natural com a evolução tecnológica, não algo específico da IA. O que importa mais é se a demanda está acompanhando. Caso sim, mesmo uma pessoa conseguindo desenvolver mais, precisará de mais pessoas desenvolvendo.

1

Óbvio que a IA rouba empregos. No seu caso mesmo a IA roubou alguns.

O arquiteto continua escrevendo/ajustando 10% do código e revisando 90% do que foi entregue para ele. Nada muda aqui.
O que muda é quem escreveu esses 90%. Seriam vários júniors, plenos ou sênior mais fracos, agora é a IA.

A maioria dessas migrações que eu estou vendo acontecer não seriam nem possíveis sem IA por causa dos custos de desenvolvimento (o maior deles é justamente com contratações).

1
1

o fio foi pro debate de ia, mas tem um ponto técnico no post que eu acho mais interessante: o custo de multiplataforma não está no código de tela, está na borda com a plataforma.

eu mantenho um app em flutter e os dois problemas que mais me custaram tempo não tinham nada a ver com dart. um: no android 11+ as regras de visibilidade de pacote escondem os engines de tts se você não declarar o intent certo no manifest — a api não dá erro, devolve lista vazia, e o app simplesmente fica mudo. dois: o sdk de anúncios precisava dos adaptadores de cada rede compilados como dependência nativa; sem isso toda requisição voltava sem preenchimento, e nada disso aparece do lado dart.

ou seja: multiplataforma te poupa de escrever a tela duas vezes, não te poupa de conhecer as duas plataformas. com equipe pequena isso ainda compensa muito. no tamanho da shopify a conta inverte, que é basicamente o que eles descreveram.