GetWidget: a 1,000+ widget Flutter UI kit, and what its release history tells you

The problem GetWidget targets, and who ends up using it

Flutter ships with Material and Cupertino widget sets, and both are complete enough to build an app without any third-party UI package. The cost shows up later, when a team needs a carousel, a rating control, a shimmer placeholder, an accordion, a search bar with a particular look, or a social login button row. Each of those is a small build, and each one drifts in styling from the others unless someone owns the design tokens.

GetWidget's answer is breadth. The README describes it as an "open-source Flutter UI Kit with 1,000+ production-ready widgets" and lists the collection by component: GFButton with standard, pill, square, icon and social variants, GFAvatar, GFImage, GFCard, GFCarousel, GFTile, GFTab, GFToast, GFToggle, GFDrawer, GFAccordion, GFAlert, GFAppBar, GFSearchBar, GFRating, GFDropdown, GFLoader, GFProgressBar, GFShimmer, plus checkbox, radio and sticky-header widgets. The intended reader is a Flutter developer who wants those patterns pre-styled rather than hand-rolled.

The README is explicit that the library is additive rather than a replacement: "GetWidget is additive" and you can mix GF* widgets with Material/Cupertino widgets in the same screen. That matters for adoption, because it means you can introduce one component without rewriting a screen. The naming convention is the whole interface: if it starts with GF, it comes from this package.

How the package is put together

The repository layout is a standard Flutter package. Source lives under lib/, tests under test/, and a full runnable app under example/, with android/, ios/, linux/, macos/ and windows/ subdirectories plus its own pubspec.yaml and analysis_options.yaml. There is a config directory at the top level and an icons directory, which suggests theme tokens and icon assets are shipped inside the package rather than fetched at runtime.

The README claims a single theming surface: widgets follow the same prop conventions and theming model, and the pitch is that all of it is themable from a single design-token surface. That is the architectural claim worth checking against the source, because a shared token layer is what separates a coherent kit from a folder of unrelated components. The README does not name the token class or the theme entry point, so you have to read lib/ to confirm how a global override propagates. The documentation site at docs.getwidget.dev is where per-widget props are described; the README itself only links out.

Build tooling is visible but dated. The repository carries a .travis.yml, and the README's build badge points at travis-ci.org, a CI service that has been retired. A Travis configuration in 2026 is a signal about how much of the release pipeline has been revisited, not proof of anything about the widget code, but it is the kind of detail that tells you to check the repository rather than the marketing copy.

Installing GetWidget and rendering a first GFButton

The README's quick start is a single line pointing at the Getting started page on docs.getwidget.dev, and the documentation section repeats that link as the Installation Guide. The repository does not inline install commands, so the package name comes from the pubspec and the badge URL: getwidget on pub.dev.

Add it to the dependencies block of your app's pubspec.yaml. Keep the constraint loose enough to resolve against your Flutter SDK, then let pub pick the version.

yaml dependencies: flutter: sdk: flutter getwidget: ^2.0.4

Run pub get from the project root. The README does not document a minimum Dart or Flutter SDK constraint, so if resolution fails, check pubspec.yaml in the repository for the declared environment before changing anything else.

bash flutter pub get

Import the package and use a GF* widget directly. The README's component list names GFButton with standard, pill, square, icon and social variants, and the docs site splits those across /gf-button, /gf-button/standard-button, /gf-button/pills-button, /gf-button/square-button, /gf-button/icon-button and /gf-button/social-button.

dart import 'package:getwidget/getwidget.dart';

GFButton( text: 'Continue', onPressed: () {}, )

If that renders a styled button, the package is wired up correctly and you can pull the rest of the collection in the same way. If the widget name does not resolve, the version you resolved is not the one the docs describe; check pubspec.lock and the docs page for the specific component before filing anything. The example/ directory is a working app with platform folders for Android, iOS, Linux, macOS and Windows, so it is the best place to see a component in context when a docs page is thin.

The release history is the part to read carefully

The README's status line is confident: it states that GetWidget is maintained, at v7.0.1 in May 2026, with 23,000 monthly downloads on pub.dev and 4,800+ GitHub stars. The repository metadata tells a different story about what has actually been published. The most recent releases listed are v2.0.4 from 2021-08-23, v2.0.3 from 2021-06-29 and v2.0.2 from 2021-05-10. There is no v7.0.1 in the release list.

Those two records cannot both describe the same published artifact trail, and the README does not explain the gap. It is possible that releases are tagged inconsistently, that the version numbering restarted, or that the README is describing an unreleased state of the package. Nothing available says which. What you can verify is the pub.dev version badge, which is the version pub will actually resolve when you run pub get. Treat that as the source of truth and treat the README line as a claim.

The last push to the default branch was on 2026-05-24, so work is happening in the repository. The README's own contributor section asks for help with documentation and marks issues as "good first issue". Note also that the README does not document a rollback path or a deprecation policy for GF* widget names, so if a component is renamed between versions, nothing published tells you how that is announced.

Where GetWidget is the wrong tool

The breadth is the selling point and also the risk. A kit that lists over a thousand widgets across buttons, carousels, forms, accordions, loaders and sticky headers is a large surface to keep aligned with Flutter's stable channel, and the README's own claim that releases follow Flutter's stable channel is the commitment that needs the most scrutiny. When Flutter changes a rendering or theming default, every GF* component that wraps it has to be revisited. Nothing in the README describes how that review is done or how quickly.

If you need one or two components, this is the wrong dependency. A single button variant is a few lines of Material code, and pulling a full UI kit in for that adds a package you now have to track through Flutter upgrades. The same applies if your design system is already defined: a kit with its own token surface means reconciling two theming models, and the README does not describe an escape hatch for opting a single GF* widget out of the shared theme.

Accessibility is not addressed anywhere in the README. There is no statement about semantic labels, screen reader behaviour, contrast guarantees or keyboard navigation for the desktop targets that example/ covers. If your app has accessibility requirements, that silence is a gap you would have to close yourself by inspecting the source of each component you adopt.

How GetWidget differs from VelocityX and Forui

The related search data puts GetWidget next to VelocityX, Forui and TDesign Flutter, and the approaches are not interchangeable. VelocityX is built around a shorthand API style that compresses widget construction into chained modifiers, so the code you write looks different from stock Flutter at the call site. GetWidget instead keeps conventional constructor arguments, as the GFButton example shows, which means a developer who knows Flutter can read a GetWidget screen without learning a new syntax.

Forui takes the opposite stance on visual identity. It is a component library with its own design language rather than a set of drop-in widgets meant to sit beside Material, and the README's framing for GetWidget is explicitly the mixing model: GF* widgets next to Material and Cupertino on the same screen. If you want a distinct look that is consistent by construction, a library with an opinionated design language is the better fit. If you want to keep Material's look and fill gaps, GetWidget's additive model is the closer match.

TDesign Flutter comes from a corporate design system, which usually means a specification document and a versioned component contract behind the code. GetWidget's contract is the docs site and the README. That difference matters most when a component's behaviour is ambiguous: a design-system-backed library has a spec to appeal to, and GetWidget has an issue tracker.

Licence and the cost of staying current

GetWidget is MIT licensed, per the LICENSE file and the badge in the README. MIT is permissive: you can use it in commercial and closed-source apps, and you keep your own code. The practical obligation is retaining the copyright and permission notice, which for a Flutter package usually means the licence text travels with your dependency tree. This is a description of the licence, not legal advice; if your organisation has a policy on third-party notices, run the LICENSE file past whoever owns it.

The README states that GetWidget is "100% free" and open source, and that contributions are welcome, with a CONTRIBUTING.md defining the pull request workflow. There is no paid tier, no licence key and no commercial support contract described. Support runs through the forum at forum.getwidget.dev and the issue tracker.

Upgrade cost is the real line item. Because the README presents the widgets as sharing one theming model, a change to that model is a change that can touch every screen using GF* components. The repository has a CHANGELOG.md at the top level, so the upgrade path is to read that file for the version you are moving to, check pubspec.lock for what you currently resolve, and grep your own codebase for GF prefixes to size the blast radius before bumping the constraint in pubspec.yaml.

Editorial conclusion

Adopt GetWidget if you are building a Flutter app and want a wide set of pre-styled GF* components you can mix with Material and Cupertino widgets, and you accept that the published package trail is older than the README suggests. Do not adopt it if you need a component set whose changelog you can audit release by release, or if you are targeting a platform the example directory does not cover. Before committing, check the pub.dev page for the version you will actually resolve, confirm the GF* widget names you plan to use exist in that version, and read CHANGELOG.md in the repository rather than the README badge line.

Frequently asked questions

Official sources

1. ionicfirebaseapp/getwidget on GitHub
2. License: MIT
3. Project website
4. README
5. Releases