Flutter ShadcnUI: shadcn-style components for Dart, and what the port leaves out

The gap Flutter ShadcnUI fills: shadcn's look without a web layer

Flutter ships Material and Cupertino, and both come with opinions baked into the widget set. Teams that like shadcn's flatter, less decorative styling usually end up either restyling Material widgets until they stop looking like Material, or embedding a web view to run the real thing. Flutter ShadcnUI takes a third route: it reimplements the components natively in Dart, published on pub.dev as shadcn_ui, under the MIT licence. The README describes the project as "Shadcn UI ported in Flutter" with components that are "fully customizable".

The audience is narrow and specific. You need to already be building a Flutter app, you need the shadcn aesthetic rather than Material's, and you need to be willing to accept a component set that is still filling in. If any of those three is false, this is not the library for you. It is not a way to reuse shadcn's React source, and it is not a design system with a separate spec you can hand to a designer who does not read Dart.

How the port works: Dart widgets and a theme, not a registry

The important architectural fact is that nothing is copied in from the JavaScript project. In shadcn's original model you run a CLI, it writes component source files into your repository, and you own and edit those files. Flutter ShadcnUI does not work that way. The components live in the package's lib/ directory and you consume them as a dependency. Customization happens through the widget API and the library's theme rather than by editing vendored source.

That difference has consequences. Upgrading the package upgrades every component at once, which you cannot do with copy-in source files. You also cannot patch a single component in place without forking or wrapping it. The README's own framing supports the customization claim: the maintainer writes that each widget "takes some time because I try to solve problems in a simple way, making each widget extremely customizable."

The repository layout backs this up. lib/ holds the package, example/ holds a runnable app, playground/ is a separate project built for the web, docs/ holds the documentation site, and cli/ and skills/ sit alongside them. The Makefile shows how the hosted playground is produced, which is also the clearest statement of how the project itself is built and shipped.

Getting the code: the docs site and the Agent Skills command

The README does not print a pubspec snippet or a flutter pub add line, so there is no dependency block to copy here. What it does say is where to go: the documentation site, linked from the README under Documentation, is where you "interact with the components and see the code". That site is the source of truth for widget names and usage, and it is generated from the same repository, so the examples there match the project rather than a third-party tutorial.

The one command the README does give is for coding agents. If your tooling supports Agent Skills, the project can be added with the command below. This installs skill definitions for the project; it does not add a Dart dependency or change your pubspec.

npx skills add nank1ro/flutter-shadcn-ui

The repository's own build steps are visible in the Makefile, which is worth reading before you file a bug, because it shows what the maintainers actually run. The compile target builds the playground for web with the CanvasKit renderer and icon tree shaking disabled, and the deploy target pushes it to Firebase.

cd playground && flutter build web --web-renderer canvaskit --no-tree-shake-icons

Expect the docs site to track the main branch while pub.dev serves the last release. The repository has shipped releases frequently, including v0.57.0 and v0.57.1 within days of each other in September 2026, so a widget that works in a docs example can differ from what your pinned version compiles.

What the component checklist still marks as missing

The README's progress list is the most useful page in the repository, and it is honest about gaps. Carousel, Collapsible, Command, Data Table, Drawer, Navigation Menu, Pagination, Skeleton, Toggle and ToggleGroup are all unchecked. Several of these are not cosmetic omissions. A data table is a load-bearing component in most admin interfaces, and pagination usually travels with it. Skeleton matters if you show loading states rather than spinners.

The list also records deliberate substitutions rather than gaps. Dropdown Menu is struck through with the instruction to use Context Menu instead. Hover Card is struck through in favour of Popover. Label is struck through in favour of Text. Scroll Area is struck through with the advice to use SingleChildScrollView, ListView and similar Flutter widgets. Those are reasonable calls in a Flutter context, where scrolling is a framework concern, but they mean the component names you know from shadcn's documentation will not all exist here.

This is the case where the library is the wrong tool: if your design is specified against the full shadcn component list and you cannot substitute, you will be building the missing pieces yourself, and a hand-rolled data table in Flutter is a real project. The second wrong-tool case is a team that wants to edit component internals. Without copy-in source, every change is a wrapper or a fork.

Choosing between Flutter ShadcnUI, shadcn_flutter and Forui

The README addresses one alternative directly. Asked what the difference is with shadcn_flutter, the maintainer answers that this repository was created on 05/01/2024 while the other started on 12/02/2024, that he was never contacted to contribute, and that he would welcome contributions. He adds that another library "could probably come first with more widgets, but in the long run it's the quality the most important thing."

That is the real trade-off, stated by the maintainer rather than inferred. If you need breadth quickly, a project that has already checked off more boxes will get you to a working screen sooner. If you care about per-widget customization and can wait or work around the gaps, this project's stated priority is depth over count. Neither position is verifiable from the README alone, and you should compare the two component lists yourself rather than trusting either claim.

Forui is a different kind of alternative. It is a Flutter UI library with its own visual identity rather than a port of an existing web design language. Choosing it means your app will not look like shadcn, which may be fine or may be the entire reason you started looking. Fluent UI Flutter is a third option in the same space, tied to Microsoft's design language. The decision between them is mostly a decision about which visual language your product already committed to.

Maintenance, releases and the cost of tracking main

The repository is not archived, and the last push was on 2026-09-24. Releases have been frequent and small: v0.56.3 on 2026-09-03, v0.57.0 on 2026-09-16, and v0.57.1 on 2026-09-24. The version numbers are still in the 0.x range, which in Dart's convention means the API is not yet considered stable and minor bumps can carry breaking changes. That is the upgrade cost you are signing up for: a fast release cadence paired with no stability guarantee.

Practically, that means pinning an exact version in pubspec.yaml and reading CHANGELOG.md before moving. The repository also carries a .coderabbit.yaml file, indicating automated review runs on pull requests, and a CONTRIBUTING.md for anyone filing fixes upstream.

The licence is MIT, which is permissive and places few obligations on how you distribute a Flutter app that depends on the package. This is a description of the licence identifier, not legal advice; if your organisation has rules about dependency licences, run the package through your normal review.

Editorial conclusion

Adopt shadcn_ui if your app is Flutter and you want shadcn's visual language with widgets you can restyle through the package API rather than a web layer. Do not adopt it as a drop-in replacement for the JavaScript shadcn registry: there is no copy-in source workflow here, and the README still lists Carousel, Collapsible, Command, Data Table, Drawer, Navigation Menu, Pagination, Skeleton, Toggle and ToggleGroup as unchecked. Before committing, open the component list in the repository and confirm the widgets your screens actually need are marked done, then build one real screen against the pub.dev release rather than the docs site, because the docs reflect main and the pub package is what your app will compile against.

Frequently asked questions

Official sources

1. License: MIT
2. nank1ro/flutter-shadcn-ui on GitHub
3. Project website
4. README
5. Releases