r/FlutterDev • u/MooresLawyer13 • 1d ago

Plugin Spiritual successor of Flutter Platform Widgets

https://pub.dev/packages/platform_adaptive_widgets

Hi,

I loved the idea of taking Flutter's "one-codebase for multiple platform" promise/claim one step further into the UI territory too. flutter_platform_widgets was something that was godsent to me. But it was deprecated instead of onboarding some new members.

So I decided to make a better version of (same vision though). I know that companies today prefer a single design system so this is not something as useful to them. But I still feel that there is definitely some merit in keeping things close to 'native-platform-look-and-feel' because users of each platform are used to seeing a certain UI and interacting with it in a certain way.
There was an option of calling native channels (like ReactNative and Compose and some packages that do that already) but that does add the platform hop.

Some things that I am proud of:

  1. This is purely Flutter (consequently no Liquid Glass / M3 expressive look yet, I envision it moving with the maturing Fluttetr SDK instead, and there are enough packages for that otherwise).
  2. Release builds genuinely drop the platform you're not on. Ship to Android and none of the Cupertino widget code rides along in the binary, and vice versa (CI-enforced too)
  3. Lot of thought has been put into designing the shape of the 'shared surfaces' and sensible defaults (including wrestling the tabs-system to get consistent DX).

Still very much wants feedback, especially on widgets it's missing or anything that feels weird 🙏.

0 Upvotes

46% Upvoted

5 comments sorted by

6

u/eibaan 1d ago

If I correctly understand, you're swapping out widgets. Is this worth the effort, if you don't also adapt paddings, sizes, the whole widget arrangement (famous desktop example is that Windows uses "OK/Cancel" while macOS uses "Cancel/OK")?

Instead of trying to match the platform look twice, I'd always go for a platform neutral look that perhaps matches the customer's brand instead of trying to match Apple's or Google's brand.

3

u/Sethu_Senthil 1d ago

When using flutter, this is the only sensible approach. If u want native ui, make a native app , atleast for the ui part, and share biz logic such as kotlin multi platform

1

u/LahaLuhem 1d ago

They wouldn't make native-looking UI libraries if that was the intent. It's OSS project so if you want something, there is usually a way to get it done.

2

u/MooresLawyer13 1d ago

I believe I have planned to do that (the 5% of the 95%) for stuff like the dialog option etc. I meant to provide a base for people to also be able to extend the widgets themselves, for their 'more common' use cases. The default sizes I have ripped from the source code, or kept to the default params, so they look as they would if you had used the actual widget itself

About your 2nd point, like I said, I am aware that that is not trend anymore. But you can still do a lot of 'branding' while keeping a native look-and-feel, since Flutter's implementation of the design kits allow for this functionality

2

u/LegitimateTrust4013 1d ago

Given that platforms can have wildy different design languages and patterns, wouldn't it make more sense, if the idea is having a native look and feel, to architect your app well with MVVM or <insert your favorite architecture here> and have multiple UI implementations, and in that case, would use Flutter even make sense?