ci: Bump all the macOS builder images - #32372

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.