# Angular Native runs your Angular components on Fabric, with React nowhere in the path > ng-native renders Angular components directly onto React Native's Fabric renderer so a view becomes a UIView on iOS and an android.view.View on Android, with signals, Signal Forms and the Angular router intact. It is an alpha project at 0.17 with a documented limitations page. **ng-native/ng-native** — Angular apps, rendered as real native iOS and Android views, on React Native's Fabric renderer. - Repository: https://github.com/ng-native/ng-native - Website: https://ng-native.com - Stars: 586 · Forks: 26 - Language: TypeScript - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/ng-native-ng-native ## Angular components, native views, no React in the render path Angular Native renders Angular components straight onto React Native's Fabric renderer, so a view is a UIView on iOS and an android.view.View on Android, and React is never in the render path. That last clause is the whole design and the reason the project exists. React Native's renderer is used, but React is not, so there is no component tree, no reconciliation loop and no React runtime cost in the path between your template and the screen. What you write is an Angular component, and what you get is a native view hierarchy. You write standalone components, signals, Signal Forms and @angular/router routes as you would for the web. Then you create, run, hot reload and ship the app with Expo. ```sh npx create-expo-app@latest my-app --template @ng-native/template cd my-app && npx expo start ``` Then you scan the QR code with Expo Go, or press i or a for a simulator. The starting point is a template rather than a library you wire in by hand, which tells you something about the intended workflow. The template carries the Metro preset, the Tailwind preset and the rest of the build configuration, and the README has a separate guide for adding Angular Native to an existing app, so the manual path exists but is clearly the second option. The project is MIT licensed, the homepage is ng-native.com, and the README states that it is an independent open source project, not affiliated with or endorsed by Google, the Angular team or Expo, with Angular a trademark of Google LLC. That disclaimer is worth reading, because it tells you where the project sits relative to the frameworks it builds on. ## The renderer is incremental, and that is what makes it fast The native rendering feature is described in one line that carries most of the technical weight. An incremental renderer commits only what changed to Fabric, with native text, images, scroll views, virtual and section lists, text inputs, switches, modals and gestures. Two things follow. First, the element list is not a small demo set. Text inputs and switches mean forms work natively rather than being emulated with a web view, and virtual and section lists mean long lists are handled by the platform's own list machinery instead of by a JavaScript bridge. Gestures being native is the difference between a scroll that feels right and one that does not. Second, the incremental part is what makes Angular's model viable here. Angular's change detection already knows what changed in a component, and a renderer that commits only the changed parts to Fabric is the shape of problem Angular's template binding is designed for. A renderer that rebuilt the whole tree on every update would throw that away. Beneath the renderer sits a package the README lists last but which is architecturally the most interesting: @ng-native/fabric, described as the framework agnostic retained tree and commit engine the renderer is built on. Framework agnostic is the key word. The engine knows about a retained tree of nodes and about committing diffs, and it does not know about Angular. That separation is what makes the rest of the package list possible, and it is why the same components can also be rendered to the DOM by @ng-native/web, which is described as a DOM renderer for the same components with a Vite preset. ## Styles compile to native, and Tailwind comes with platform variants The styling story is that CSS is a source language that compiles to native styles at build time. The README says elements are Angular components imported like any other with lowercase names, and that stylesheets compile to native styles at build time. The CSS feature list is substantial: component stylesheets, CSS variables, media queries, dark mode, transitions and @keyframes, plus a Tailwind preset with ios: and android: variants. The Tailwind preset with platform variants is the piece with the most practical value, and it is a small idea that solves a real problem. In a hybrid codebase, you often want a margin that is larger on one platform than the other, or a font size that accounts for a notched screen. With ios: and android: variants, that is a prefix in the class name rather than a conditional in the template, and the compiler resolves it to the right native value at build time. Media queries and dark mode are also native features rather than approximations, which matters for a design system that is shared with a web target. The theming and Tailwind guide is one of the links in the documentation list, alongside guides for getting started, adding it to an existing app, building a form, deployment, how it compares to other approaches, known limitations and the architecture document. ## Router, forms and Expo modules, in the Angular idiom The navigation story is that @angular/router works over native stacks, tabs, headers, modals and sheets, with guards, resolvers, lazy routes and deep links. Guards and resolvers are the part that matters. An Angular codebase already has route guards, and if they are not honoured the whole navigation model breaks. The fact that they carry over means an existing app's routing configuration has a chance of surviving the move to native. Forms are handled by Signal Forms bound to native controls, so a form field is a real text input rather than a JavaScript implementation of one. Expo's modules are exposed as Angular services, with the README listing camera, location, notifications, secure storage, the file system, SQLite, biometrics, maps, haptics and more, injected like any other service. The Angular dependency injection system is doing the work that a React Native library would do with a hook or a context provider. That is a nice fit for Angular developers, and it is a place where the two frameworks have genuinely different idioms. For animation there is animate.enter and animate.leave, CSS transitions, and the Animated and Reanimated worklets. The whole set of these features is in a package at version 0.17.0, which is worth holding in mind as you read the list. ## Testing without a simulator, and the web target The testing feature deserves attention because it removes the usual excuse for not testing a native UI layer. There is a Testing Library API that runs components in Node against a fake Fabric, with no simulator. A fake Fabric means the component tree is exercised in a normal Node process, with the same test runner and the same assertions as the rest of your suite. You are not booting a simulator to check that a label renders, and you are not writing a separate native test suite. The @ng-native/testing package is the one that provides this, described as Testing Library for Angular Native running in Node. Then there is @ng-native/web, a DOM renderer for the same components with a Vite preset. The consequence of the framework agnostic engine in @ng-native/fabric is that the same Angular component can be rendered to a DOM. So a component library can have a web build and a native build from one source, and a storybook or a test page can render in a browser. For teams with an existing web Angular application, that is the interesting combination, because it means a migration can be incremental rather than a rewrite with a parallel web build maintained alongside. ## Fifteen packages, and where the work happens The package table is long, and reading it tells you what the project has had to build to make the hybrid work. @ng-native/platform provides mount(), the Angular renderer, and HttpClient for React Native. @ng-native/components holds the elements, views, text, images, lists, inputs, pressables, gestures and animation. @ng-native/router is native stack and tab navigation over the Angular router. @ng-native/device covers keyboard, screen, colour scheme, app state, accessibility and deep links. Then the integration packages. @ng-native/expo exposes Expo's modules as Angular services and directives. @ng-native/icons provides an ng-icon element with the @ng-icons sets, drawn as native SVG. @ng-native/analog brings Analog's file-based pages, routed on a native stack. @ng-native/metro is the Metro preset with the Angular compiler, the CSS compiler and hot reload. @ng-native/tailwind is the Tailwind preset and its platform variants. The tooling packages are @ng-native/testing, @ng-native/web, @ng-native/schematics for ng add and ng generate in Angular CLI workspaces, @ng-native/nx for nx add and an app generator, @ng-native/migrate for the migrations that update an app to a new release, and @ng-native/fabric as the retained tree and commit engine. The packages directory in the repository matches this list, and the top level is an Nx workspace with nx.json, a pnpm workspace file, a template/ directory, apps/ and examples/. The examples are complete applications, and there are more of them than the README names, including canary, foldbook, markdown and padel alongside the bank, habit tracker, music player, run tracker, notes app and the Analog showroom. ## Alpha status, a strict requirements list, and the limits page The status section is the first thing to read and it is unambiguous. Angular Native is in alpha, so APIs can change between 0.x releases, and the known limitations page lists every gap with its workaround. The requirements are strict and specific: Angular 22, Expo SDK 57 and React Native 0.86 with the New Architecture, on Node 22.18 or later. Three specific framework versions, a specific React Native architecture, and a specific Node minor version. Any of these moving is an upgrade for you, not just for the library. The version numbers of the releases support that reading. v0.15.0, v0.16.0 and v0.17.0 landed on 2026-10-16, 2026-10-17 and 2026-10-20, three releases in five days, with the last push to the repository on the same day as the newest release. That is the pace of an active alpha, and it cuts both ways. You get fixes quickly, and you also get API churn. The repository itself is a well built engineering project by the standards of the field. The package.json is an Nx workspace with pnpm at a pinned version, and the scripts run lint, typecheck and test across the workspace, plus a coverage script that enforces a minimum of 95 percent, a bundle size check for the canary app, and a verify script that chains format check, lint, typecheck, build, test and the bundle check. There is a pnpm lock file, a verdaccio configuration for local publishing, an oss-scanner directory, and a CHANGELOG.md. So the tooling is serious. The alpha warning is about the API, not about the project's engineering. ## Conclusion Adopt ng-native if your team already writes Angular and you want native iOS and Android output without rewriting the UI in React Native, and you are prepared to work against an alpha API that changes between 0.x releases. Do not adopt it if you need a production-stable surface, or if you need to drop Angular entirely, since the whole premise is that Angular stays. Before you start, read the known limitations page the README links, confirm your Angular, Expo SDK and React Native versions match the stated requirements, and use the create-expo-app template so the Metro and Tailwind presets are wired correctly. ## FAQ ### What is Angular Native? It renders Angular components straight onto React Native's Fabric renderer, so a view is a UIView on iOS and an android.view.View on Android, and React is never in the render path. You write standalone components, signals, Signal Forms and @angular/router routes, then create, run, hot reload and ship with Expo. ### How do I create an Angular Native app? Run npx create-expo-app@latest my-app --template @ng-native/template, then cd my-app and npx expo start. Scan the QR code with Expo Go, or press i or a for a simulator. The README also links a guide for adding Angular Native to an existing app. ### What versions does Angular Native require? Angular 22, Expo SDK 57 and React Native 0.86 with the New Architecture, on Node 22.18 or later. The project is in alpha, so APIs can change between 0.x releases. ### Can I test Angular Native components without a simulator? Yes. The @ng-native/testing package provides a Testing Library API that runs components in Node against a fake Fabric, with no simulator required. ### Can the same Angular components run on the web? Yes. The @ng-native/web package is a DOM renderer for the same components, with a Vite preset, and it exists because the renderer is built on the framework agnostic retained tree and commit engine in @ng-native/fabric. ## Sources - [License: MIT](https://github.com/ng-native/ng-native/blob/main/LICENSE) - [ng-native/ng-native on GitHub](https://github.com/ng-native/ng-native) - [Project website](https://ng-native.com) - [README](https://github.com/ng-native/ng-native/blob/main/README.md) - [Releases](https://github.com/ng-native/ng-native/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ng-native-ng-native