Expo Modules 2.0 troca DSL por classes Swift e Kotlin anotadas

A Expo apresentou uma prévia do Expo Modules 2.0, que abandona a DSL da API 1.0 e define um módulo nativo como uma classe Swift ou Kotlin anotada. A promessa é menos boilerplate, nada novo a aprender além de algumas anotações e chamadas até 5,6 vezes mais rápidas. No iOS, os macros que sustentam o recurso já vêm no SDK 57, ainda em caráter experimental; o Android está em desenvolvimento.

Da DSL a classes anotadas

Na versão 1.0, o que o módulo expõe ao JavaScript é descrito em uma DSL baseada em result builders do Swift, com Function, AsyncFunction, Property, Class e Events. Na 2.0, Function e AsyncFunction viram um método Swift comum marcado com @JS. Nome e tipos são lidos da própria declaração; um método async aparece no JavaScript como função que retorna Promise. Uma Property com getter e setter vira uma var Swift: propriedades graváveis são graváveis no JS, e let ou var somente leitura são somente leitura. As duas APIs podem coexistir no mesmo módulo: adiciona-se @ExpoModule e move-se funções e propriedades para @JS aos poucos.

Records, objetos e eventos

Records viram structs Swift; propriedades armazenadas que não sejam private, static ou lazy viram campos, com obrigatoriedade, opcionalidade e nulabilidade lidas da declaração. Shared objects são classes cujas instâncias existem ao mesmo tempo em Swift e JavaScript, expostas com membros @JS, incluindo um @JS init() que vira construtor no JS. Eventos deixam de ser nome registrado mais sendEvent(...) e passam a ser uma propriedade callable tipada: declara-se o tipo do payload uma vez, e chamar a propriedade despacha o evento. Payloads aceitam primitivos, arrays, dicionários, records, shared objects, typed arrays, array buffers, Data e Date; outros tipos exigem JavaScriptEncodable e JavaScriptDecodable. Se o tipo não puder ser enviado, o compilador Swift emite erro em tempo de build.

Migração e agentes

A adoção de sintaxe nativa é justificada também pelo uso crescente de agentes de código para escrever, revisar e migrar módulos. Modelos são treinados em Swift e Kotlin, enquanto a DSL 1.0 tem menos exemplos; com 2.0, boa parte da API é a própria linguagem, o que reduz contexto e encurta o ciclo de gerar, errar e corrigir, já que o compilador aponta tipos inválidos. Há uma skill, expo-migrate-module, que usa um agente para migrar o lado Swift de 1.0 para 2.0 mantendo a API JavaScript inalterada; o que não for migrado fica na definition() e é listado em relatório. O comando aceita claude-code, codex, cursor ou outro agente.

Desempenho

O ganho vem de mudanças em três SDKs. O SDK 56 removeu a camada Objective-C++ e tornou as chamadas de módulos Expo 1,5 a 2 vezes mais rápidas que no SDK 55, comparáveis às Turbo Modules do React Native. O SDK 57 melhora o runtime compartilhado, beneficiando até módulos que seguem em 1.0 sem alteração de código. O macro @JS lê as assinaturas em tempo de build e evita o caminho dinâmico da API 1.0, que alocava contêineres e convertia argumentos a cada chamada. Na mesma SDK, o caminho @JS é de 2,5 a 5,6 vezes mais rápido em chamadas síncronas; as assíncronas ficam próximas, pois compartilham a mesma máquina de promises, com melhoria maior prevista para o SDK 58. As medições usaram um iPhone 16 Pro com iOS 27, build Release e frameworks pré-compilados, em 100.000 chamadas.

Próximos passos e disponibilidade

Views virão depois, como classes marcadas @ExpoView, com props e callbacks declarados em uma struct tipada @ViewProps. Também está prevista a geração de declarações TypeScript a partir das assinaturas nativas. A ferramenta produzirá um resumo legível por máquina do que o módulo exporta; quando o Android gerar o mesmo resumo a partir do Kotlin, será possível comparar plataformas e detectar diferenças antes que virem bugs. Os macros principais já estão no SDK 57 para iOS, mas seguem sem documentação e a API ainda pode mudar. A beta oficial chega no SDK 58, junto de uma agent skill que ensina a nova API a assistentes de código. O Android segue o mesmo modelo de autoria, mas ainda está em obras. No longo prazo, o Expo Modules 2.0 deve se tornar a forma padrão de escrever um módulo Expo, enquanto a versão 1.0 continua funcionando para o que já foi construído com ela.