flutter_getx_template wires the Flutter boilerplate you always rewrite

The list of things every Flutter project rewrites

The Introduction section lists the repeatable work that every new Flutter project ends up doing, and it is worth reading because the template's feature list is exactly this list, itemised.

Theme with light and dark modes, and the current theme stored in shared preferences. Localization with the current locale stored in shared preferences. Firebase Messaging. Notification setup. Safe API requests with error handling. Switching between widgets during an API call, that is, loading, success and failed states. Snackbars, toasts and in-app notifications. Making the app responsive and stopping font scaling. Changing the app icon, name and package id.

Each of these is a small, well-understood piece of work. Together they are the first day of most Flutter projects, and each one is a place where a new developer either copies a previous project, gets an answer wrong, or spends a day wiring it up.

The template's claim is that it takes care of all of this so you start with it set up and ready to use. That is a modest claim and a defensible one, which is more than can be said for templates that promise a complete architecture.

The README also names the companies and apps built on it, including a list of named customers and apps on the Google Play and Apple stores, and two open-source projects that reuse it, an e-commerce UI kit and a weather app. Those references tell you the template survives contact with real applications, which is a different claim from the feature list.

The .agent folder: skills and context for a coding agent

The most distinctive part of the template is not Flutter at all. The README's framing is blunt: your AI already knows this template. You clone it, open it in any AI coding agent, and that is the setup.

Everything the agent needs lives under `.agent/`, split into two parts. The `skills` directory is a playbook for screens, theme, localization, APIs and the rest of the stack. The `context` directory holds the architecture plus coding guidelines, described as there so the agent follows the project's leads instead of inventing a second one.

That second purpose is the interesting one. The stated failure mode is an agent that writes code in a style that does not match the surrounding project, and the fix is to give it the architecture and the conventions before it writes anything.

The README lists what you can ask the agent to do, and the list is a map of the template's own surface area: create a screen, create a controller, create or edit a widget, change theme between light and dark, set the default theme, add a theme extension, change fonts, change language, set the default language, add a new language, add a translation, make an API request, rename the app, and change the package name.

There is a note attached to the screen and widget cases. The agent already follows the project's leads: ScreenUtil for sizes, localization for strings, theme for colours, `MyWidgetsAnimator` for API states and `CustomSnackBar` for toasts. No extra briefing needed.

The repository layout backs this up. There is an `AGENT.md` at the top level alongside `.agent/`, and the `Coming Soon` checklist is ticked for AI agent coding guidelines for more reliable vibecoding, AI agent skills for easier use, and updating dependencies to work with the latest Flutter versions. The last two releases were dedicated to this: v3.0.0, tagged AI Skills Arrived, on 2026-09-05, and v3.0.1, tagged AI Skills + Coding Guidelines, on 2026-09-06.

The house style: ScreenUtil, MyWidgetsAnimator, CustomSnackBar, localization

The conventions an agent is told to follow are worth reading as a design brief, because they are the opinions the template encodes.

ScreenUtil handles sizing, so that a layout matches a design file. The README is direct that you must set the artboard size in `main.dart` for the app to be responsive and to look like your design, whether that comes from xd or Figma:

    ScreenUtilInit(
      designSize: const Size(375, 812), // change this to your xd artboard size

`MyWidgetsAnimator` handles the widget swap during an API call, which is the loading, success and failed states as a single reusable unit rather than three repeated blocks. `CustomSnackBar` handles toasts. Strings go through localization rather than inline literals, and colours come from the theme rather than hardcoded values.

The theme is a variable rather than a constant, which is what allows the agent to handle change theme, set the default theme and add a theme extension as three separate operations rather than a sweep through the codebase.

The alternative is the standard Flutter starter plus a package for each concern, assembled by you. The difference in approach is that this template gives you a named component for each recurring problem and a rule that says which one to use, and it is that rule, more than the code, that is the actual product. The trade is that every one of those choices is now a constraint, and `CustomSnackBar` is the snackbar your app will use whether or not it is the one you would have chosen.

Renaming the app and wiring Firebase, command by command

The clone and start section is a set of concrete commands, and they cover the chores that otherwise leak into a team's first week.

The package name changes with a pub run of the change_app_package_name tool:

    flutter pub run change_app_package_name:main com.new.package.name

The app name is renamed with:

    flutter pub run rename_app:main all="My App Name"

And the launcher icon is regenerated by replacing `assets/images/app_icon.png` with your own icon and running:

    flutter pub run flutter_launcher_icons:main

The Firebase path is the part with a real dependency on an external service. You need the Firebase CLI, and the template asks you to activate the FlutterFire CLI globally:

    dart pub global activate flutterfire_cli

Then you follow the Firebase guide and run the configure command for your project:

    flutterfire configure --project=flutter-firebase-YOUR_PROJECT_ID

The README notes that Firebase has added a step that makes adding a Flutter app to Firebase take two steps, and flags an important caveat for iOS, which requires extra steps on your side to receive FCM notifications, following the Apple integration documentation.

One detail is worth pausing on. FCM and Awesome Notifications are initialised in `main.dart`, so once the app is connected to Firebase it is ready to receive notifications without further work, and if you want to send the token to your own API, the function is already there in the FcmHelper class:

    static _sendFcmTokenToServer(){
        var token = MySharedPref.getFcmToken();
        // TODO SEND FCM TOKEN TO SERVER

That last snippet has a TODO in it, which tells you where the template's scope ends. Everything up to the handoff to your backend is wired, and the handoff itself is yours to finish.

What the changelog says about the packages underneath

The What is new list names the packages, which is more informative than the feature list for anyone deciding whether to adopt.

GetX 5 support is available on a V5 branch rather than on the default branch, and the earlier release v2.0.0-flutter-latest-getx5, tagged as an update to the latest Flutter version with GetX 5 support, dates from 2024-09-01. So the default branch and the GetX 5 line have diverged, and the release history shows the template has been through at least one significant platform migration.

The storage decision is worth noting because it is a reversal. The project replaced get_storage with SharedPref, citing unsolved testing problems with get_storage. It also separates the local notification helper from the FCM helper, which is a small change that makes the two notification paths independently testable.

The testing story is the strongest part of the list. There is an integration test for BaseClient, an integration test for the Awesome Notifications helper and an integration test for the Widget Animator, plus unit tests for BaseClient, MySharedPreference, MyHive and the Localization Service. The repository layout shows both a `test/` directory and an `integration_test/` directory, which matches.

The underlying packages are named in the commented-out acknowledgment section of the README: get_cli to create the project, screens, controllers and handle dependency injection, GetX for state management, navigation and dependencies, flutter_screenutil for responsiveness, hive as the local database, shared_preferences for persistent key and value storage, and awesome_notifications for local notifications.

Read that list as the dependency footprint of the template. Every one of those is a package your app will carry, and each represents a decision someone else made for you.

Licence, branches and what you inherit

The licence is MIT, which is the permissive end of the range and means you can take the template, change it and ship it inside a proprietary app, as long as you keep its copyright and licence notice.

The default branch is `master` rather than `main`, and the last push was on 2026-09-22, a little over a month ago, so the template is being worked on. The repository is not archived, and the release history shows the last two tagged releases landing on consecutive days in September 2026 with the AI skills work, which is what you would expect from a maintainer who added a feature area and then tightened it.

What you inherit is worth being explicit about. You inherit a theme system, a localization system, an API client with defined error states, two notification paths, a shared preferences wrapper, a Hive database, a set of named UI components and a set of rules about which to use when. That is a coherent house style, and it is exactly what the agent skills are there to protect.

The cost is that these decisions are now the project's decisions, and diverging from them means fighting the conventions. If your team already has a pattern for API error handling, or a design system with its own components, then the template's value drops sharply and its constraints rise. The template is at its best for a small team starting a new app with no established house style, and at its worst for a team that has one and has to unlearn it.

The template also does not include the backend. The FCM token function ends in a TODO to send it to your server, the API layer expects endpoints you define, and the Firebase project is yours to create. The promise is a configured front end, and only that.

Editorial conclusion

Adopt flutter_getx_template if you are starting a Flutter app with GetX and want the recurring setup, theming, localization, notifications and API error handling already in place, and if you intend to work with an AI coding agent that needs written conventions. Do not adopt it if your team has its own state management or routing conventions, since the template's value is precisely that it has made those decisions for you, and note that the latest tagged release is v3.0.1 from 2026-09-06 with GetX 5 support living on a separate branch. Before you start, set the ScreenUtil design size to your own artboard in `main.dart`, and read the `.agent/` skills and context files so the agent does not invent a second architecture beside the one in the repository.

Frequently asked questions

Official sources

1. EmadBeltaje/flutter_getx_template on GitHub
2. Issues
3. License: MIT
4. README
5. Releases