Angular Native: Angular, Fabric e Expo para apps nativos

Angular Native propõe uma combinação interessante para quem já desenvolve com Angular: escrever componentes, templates, signals e serviços, mas entregar uma interface formada por views nativas de iOS e Android, usando o ecossistema do Expo.[8] A ideia não é colocar um site dentro de um aplicativo, nem trocar TypeScript por outra linguagem: é conectar Angular ao renderizador nativo do React Native.[3]

O foco deste artigo é o projeto ng-native/ng-native, disponível em ng-native.com. Ele é independente, tem licença MIT e não é afiliado nem endossado por Google, pela equipe do Angular ou pelo Expo.[8] Na consulta de 8 de outubro de 2026, a release mais recente era a v0.8.0, mas a documentação continua classificando o framework como alpha, com possibilidade de mudanças de API entre versões 0.x.[9][8]

Como Angular chega à interface nativa

No navegador, a implementação de Renderer2 do Angular cria e atualiza elementos do DOM. No Angular Native, @ng-native/platform fornece outra implementação dessa interface: as operações dos componentes alimentam uma árvore mantida por @ng-native/fabric, que é entregue ao Fabric, o renderizador do React Native.[3]

Assim, um <view> do template torna-se uma UIView no iOS ou uma android.view.View no Android.[8] Não há uma árvore de elementos React nem seu reconciliador no caminho de renderização: Angular dirige o mesmo renderizador C++ usado pelo React Native.[3]

As responsabilidades principais ficam divididas entre três pacotes:[3]

@ng-native/components: componentes Angular que representam os elementos da interface nativa.[3]
@ng-native/platform: integração com Renderer2 e inicialização da aplicação.[3]
@ng-native/fabric: árvore de renderização, commits, eventos e resolução de estilos.[3]

A inicialização usa detecção de mudanças zoneless, sem opção de adicionar zone.js.[4] Isso aproxima a experiência do Angular moderno, mas não transforma automaticamente uma aplicação web existente em um aplicativo móvel.

Reutilizar Angular não significa reutilizar qualquer HTML

A familiaridade está nos componentes standalone, signals, injeção de dependência e rotas do Angular.[8] O conjunto de elementos da interface, porém, é outro: entram <view>, <text>, <text-input> e <pressable>, importados como componentes Angular.[8]

No ambiente nativo não existe o DOM do navegador, e APIs como document, window e manipulação de HTMLElement não funcionam como na web.[7] A documentação também aponta a indisponibilidade de DomSanitizer e NgOptimizedImage nesse contexto.[7]

A consequência prática é separar duas coisas: lógica de negócio e serviços sem dependência do navegador são candidatos ao compartilhamento; telas e bibliotecas que assumem HTML precisam ser revisadas. É uma avaliação de arquitetura, não uma promessa de migração sem esforço.

CSS e Tailwind, com limites explícitos

O projeto compila os estilos dos componentes durante o build com lightningcss e resolve seletores, cascata e herança sobre a árvore nativa em tempo de execução.[3] A documentação apresenta variáveis CSS, media queries, transições e keyframes, além de integração com Tailwind e variantes como ios:, android: e dark:.[1]

Isso reduz a distância para quem já conhece estilização web, mas não equivale a executar todo o CSS de um navegador. Grid, layout de tabelas, ::before, ::after, position: fixed e position: sticky estão entre os recursos declarados incompatíveis com o modelo de estilos utilizado; o build informa essas restrições por meio de avisos.[3]

Portar uma tela exige conferir layout, tipografia, teclado, áreas seguras e comportamento em cada plataforma. Copiar a folha de estilos e ignorar os avisos é uma forma rápida de produzir uma interface diferente da pretendida.

O que o Expo acrescenta

O fluxo de desenvolvimento usa Expo Go, builds de desenvolvimento e distribuição via ferramentas do Expo, incluindo EAS Build.[2] Módulos de câmera, localização, notificações, armazenamento seguro, arquivos, SQLite e biometria são expostos por integrações que podem ser usadas como serviços Angular.[8]

A navegação também aproveita @angular/router: URLs, guards, resolvers e carregamento sob demanda convivem com stacks e transições nativas implementadas sobre react-native-screens.[3]

Há uma ressalva importante: a própria documentação informa que várias fachadas de APIs da plataforma possuem testes unitários e verificação de tipos, mas ainda não foram verificadas em hardware real.[4] Uma integração aparecer na lista de recursos não é evidência suficiente para colocá-la no caminho crítico de um aplicativo sem testar o dispositivo e o cenário necessários.

Como se diferencia das alternativas

A comparação publicada pelo projeto destaca diferenças de modelo, não apresenta benchmarks e não sustenta alegações de superioridade de desempenho.[4]

React Native: Angular Native reutiliza Fabric e Expo, mas substitui a camada de UI baseada em React por templates, signals e injeção de dependência do Angular.[4]
NativeScript com Angular: também oferece interface nativa, porém sua integração acessa APIs das plataformas por bindings próprios, em vez de se apoiar no conjunto de módulos do React Native e do Expo.[4]
Ionic com Capacitor: mantém a interface web dentro de uma WebView, enquanto Angular Native renderiza seus elementos principais como views nativas.[4]

Para uma equipe que já usa React Native, familiaridade com Angular não é, por si só, motivo para migrar. Para um produto Angular que depende muito do DOM, Ionic pode exigir menos adaptação. O valor do Angular Native aparece quando manter o modelo de programação Angular e usar controles nativos são requisitos simultâneos.

Como começar a avaliar

O README consultado exige Node.js 22.18 ou superior, Angular 22, Expo SDK 57 e React Native 0.86 com a New Architecture.[8] O caminho inicial documentado cria uma aplicação pelo template oficial do projeto:[2]

npx create-expo-app@latest my-app --template @ng-native/template
cd my-app
npx expo start

Depois, o guia orienta abrir o QR code no Expo Go ou usar as opções de simulador disponíveis; módulos ausentes no Expo Go exigem um build de desenvolvimento.[2] Para quem mantém um workspace, há integrações com Angular CLI e Nx.[2]

Para avaliar além do contador inicial, monte uma pequena fatia do produto: login, uma lista com rolagem, um formulário, acesso à API e a integração nativa mais importante. Teste também uma build de release, não apenas a versão de desenvolvimento.

Esse último ponto tem uma justificativa concreta: a documentação recomenda provideNativeHttpClient() e descreve cenários em que a configuração inadequada do backend HTTP funciona em debug, mas produz respostas com corpo nulo em release.[7]

Limites que entram na decisão de adoção

Além da condição alpha, há suporte parcial a internacionalização, ausência de SSR e hidratação e incompatibilidade do Angular DevTools com a árvore nativa.[7] O projeto oferece testes de componentes em Node com uma camada nativa simulada, mas isso não substitui a validação dos fluxos em dispositivos.[1][4]

Também existe um renderizador web, @ng-native/web, para os mesmos componentes, mas a documentação diz que ele não é destinado a ser um alvo de distribuição; navegação nativa, worklets e gestos não se transferem integralmente para o navegador.[5] Portanto, não seria correto vender a proposta como um único aplicativo pronto para web, iOS e Android sem ressalvas.

A recomendação aqui é começar por uma prova de conceito com critérios de saída: estabilidade em release, acessibilidade, funcionamento offline quando necessário, cobertura das integrações e custo de manutenção. Para uma entrega com prazo rígido, adotar um framework alpha adiciona risco que precisa ser assumido conscientemente.

Como isso pode ser útil para você

Um projeto pessoal de hábitos, notas ou organização financeira pode servir como experimento controlado: compartilhe modelos e regras de negócio, escreva a interface com os componentes nativos e valide uma integração como armazenamento local ou biometria. O objetivo é medir quanto reaproveitamento realmente existe no seu caso, em vez de presumir que todo o front-end será compartilhado.

Em um produto existente, vale investigar Angular Native quando a equipe conhece Angular, precisa de interface nativa e aceita investir na adaptação e na validação das dependências. A decisão deve seguir os resultados desse experimento. A proposta é tecnicamente relevante, mas seu estado atual pede avaliação, não migração por entusiasmo.

Fontes consultadas

Projeto no GitHub: Angular Native