Repository navigation
[ENH]: macOS backend should match system app icons #31895
Description
Problem
A minor issue, but one that has bothered me for several years.
Apple switched to squircle icons with macOS Big Sur in 2020. This style persisted until macOS Tahoe in 2025, when they subtly changed the corner radius and added support for dark/clear/tinted icons.
On macOS Big Sur through macOS Sequoia, we stand out a bit:
In Tahoe with dark icons enabled, we stand out a bit more:
This could be a visual accessibility issue, since there's now a very-bright dot on the outskirts of your vision.
Apple locks most of the app icon appearance functionality behind private API, so perfectly matching dark/clear/tinted Tahoe icons with the operating system is prone to breakage. Even if we made an icon matching the dark Tahoe design perfectly, this would break in Golden Gate as they have changed the highlight angle.
There is also no public way to determine if the user has light/dark icons selected (a separate preference from light/dark system appearance), although there is an undocumented AppleIconAppearanceTheme setting. Using it could likely create a maintenance issue in the future.
All that said, I'd like to add macOS icons for basic light mode and dark mode.
However, I'm not sure of the exact legal issues here. There are some open issues related to Logo Usage (#18716) which seems to imply that exact color combinations should be used. However, the current macOS icon (which is rendered from matplotlib.pdf) doesn't match those specific colors.
We could match the icon closer to what is found on the main site. Something like this:
(From left to right: System Settings, Preview, Matplotlib mockup, Matplotlib current, Apple's template icon. This is the Big Sur - Sequoia style, Tahoe changed these icons.)
Proposed solution
No response
Activity
iccir commentedon Jun 14, 2026
Additional note: on iOS, if the operating system detects that your icon hasn't been updated to match the new guidelines, Apple will take your icon and attempt to apply glass effects to it. This has resulted in my own trademarked icons getting modified on user devices (sigh).
macOS does something similar, which folks have referred to as "squircle jail".
Right now, the macOS backend uses
NSApplication.applicationIconImage, which bypasses squircle jail in Tahoe. However, there is no guarantee that this behavior won't change in future versions of macOS. A lot of us were hoping that Apple would relax the squircle requirement in macOS Golden Gate, but this doesn't appear to be the case.timhoffm commentedon Jun 15, 2026
I don't care too much, but if you want to make a mac icon compliant variant, go for it. You can generate appropriate logo input from
https://matplotlib.org/stable/gallery/misc/logos2.html
iccir commentedon Jun 27, 2026
My apology, I have this working in my local branch, but I forgot to update this bug with my findings.
I did a lot of research into reversing Apple's icon metrics. In Big Sur through Sequoia, Apple provided Photoshop templates, so the metrics were easy to reverse. In Tahoe and Golden Gate, I had to write a program to "wiggle" between a blank white icon and a programmatically-generated one.
As previously mentioned, the best that we can do is set
NSApplication.applicationIconImageto an approximation. Using my linked file, an almost exact approximation can be made using these parameters:A few notes:
My approach has been as follows:
Use 6 image files: 2 content files, 2 squircle masks, 2 shadows.
In the macosx backend: draw a shadow, set a squircle as the mask, and then draw the content. These are all lightweight operations (it's actually more performant on my machine than trying to render the current PDF!) and the total file size is 74KB. It may be possible to configure meson to not include these files if building the Windows or Linux binaries.
The current result of the work-in-progress:
Sonoma + Light:
Golden Gate + Dark:
In both cases, the wedges of the logo follow the
jet()base colors per my comment in #18716.