Glyphs 2 compatibility with macOS 12.3

Note: The latest version of Glyphs 2 is now compatible with macOS 12.3.

Since macOS 12.3 no longer includes Python 2.7 (which is needed by most plugins and scripts), you need to download and install it manually if you want to use extensions with Glyphs 2 on macOS 12.3.

Download the macOS 64-bit installer here:

Then, install pyobjc with the Terminal app by entering the following text and pressing Return:

pip2 install pyobjc

Original post:

Telling from the current beta of macOS 12.3, Apple appears to be making changes to the system that will make it impossible for Glyphs 2 to run in the upcoming system version.

That means that if you intend to keep using Glyphs 2, do not upgrade to macOS 12.3.


No plans to update G2 to keep it compatible?

I’m looking into it.

The problem is that Apple removed python from the system. And as Glyphs 2 is expecting it at a specific place, it will crash when it is not there. What I can do is to change that path. But then you need to install python yourself or it will still crash.

The good thing is that I can “fix” this without recompiling. So I can adjust specific versions (if someone needs that).

That leads to another issue. How to distribute the new binaries. Just pushing them through the updater will not work as it isn’t a new version. And it will make the app unusable for all that didn’t install python.

1 Like

Does this affect Glyphs Mini?

No, it is only because of the missing python. And Glyphs Mini doesn’t need it.

1 Like

I’d be glad to keep G2 for a while. Maybe you could just post a download link with a little instruction?

1 Like

The download link has the system requirements next to it.

void main(argc, argv) {
    if (is_python_available()) {
        execvp("Glyphs", argv);
    } else {
        execvp("A tiny Cocoa executable that asks users to install Python 2 and then exit", argv);

I’d also be happy if it’s addressed. Making a shim like above in C and sneaking it into CFBundleExecutable might do? Apart from the extra executables no recompilation should be required, but I’m just saying and surely it will be a layer of complexity if it’d worked…

I’m working on it. I know what to do but it is a bit more work.

1 Like

I don’t mean to rush but do you guys have any estimated timeline when new Glyphs 2 will drop? I still need Glyphs 2 in my current workflow so that’s pretty critical.

So to reliably keep Glyphs 2 projects as usable we need to keep some old Macs around? And if they die… that’s just it? Deal with it? Even FontLab doesn’t force this.

I really wish the computer racism from the team would drop and Glyphs would be made with cross-OS compatibility in mind (ie using QT and not going full ham on Swift or whatever flavour Apple chooses next year). At least then if a very specific version of Windows or Linux is needed for whatever dependency we could throw it in a VM.

I’m working on it and it should be finished in the next few days.

And you don’t need to worry too much as the 12.3 version just started beta testing and the will be released in a couple of weeks.
And MacOS 12.2 works fine. So no need to get an old Mac just yet. Just don’t update to 12.3 until you got the Glyphs update.


Sorry, but this is false. FontLab 5 has not worked for a few system iterations already. FontLab 4 has not worked for a long time in current OSes.

And no specific software version anywhere is kept up to date for ever. WordPerfect does not run on Monterey either. So, we will do our best to keep Glyphs 2 around, but we have limited resources. If you want to keep old software running, you will need to keep an old system around, like everyone else who wants to do that, yes. Qt would not help much with that.

Or in different words, why would you want to upgrade your OS, but refuse to upgrade your app?

1 Like

FontLab dropped support for FontLab Studio 5 long before the MacOS changes made it incompatible. There were known bugs that they wouldn’t fix because they were focused on releasing FontLab 6. Cries for help fell on deaf ears. They couldn’t have cared less. They kept telling people to upgrade to FontLab 6, which was essentially in a very crude beta stage. At the time it was so unstable you couldn’t work on it for more than 10 minutes without it crashing. It was then I decided, if I had to learn a different workflow I might as well make the jump to Glyphs. I’m very happy with the switch. It’s a great app, and the support in this forum is very responsive. Glyphs 3 has been out for a while and the developers are still making the effort to keep Glyphs 2 useable. I think that is amazing.



I don’t think it’s a fair comparison, but since you’ve mentioned FontLab, I’d like to respond.

FontLab Studio 5.0 for Mac was published in 2005 as a PowerPC app (the dominant technology at that time). In 2012-2013, FontLab had 3 engineers work for almost a year (collaborating with a very active user community) to port the app to Mac 32-bit Intel, and published this as a free 5.1 update, even though it was a heavy rewrite. In 2019, FontLab published FontLab Studio 5.1.6, again a free update that brought compatibility to macOS 10.13 High Sierra and 10.14 Mojave.

But it has been virtually impossible to keep the old (ancient, really) codebase of FontLab Studio 5 going, as it originated in FontLab 3 times. Apple has since removed all system components that made FontLab Studio 5 work.

The original FontLab VI was indeed a painful release. It was an app written from scratch, similar in a way to Glyphs 1. The current FontLab 7.2 is miles ahead of the (now similarly ancient) FontLab VI — over 650 feature additions and improvements and several thousand fixes.

I’m not sure if Glyphs plans to provide updates to Glyphs 1. But of course I’m glad that there will be a free update to Glyphs 2 to run on macOS 12.3 that no longer ships Python. Similarly, FontLab 7 will publish a free update so that the app runs on macOS 12.3 (FontLab 7 is similarly affected by the change).

AFAIK, RoboFont is also not providing fixes to old versions. I think it’s understandable — Glyphs, FontLab and RoboFont have modest developer teams, and the font technology has been progressing rapidly. The Glyphs developers, the FontLab developers, the RoboFont developers put a lot of effort to match the requirements to go into the future. I think the progress in all these apps is quite amazing. :slight_smile:


Ps. Rainer is right: there is no magic formula, no Qt or anything else helps you with that. And each solution has its caveats.

FontLab 7 uses Qt, which is great is some aspects. Qt lets FontLab make the app affordable, because FontLab 7 can run on the Macs, and onbany inexpensive hardware that runs Windows, and even, with some limitations, on Linux. But it also makes it impossible to use some conveniences that Apple offers. And Qt isn’t bug-free.

Sometimes you cannot serve all people. Some users of FontLab 7, and I imagine Glyphs as well, on the Mac, do not want to upgrade to the newest macOS, because they use software that doesn’t run on the newest OS. For example, some people may want to still use Adobe CS6 apps for various reasons. Others actively upgrade their macOS to the newest.

But as a developer, when you use frameworks like Cocoa/XCode or Qt, you’re faced with the fact that these frameworks get newer versions which ship improvements, but often they also drop support for older OSes.

So when we build a new version of our apps, we need to choose: do we ship the app also got those who prefer older macOS, but other users don’t benefit from the improvements (or simply bugfixes) in those frameworks, or do we use the latest framework but accept that our app won’t work on older systems?

It’s not easy or sometimes not possible to do both. And the truth is, the more versions and OS combination you work on as a developer, the more complex it is, and the more testing it requires.

This is by no means limited to font editors. But font editors are particularly affected because in the last year’s, font technology has actually developed quite rapidly (color & variable fonts, also the progression of Unicode, shaping engines and screen rendering).

We all want to make type design tools that let you make all kinds of fonts, for any script and in any format. But that naturally means that we put our energy primarily into the newest versions of our apps.


Or export your project(s) to UFO, which is, you know, “a cross-platform, cross-application, human readable, future proof format for storing font data”. And, please, don’t put unnecessary pressure on developers. I guess they have just enough without it.

Not sure what ufo will help if you need to work on on the font or rely on exporting it from Glyphs. And with the help of glyphsLib, you can generate fonts with fontMake.