The Material 3 guidelines currently do not list additional adaptations for Material Design on iOS. Therefore, the crux of this issue is to fill the gaps in the Material 2 guidelines (issues listed below). Since Flutter is a cross-platform framework, we want to balance:

1. Avoid making developers specify distinct app layouts for Android and iOS, and
2. The desire for Flutter apps to be indistinguishable from native iOS apps

We plan to make small improvements that are automatic or easy-to-use, and are open to suggestions for improvements. InMatrix/veggieseasons_adaptive#6 is currently investigating an implementation of adaptiveness for M3.

Background

There are two types of platform adaptations:

• Automatic: done by the framework (see documentation below)
• Developer-driven: require developers to write some code, e.g. .adaptive constructors

Docs & code

• Platform adaptations documentation: Flutter adaptation philosophy & automatic adaptations
• Material/Cupertino adaptive widget problem definition: defines 4 types of adaptiveness
  • Material<->Cupertino switching for clear 1:1 widgets #33830: sub-issue, tracking .adaptive constructors for type # 4
• flutter/samples/tree/master/platform_design: sample project shows a Flutter app that maximizes application code reuse while adhering to different design patterns on Android and iOS

Research

Google-only, sorry. go/flutter-platform-adaptation-research.

Material 2 adaptations

Guidelines for cross-platform adaptation

• Toolbars: APIs too dissimilar
• Iconography (automatic and Icons.adaptive)
• Add .adaptive constructor for Dialogs #102811
• Controls
  • Switches (Switch.adaptive)
  • Add .adaptive constructor for single-selection #102809
  • Add .adaptive constructor for multi-selection #102810
• Edge swipe (automatic)
• Transitions (automatic)
• Typography (automatic)
• [Proposal] Add an adaptive constructor for RefreshIndicator widget #119361

Related issues

• 📚 cupertino library tracker #102812