Support Flutter 3.47 standalone material_ui package in GetMaterialApp

Is your feature request related to a problem? Please describe.

Flutter 3.47 introduced the official standalone material_ui 1.0 package and an opt-in migration from package:flutter/material.dart to package:material_ui/material_ui.dart:

GetX 4.7.3 still imports package:flutter/material.dart internally. As a result, applications that run the official migration:

dart fix --apply --code=migrate_design_widgets

cannot pass the new Material types to GetMaterialApp. The old and new classes have the same names but are different Dart types.

Minimal example:

dependencies:
  flutter:
    sdk: flutter
  get: ^4.7.3
  material_ui: ^1.0.0

import 'package:get/get.dart';
import 'package:material_ui/material_ui.dart';

void main() {
  runApp(
    GetMaterialApp(
      theme: ThemeData(),
      darkTheme: ThemeData.dark(),
      themeMode: ThemeMode.system,
      home: const Scaffold(),
    ),
  );
}

This produces errors such as:

The argument type 'ThemeData (material_ui)' can't be assigned to the parameter type 'ThemeData? (flutter/material.dart)'.
The argument type 'ThemeMode (material_ui)' can't be assigned to the parameter type 'ThemeMode (flutter/material.dart)'.

The same split affects GetX APIs and extensions that expose legacy Material types. For example, context.theme returns the legacy ThemeData, so extensions declared on material_ui.ThemeData are unavailable.

Describe the solution you'd like

Please add first-class support for the standalone material_ui package in GetX, including:

migrating Material imports used by GetMaterialApp and related navigation/UI APIs;
allowing GetMaterialApp to accept material_ui.ThemeData and material_ui.ThemeMode;
updating context/theme extensions and other public APIs that currently expose legacy Material types;
documenting the minimum Flutter version and migration path;
considering this change for both the current stable line and GetX 5, as appropriate.

Because changing exported/public Material types is a breaking API change, a major release or a separately versioned compatibility release would be understandable.

Describe alternatives you've considered

Continue using package:flutter/material.dart. This works in Flutter 3.47, but the bundled design library is scheduled for formal deprecation in a future stable release.
Replace GetMaterialApp with material_ui.MaterialApp/MaterialApp.router and manually integrate GetX routing and dependency injection.
Use MaterialUiCompatibilityBridge for legacy widget subtrees. However, the bridge only maps inherited theme/localization data; it cannot solve compile-time type mismatches in the GetMaterialApp constructor.

Environment where this was reproduced:

Flutter 3.47
Dart 3.13
GetX 4.7.3
material_ui 1.0.0

Thank you for considering support for Flutter's new independently versioned Material package.

Give it up, man. This package is effectively abandoned and no longer maintained. Whether for personal or corporate projects, I’ve completely removed it and switched to zenify/bloc or riverpod. It’s better to remove it early for the sake of maintainability; otherwise, as the project grows, migrating away from it becomes increasingly difficult.

I will update in pub dev tomorrow

Since the new version requires upgrading the Flutter version and forces a breaking change to the API, I would have to move the project to version 5 anyway. Therefore, I think it's time to release version 5 as stable and either create migration documentation or incorporate it into the CLI.

I’m just sharing this feedback because I initially thought it would take only a few hours, but I’ve set aside today and the next three days to work FULL-TIME on GetX.

@jonataslaw

Is there any update on the release version? @jonataslaw

@jonataslaw

How long time release 5.0 version? @jonataslaw

Hello! We are waiting for version 5 adapted to Flutter 3.47, thank you.

It is almost there.

Is there any new information?

@jonataslaw

@jonataslaw how is the migration coming along

@jonataslaw

@jonataslaw Totally understand that things can take longer than expected. It would just be great to get a short update from time to time so we know where things stand.

Even a simple “still working on it” or “no ETA yet” would be enough. Thanks for your work on GetX.

@NebiSarigul

Just as @NebiSarigul said it will be greatly appreciated if we could get short responses or a general idea for the amount of work still remaining as most of us have production level apps that we maintain and some have entire structure built with getx

@jonataslaw

@jonataslaw I know it must be difficult when everyone starts questioning but it will very helpful for everyone if you could provide the update status

@jonataslaw I know it must be difficult when everyone starts questioning but it will very helpful for everyone if you could provide the update status
It would be much better to migrate from GetX to Zenify; there are dedicated AI-powered tools to help boost efficiency. Plus, it supports go_router for routing, and the migration process is quite fast with AI assistance. We managed to migrate our social app in about a week. Take my advice and ditch GetX—you’ll find that writing code with low coupling is a much more pleasant experience.

@jonataslaw

Hi @jonataslaw, we need to talk.

First of all, I want to express my enormous gratitude for the wonderful GetX. Flutter and Dart taught me how to program, but GetX taught me how to actually build applications. It helped me understand state management, routing, dependency injection, internationalization, and so much more.

Over the years, whenever I came across packages such as BLoC, Provider, Riverpod, and others, I always had the same thought: “Why does this have to be so complicated when GetX exists?”

A few years ago, when Flutter 3.0.0 was released, I opened issue #2345 about a problem that affected many users. You fixed it in just one day. That was amazing.

This time, however, this issue has remained unresolved for three weeks, even though you have twice said that the update was almost ready. If you simply do not have enough time right now, we will understand—but please tell us. There is already a proposed solution in PR #3472, kindly prepared by @ashutosh2014 . Please review it and either merge it or let us know what is still missing. As for GetX 5 and #2966, we are prepared to wait another couple of years. ^)

The immediate problem is that GetX 4.7.3 is already blocking us from using parts of Flutter ecosystem. For example, packages such as m3e_typography and m3e_color_scheme cannot be properly used until GetMaterialApp supports the new material_ui types.

Many of us here have been extremely loyal - almost romantically faithful - to GetX, patiently waiting for you to find the time. But even the most loyal relationships can come to an end without communication 😁

I have now opened the same issue Open-Neom/sint#12 in SINT

So, a little confession: if they fix it first, I may finally have to say goodbye to GetX. Sorry.

And once again, thank you for everything GetX has taught me and for all the work you have put into it over the years.

@jonataslaw

@jonataslaw any update

Any update? at least you have that much time to answer just yes or no...

GG

I had to move my project from GetX to signals...

I had to move my project from GetX to signals...

I think the author already moved his own projects away from GetX a long time ago. That would probably explain why he stopped updating it too 😄

I had to move my project from GetX to signals...

I think the author already moved his own projects away from GetX a long time ago. That would probably explain why he stopped updating it too 😄

My project integrates GetX's DI, router, and state management. Now I have to separate them one by one.😅

We know that life is not all about Github. Even if you say you need to take a break for a while, everyone will understand you, rather than being silent like this.

We know that life is not all about Github. Even if you say you need to take a break for a while, everyone will understand you, rather than being silent like this.

Exactly. If the author simply told us, “I’m no longer maintaining this project,” we could accept that, start looking for alternatives, and move on. The frustrating part is being left in limbo, not knowing whether to wait or start tearing GetX out of our projects.

We know that life is not all about Github. Even if you say you need to take a break for a while, everyone will understand you, rather than being silent like this.

Exactly. If the author simply told us, “I’m no longer maintaining this project,” we could accept that, start looking for alternatives, and move on. The frustrating part is being left in limbo, not knowing whether to wait or start tearing GetX out of our projects.没错。如果作者直接告诉我们“我不再维护这个项目了”，我们就能接受，开始寻找替代方案，然后继续前进。最令人沮丧的是，我们现在进退两难，不知道是该继续等待还是该开始从我们的项目中移除 GetX。

Don't hesitate any longer. The fastest migration solution at present is signals + go_router + get_it

Hi everyone - I’ve found a working solution.

After reading “Haha, the author is just teasing you guys, right?” #3471, I started looking seriously for a GetX replacement.

After a deep comparison of five packages, Codex initially recommended SINT. Unfortunately, SINT did not support the standalone material_ui package either, so I opened Open-Neom/sint#12. A fix was promised about two weeks ago, but there has been no update.

I then moved to the next candidate: GetXify.

GetXify already supported material_ui, but it had one open bug that directly affected my application: Aniketkhote/getxify#9. I also reported another blocker: Aniketkhote/getxify#11.

@Aniketkhote fixed both issues very quickly, so I migrated my real application to GetXify. The initial migration commit touched 120 files with 550 insertions and 383 deletions, but most of the work was predictable and mechanical:

Cashr before migration	GetXify / `material_ui` migration
100 imports of `package:get/get.dart`	Imports changed to `package:getxify/getxify.dart`
22 classes extending `Bindings`	Changed to `Binding`
27 `GetPage` declarations with `binding:`	Changed to `bindings: [SomeBinding()]`
14 uses of `SnackPosition.BOTTOM`	Changed to `SnackPosition.bottom`
5 empty `RxnInt()/RxnString()` constructors	Changed to explicit initial `null`
5 `RxStatus` usages	Migrated to `GetStatus`, including the success payload
8 uses of `Get.width`, `Get.height`, or `Get.isDarkMode`	Replaced with `MediaQuery` and theme brightness
3 uses of `Get.testMode`	Tests adapted to GetXify lifecycle/setup
`get_storage 2.1.1` (which depends on GetX)	Replaced with `shared_preferences`

A few migration notes that may save others time:

Put MaterialUiCompatibilityBridge in the GetMaterialApp.builder while third-party widgets still use Flutter SDK Material types. It carries the theme and localizations into those legacy subtrees.
Use the delegates exported by material_ui, e.g. ...GlobalMaterialLocalizations.delegates.
The bridge cannot convert one Dart type into another at a constructor boundary. For packages such as extended_text_field or SDK-based date pickers, import only the required legacy types:

import 'package:flutter/material.dart'
    as legacy
    show Material, MaterialType;

Then wrap that package's widget in legacy.Material(type: legacy.MaterialType.transparency, ...). If the package accepts SDK InputDecoration, include InputDecoration and InputBorder in the same aliased import and use legacy.InputDecoration explicitly.

Replace get_storage if you want the old get package to disappear from the dependency graph. I used shared_preferences for settings and drift for all other data.
Migrate Material imports consistently. Mixing SDK Material and standalone material_ui types is where the confusing “same class name, different Dart type” errors come from.
Adapt route bindings, status objects, nullable reactive values, snackbar enums, screen-size/theme lookups, and tests as shown in the table. These were straightforward search-and-replace changes plus a few small API adjustments.

The current branch uses GetXify 5.0.5 and material_ui 1.4.0. flutter analyze reports No issues found, and the application is working well.

This migration cost me about 16% of one five-hour GPT-6 Astra Medium limit and five minutes of waiting. 🤣

At the moment, I have only one specific, non-critical GetXify issue open: Aniketkhote/getxify#12. It concerns Flutter Inspector lifecycle behavior in a multi-route stack, has a small GlobalKey/KeyedSubtree application-side workaround, and does not block normal use. I expect the author will address it quickly as well.

Everything is working great for me. I recommend migrating to GetXify on pub.dev, and many thanks to @Aniketkhote for taking this on and responding so quickly.

GetX, goodbye! 👋

@Aniketkhote

OMG @Aniketkhote, you’re the real deal! You keep contributing and responding to issues too. Really appreciate your efforts. We waited so long for a GetX update that it’s hard to keep building around it.

Navigation Menu

Repository navigation

Support Flutter 3.47 standalone material_ui package in GetMaterialApp #3469

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Support Flutter 3.47 standalone material_ui package in GetMaterialApp #3469

Description

Activity

wanwenfeng4798 commented on Aug 18, 2026

jonataslaw commented on Aug 18, 2026

jonataslaw commented on Aug 19, 2026

mhdwaelanjo commented on Aug 24, 2026

appdev-thermoworks commented on Aug 25, 2026

virdosdo commented on Aug 25, 2026

jonataslaw commented on Aug 25, 2026

Empty-57 commented on Aug 27, 2026

talhaamin999 commented on Aug 29, 2026

NebiSarigul commented on Aug 29, 2026

talhaamin999 commented on Aug 30, 2026

talhaamin999 commented on Sep 3, 2026

keepwan4798 commented on Sep 4, 2026

ProZhar commented on Sep 5, 2026

talhaamin999 commented on Sep 10, 2026

moinkhan780 commented on Sep 14, 2026

NebiSarigul commented on Sep 15, 2026

Empty-57 commented on Sep 15, 2026

NebiSarigul commented on Sep 15, 2026

Empty-57 commented on Sep 15, 2026

Empty-57 commented on Sep 15, 2026

NebiSarigul commented on Sep 15, 2026

Empty-57 commented on Sep 15, 2026

ProZhar commented on Sep 24, 2026

fisforfaheem commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions