How to properly target multiple platforms in a "native" way

[GroovinChip]

Hi all,

The question of targeting multiple platforms in a way that feels "native" to that platform is interesting for me because with the introduction of packages like fluent_ui and macos_ui, there are now four separate "app" widgets available for use (not including WidgetsApp):

• MaterialApp
• CupertinoApp
• FluentApp
• MacosApp

Additionally, there are now multiple kinds of ThemeData available for use:

• Material's ThemeData
• fluent_ui's ThemeData
• MacosThemeData
• The various ThemeData provided by yaru (linux)

Some pub packages like platform_widgets have tried to solve this problem for mobile, but with three desktop platforms in the mix, it's not so simple any more.

If the desired outcome is to build native looking apps for both mobile and desktop platforms, the question becomes: How can we do this so that the various root "apps" and ThemeData don't collide with each other and are used properly on each platform?

The approach I have taken thus far is to split out each desired platform "app" into an /apps directory and create a PlatformAdapter widget that will return the proper root widget based on the current platform. Then, I split out screens by platform, and simply share reusable widgets across the whole app that can adapt as needed. You can see a demo of this in action over at https://github.com/GroovinChip/macosui_counter.

What are your thoughts on this question, the approach I've taken so far, and what other solutions might be available?

Thanks and looking forward to a great discussion.

Reuben (GroovinChip)

[Andrew Brogdon]

This is a really interesting question, if for no other reason than there are multiple correct answers, and even within those answers, things can get messy. MaterialApp, for instance, will create a Material Theme widget, which in turn creates a CupertinoTheme, but using a Material-based set of values for the data. :)

I can point to a few apps that have used different approaches. Flutterfolio from gSkinner, for instance, just uses a MaterialApp widget and hacks the theme quite a bit. They're going for an interface that respects certain navigational paradigms and input methods, but otherwise doesn't use a ton of "native-looking" UI components. That means they don't explicitly need a CupertinoApp at any point in the hierarchy.

When we did the Building for iOS talk at I/O a couple years ago, the code we built took the opposite approach, and created a MaterialApp for Android and a CupertinoApp for iOS. As a result, the app could do some cool tricks like use flat navigation on iOS, and drawer-based, stacked navigation on Android. Finding the right themedata to use for a font, though, ended up being a challenge. I had to build an InheritedWidget that would look for *either* a Theme or CupertinoTheme widget above it in the tree, grab its TextTheme data, and then pull particular values out, which it then shared with widgets below.

All-in-all, I think either approach can work as long as you're very clear with yourself about which parts of your app you want to adapt to the platform and which parts you don't. If you get that right, you can build widgets at those decision points to branch according to platform, and then have other widgets capable of bringing those branches back together.

This is a topic that's only going to become more important, BTW, so I'd be interested to hear what other folks think!

-Andrew

--
You received this message because you are subscribed to the Google Groups "Flutter Development (flutter-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flutter-dev/9c262b58-1fd0-4960-b4ad-f34c1235af03n%40googlegroups.com.

[GroovinChip]

Thanks for your response, Andrew! I'll check out the talk you linked, because I think that more closely addresses this issue, which is getting a truly native look and feel per-platform. And I agree that this will become more and more important, so if anyone else has anything to share, I'd love to hear it!