Hmm, it looks like Qt is crashing on macOS 26 for some reason.

Attaching crash log. Working on a solution.

qt_crash_log.txt

I'm still investigating. It would appear that using CTFontCollectionCreateFromAvailableFonts() exposes a bug in __NSGetSystemFontVariants.

When AppKit creates a window, it calls +[NSFont monospacedDigitSystemFontOfSize:weight:], which calls __NSGetSystemFontVariants and we hit the bug. This occurs on the first launch of matplotlib using an interactive framework in macOS Tahoe 26.5.2 (and possibly earlier/later).

As far as I can tell, our usage of CTFontCollectionCreateFromAvailableFonts() in mpl_get_available_fonts is 100% correct. We are correctly getting the font list and building the font cache.

I need to call it for the night, but I'll investigate a workaround/fix tomorrow.

Our usage of CTFontCollectionCreateFromAvailableFonts() is correct. The issue is related to the order we load frameworks and how the runtime sets up toll-free bridging between CTFont and NSFont.

Consider the following example:

import ctypes
from ctypes import c_void_p, c_double

LOAD_APPKIT_FIRST = False

appkit = None
if LOAD_APPKIT_FIRST:
    appkit = ctypes.CDLL("/System/Library/Frameworks/AppKit.framework/AppKit")

objc = ctypes.CDLL("/usr/lib/libobjc.A.dylib")
coretext = ctypes.CDLL("/System/Library/Frameworks/CoreText.framework/CoreText")

CTFontCollectionCreateFromAvailableFonts = (
    coretext.CTFontCollectionCreateFromAvailableFonts
)
CTFontCollectionCreateFromAvailableFonts.argtypes = [c_void_p]
CTFontCollectionCreateFromAvailableFonts.restype = c_void_p

collection = CTFontCollectionCreateFromAvailableFonts(None)

objc_getClass = objc.objc_getClass
objc_getClass.argtypes = [ctypes.c_char_p]
objc_getClass.restype = c_void_p

sel_registerName = objc.sel_registerName
sel_registerName.argtypes = [ctypes.c_char_p]
sel_registerName.restype = c_void_p

objc_msgSend = ctypes.cast(
    objc.objc_msgSend,
    ctypes.CFUNCTYPE(c_void_p, c_void_p, c_void_p, c_double, c_double)
)

if not appkit:
    appkit = ctypes.CDLL("/System/Library/Frameworks/AppKit.framework/AppKit")

NSFont = objc_getClass(b"NSFont")
selector = sel_registerName(b"monospacedSystemFontOfSize:weight:")

font = objc_msgSend(NSFont, selector, 0, 400.0)

If LOAD_APPKIT_FIRST is True, we will load AppKit before our call to CTFontCollectionCreateFromAvailableFonts(). This sets up bridging and allows later calls in AppKit that assume a NSFont object to instead operate on a CTFont object.

If LOAD_APPKIT_FIRST is False, AppKit will later try to send an Obj-C message to a CTFont object and we will get an exception. I'm not 100% sure of the exact details here. I could find out, but it would require a few hours of decompiling AppKit code.

I can make the above example reproduce on all versions of macOS; however, the bug in matplotlib only reproduces in macOS 26+. On 15-, I assume that something else is loading AppKit into memory before we use CoreText.

There are two possible solutions:

1. Load AppKit explicitly in mpl_get_available_fonts()
2. Use multiprocessing to call mpl_get_available_fonts() in a subprocess.

1 is the simpler choice for now. 2 could be used in the future if we encounter more "run this in a separate process to work around an OS bug" situations.

10.14 and below just barely summed to 0.1% of usage in December 2024, so we should be safe to stop testing on it.

To be clear: macOS 10.14 and macOS 14 are not the same version. We haven't tested on 10.14 in a very long time.

macOS 10.14 Mojave was released in 2018 and last updated in 2021.
macOS 14 Sonoma was released in 2023 and last updated in 2026.

Yes, macOS version numbers are confusing, especially with the jump from macOS 15 to macOS 26.

I'm debating whether this should be backported. I don't want to explicitly drop support in 3.11 as it's not a meso release, but the workflows are failing again. It seems like there's a new problem in LLVM patches, though I can't locally see a difference in the checksum.

I don't think we are dropping support are we? We are just saying that it is more of a pain for us to set up a dependable CI build system and test on this specific platform, but if someone else is able to build it I think that it should still work. IMO we should backport this to make our lives easier and if someone else knows the magic build scripts to get this to work then they can certainly contribute and we can re-add it.

The root of the problem is that Homebrew on macOS 14 and earlier will continue to be unreliable, due to their support policy of classifying Sonoma as a "Tier 3 configuration".

Right now, we use Homebrew for the following packages:

• llvm
• ccache
• ffmpeg, ghostscript, imagemagick, inkscape (Image conversion?)
• font-noto-sans-cjk font-noto-sans-cjk-sc
• ninja (could be installed from pip?)
• gobject-introspection, gtk4

Could we have a "brewless" builder that loads the fonts and llvm from binaries, doesn't test GTK, and uses native libraries for image conversion? I think the main thing that we would miss out on would be GTK on older macOS versions, but if homebrew is flakey, I don't know how many people will be using this.

GitHub is retiring the macos-14 images on November 2nd, so my previous comment is moot.

@meeseeksdev Backport to v3.11.x

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:
They assume that the base project is the Git remote upstream and your fork is origin.

1. Update backport branch.

git fetch upstream v3.11.x:v3.11.x
# or `git pull upstream v3.11.x` if you are on v3.11.x

2. Create PR branch.

git switch -c auto-backport-of-pr-32372-on-v3.11.x v3.11.x

3. Cherry pick the first parent branch of this PR on top of the older branch:

git cherry-pick -x -m1 a8cabafa9a9b80f59ca5eee929ac02f4649b9851

4. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #32372: ci: Bump all the macOS builder images'

5. Push to a named branch:

git push --set-upstream origin auto-backport-of-pr-32372-on-v3.11.x

6. Create a PR against branch v3.11.x, I would have named this PR:

Backport PR #32372 on branch v3.11.x (ci: Bump all the macOS builder images)

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.

Per meeting, we are going to go ahead and put this on 3.11.x since Homebrew is broken and the macOS 14 images are going away next month anyway