Skip to content

[packages] Migrate packages to material_ui and cupertino_ui #191322

Open

Description

@justinmc

Several packages depend on Material or Cupertino:

  • go_router
  • animations
  • video_player
  • google_maps_flutter
  • image_picker
  • camera
  • webview_flutter
  • file_selector
  • interactive_media_ads

And several more in their examples:

  • path_provider
  • google_fonts
  • in_app_purchase
  • local_auth
  • pointer_interceptor
  • extension_google_sign_in_as_googleapis_auth
  • url_launcher
  • shared_preferences
  • google_adsense
  • web_benchmarks
  • vector_graphics

We should migrate these to material_ui and cupertino_ui. Or, perhaps we should even refactor them to remove the dependency where possible.

Activity

  1. added
    p: material_uimaterial_ui package in flutter/packages
    p: cupertino_uicupertino_ui package in flutter/packages
    packageflutter/packages repository. See also p: labels.
    team-designOwned by Design Languages team
    on Aug 19, 2026
  2. added
    P1High-priority issues at the top of the work list
    triaged-designTriaged by Design Languages team
    on Aug 19, 2026
  3. ricardodalarme commented on Aug 27, 2026

    @ricardodalarme
    Contributor

    I opened a PR to kickstart this migration: flutter/packages#12648. Can we assume it's fine to add material_ui or cupertino_ui to any example? Bc I suppose we want to have as few material_ui and cupertino_ui dependencies as possible in the actual packages, but in the examples, can we agree that adding them is fine?

  4. justinmc commented on Sep 25, 2026

    @justinmc
    ContributorAuthor

    Sorry I missed this, yes adding material_ui and cupertino_ui to other packages where they are using them today (especially in examples) should be fine.

  5. SangWook16074 commented on Sep 29, 2026

    @SangWook16074

    I’m looking into the pointer_interceptor_ios example as a possible small contribution to this migration. I couldn’t find an existing PR for that example. Is it already being handled as part of another PR, or would a separate PR be useful?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority issues at the top of the work listp: cupertino_uicupertino_ui package in flutter/packagesp: material_uimaterial_ui package in flutter/packagespackageflutter/packages repository. See also p: labels.team-designOwned by Design Languages teamtriaged-designTriaged by Design Languages team

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions