Breaking change: IconData is now final in Flutter (3.43+)

[ellie-me]

Hello there!
Hope you have a wonderful weekend.
First of all, thank you for migrating PhosPhorIcons to Flutter!

I've run into this today whilst I was working on the latest beta of Flutter and found that this package will break if not refactored soon.

What's happening

IconData has been market as a final class. Preventing from extending it, which currently breaks the inheritance package's core implementation:

class PhosphorIconData extends IconData

With recent Flutter versions (expected to become stable around 3.44), this now throws:

ERROR: ../../../../.pub-cache/hosted/pub.dev/phosphor_flutter-2.1.0/lib/src/phosphor_icon_data.dart:5:32: Error: The class 'IconData' can't be extended outside of its library because it's a final class.

This affects the following wrapper classes:

• PhosphorIconData
• PhosphorFlatIconData
• PhosphorDuotoneIconData

The package currently relies on inheritance from IconData, but Flutter now enforces composition instead of inheritance for this class.

I tried on finding out a solution but I am really short on time to help with this issue right now, although I have a suggested direction with a possible migration path:

• Use plain IconData for standard icons (regular, bold, fill, etc.)
• Replace PhosphorIconData with a wrapper class (composition instead of inheritance)
• Keep a custom wrapper only for duotone icons (since they already require special rendering logic)

example of this idea:

class PhosphorDuotoneIconData {
  final IconData primary;
  final IconData secondary;
}

And update PhosphorIcon to handle both IconData and custom types.

Temporary workaround

For now, the only workaround is downgrading Flutter to a version prior to this change which is around Flutter 3.43 if I am not mistaken.

Reference docs with breaking change details

https://docs.flutter.dev/release/breaking-changes/icondata-class-marked-final

Further steps

I think for now we should watch what happens over the course of the following days because the API could change direction, but. If the code matures and the new API stays then this package has to be refactored to not break projects depending on phosphor_flutter.

Thanks, I hope this is useful for anyone in the future that would be facing this issue.

Eleonor.