GetX: state management, routing and dependency injection in one Flutter package
Open screens/snackbars/dialogs/bottomSheets without context, manage states and inject dependencies easily with Get.
At a glance
- What is it?
- A Flutter library that bundles reactive state, routing and dependency injection behind a single static Get class, and is published on pub.dev as the get package.
- Who is it for?
- GetX is a good fit when you want one dependency rather than three, and when you would rather navigate and show dialogs without threading a BuildContext through your code. The dependency management behaviour is the part most worth understanding before committing: controllers are removed from memory when unused unless you declare permanent, and loading is lazy by default, which removes a category of leak that other approaches leave to you.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 116 days ago.
- What is it written in?
- Mainly Dart, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 21, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One static entry point instead of three separate packages
GetX is published on pub.dev as the `get` package, and it is described as an extra-light and powerful solution for Flutter that combines high-performance state management, intelligent dependency injection, and route management quickly and practically.
The distinguishing feature is that these are not three libraries you compose. They are reached through one static class. The repository topics list state management, dependency injection, routes, http and internationalization, and the README's own framing is that GetX has three basic principles which set the priority for everything in the library: productivity, performance and organization.
At 11,195 stars and 1,851 forks, this is by far the largest project in this batch, and the fork count is high in a way that reflects a specific dynamic: the README advertises interview preparation explicitly, listing a GetView tip, a GetWidget tip and a GetxService tip under useful tips for current and prospective Flutter developers. Codebases are copied, and then diverged.
It is MIT licensed, written in Dart, not archived, and the last push was on 2026-06-12. That date is worth pairing with the release history: the most recent release is getx 4.6.1 from 2021-12-14. The repository receives pushes while the published package has not been cut since 2021.
Three pillars, and what each one claims to do
The performance claim is specific: GetX does not use Streams or ChangeNotifier. That is the mechanical difference, and it is why the package advertises minimum consumption of resources.
The productivity claim rests on memory management. The README says developers should generally be concerned with removing controllers from memory, then argues that with GetX this is not necessary, because resources are removed when they are not used by default. Keeping one in memory requires explicitly declaring permanent true in the dependency. Dependency loading is lazy by default as well.
Inverting the usual responsibility is the interesting part. Instead of the framework holding controllers until you dispose them, the framework drops them, and you opt in to retention. For a long-running app that means the failure mode is not a leak you forgot to clean up but a controller that quietly disappeared and needs a permanent flag.
The organization claim is about decoupling. The README states you do not need context to navigate between routes, so you are not dependent on the widget tree. You also do not need context to reach controllers through an inherited widget, which decouples presentation and business logic from the visualisation layer.
Navigation and overlays without a BuildContext
The route management half is where the context-free approach shows. Snacks, dialogs, bottom sheets and screens can all be opened without a context, which is the feature the repository description leads with: open screens, snackbars, dialogs and bottom sheets without context.
The 4.5.1 release explains what that cost once. An earlier snackbar implementation used an `OverlayRoute` to display a partial route, and the notes list four problems with that approach: you could not close the page without closing the snackbar, `Get.back()` interfered with tests of `Get.isSnackbarOpen`, the iOS pop gesture could produce visual inconsistency, and navigating to another route meant the snackbar was not displayed on the new page.
The fix was to remake the snackbar on top of an `Overlay` rather than a route, so opening one is no longer tied to a route. That is a good illustration of what context-free actually costs in engineering terms, and it is documented rather than hidden.
The middleware system is the other piece here. Pages can be wrapped in middleware with priorities, redirects, and lifecycle hooks named `onPageCalled`, `onBindingsStart`, `onPageBuildStart`, `onPageBuilt` and `onPageDispose`. Route management in GetX includes a lifecycle, which is more than most navigation packages offer.
Translations and theme change ship in the box
Internationalization is a built-in feature rather than a companion package. The README covers translations with a map per locale, using them in the widget tree, changing locale at runtime, and following the system locale. Internationalization is one of the listed repository topics.
Theme changes work the same way, through the same entry point. The reason these fit together is the context-free design again: a locale or theme change does not need a widget subtree to hang a rebuild off, so it can be issued from anywhere, including from a controller holding business logic.
`GetConnect` covers HTTP, with a default configuration and a custom configuration. The 4.6.0 release added proxy setting support to `GetConnect`, along with redirect handling on the request object. Bundling an HTTP client is consistent with the rest of the design and also means you may end up with one network client where you previously had a separate dependency.
Repository layout and how to read the documentation
The tree is larger than a typical single-purpose package. Beyond `lib/` and `test/` there is an `example/`, a second `example_nav2/`, and a `documentation/` directory. There are twenty README translations, including English, Vietnamese, Indonesian, Urdu, Chinese, Portuguese, Spanish, Russian, Polish, Korean, French, Japanese, Hindi, Bangla and Nepali, which is a reminder of how widely this package is used.
The README's table of contents is effectively a manual. It walks from About Get and Installing through the counter app, the three pillars, then state management with a Reactive State Manager section, route management, dependency management, utils covering internationalization and theme, `GetConnect`, middleware, and a section of advanced APIs that includes local state widgets such as `ValueBuilder` and `ObxValue`, and optional global settings.
It ends with a breaking changes section for 2.0 and a why GetX section. If you are evaluating the package, the counter app and the three pillars section are the fastest route to understanding the trade, and the breaking changes section is the one to read before upgrading an existing app.
What the issue count and release gap suggest
Two numbers deserve to be read together. Open issues stand at 1,185, which is very high for a package this size, and the last published release is from December 2021.
That combination is not automatically a problem, since a stable package with a large installed base can accumulate feature requests without needing to ship. But it does mean that if you need new behaviour, the pub.dev release is unlikely to have it, and the repository is where activity would show up instead. The last push on 2026-06-12 is recent enough that the code is not abandoned.
The 4.5.0 release also contains a forward-looking note that GetX 5 will prioritize code safety and that splitting the close command would reduce the check code. It reads as an intention rather than a commitment, and a major version that has not arrived is worth factoring into a decision.
For anyone weighing GetX against other Flutter state and routing solutions, the fair comparison is not feature count, since the package covers more ground than most. It is whether you want a framework-level dependency with one global entry point, or composable libraries that each solve one problem and can be replaced independently.
Editorial conclusion
GetX is a good fit when you want one dependency rather than three, and when you would rather navigate and show dialogs without threading a BuildContext through your code. The dependency management behaviour is the part most worth understanding before committing: controllers are removed from memory when unused unless you declare permanent, and loading is lazy by default, which removes a category of leak that other approaches leave to you. The trade is that this is a framework as much as a library, so adopting it is a decision about your whole app structure rather than one package in a pubspec. The README is unusually long and covers fourteen translated versions. Start with the counter app example and the three pillars section, then read the GetXService and GetView tips before spreading it across a real app.
Frequently asked questions
What is GetX?
GetX is a Flutter package that combines three things behind a single static `Get` class: reactive state management, dependency injection, and route management. It is published on pub.dev as the `get` package, MIT licensed, and it also includes internationalization, theme changes and an HTTP client.
How do I use GetX in Flutter?
Add the `get` package, then extend `GetMaterialApp` instead of `MaterialApp` and declare your routes through it. Controllers are created as GetX services and reached without a context. The repository includes a `example/` directory and a `example_nav2/` directory, and the README walks through a counter app before covering the three pillars.
Which is better, GetX or provider?
They solve different amounts of the problem. Provider is a single narrow mechanism for dependency propagation that composes with whatever routing and HTTP choices you make. GetX bundles state, routing and dependency injection together, so adopting it is a decision about your app structure rather than one package. GetX also avoids Streams and ChangeNotifier, which is its stated performance difference.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/jonataslaw-getx)