in iOS 13 some UIColor constants in the UIKit palette have been revised and updated. This proposed change (https://github.com/flutter/flutter/pull/40566/files
) is to reflect these color changes. More specifically:
- CupertinoColors.activeBlue is now an alias of CupertinoColors.systemBlue, which adapts to the current BuildContext.
- CupertinoColors.activeGreen is now an alias of CupertinoColors.systemGreen, which adapts to the current BuildContext.
- CupertinoColors.activeOrange is now an alias of CupertinoColors. systemOrange, which adapts to the current BuildContext.
- CupertinoColors.destructiveRed is now an alias of CupertinoColors.systemRed, which adapts to the current BuildContext.
* "Adapts to the current BuildContext" means the color is an instance of CupertinoDynamicColor and can be resolved against a BuildContext. For example, CupertinoColors.activeBlue can appear differently when resolved against BuildContext that implies
dark mode and against BuildContext that implies light mode.
In addition to the color constants change, I propose to remove CupertinoSystemColors and CupertinoSystemColorData entirely, and add iOS 13 system colors and UI element colors to CupertinoColors as constants. This would allow us to use
these color values as default values in functions/methods/constructors, instead of having to use null to indicate default values.
Generally the proposed changes shouldn't break apps API-wise, unless you are already making use of CupertinoSystemColors in your code. An notable exception is widget tests where colors are checked for equality.
With the introduction of CupertinoDynamicColor (a subclass of color), two colors may not be considered equal even if they have the exact same RGBA value, as their runtimeType may be different. If it is only
the RGBA values you want to check for equality, instead of expect(widget.color, expectedColor), you can write: