First of all, thank you for developing FontBase — it’s been my go-to solution ever since FontExplorer X was discontinued.
I’ve tested the app on multiple machines, including my M3 Pro and a test client MacBook Air, and everything worked as expected. However, when deploying FontBase on an M1 Pro Mac, I encountered an issue where fonts could not be activated properly.
Sometimes the UI showed the fonts as active, but they weren’t available in applications like Microsoft Word or Adobe InDesign.
Here’s what I tried:
Verified file permissions
Reinstalled the app and cleared all caches
Checked font validity
Switched between local folders and OneDrive-synced folders
Removed spaces and symbols from font filenames
Unfortunately, none of these steps resolved the issue.
Solution: I enabled “Open using Rosetta” on the FontBase app, and font activation started working immediately on the M1 Pro.
What surprised me is that the .dmg file appears to include both the arm64 and x86_64 binaries. Shouldn’t there usually be separate installers for different architectures?
Also, why would the ARM-native version fail to activate fonts while the Intel version under Rosetta works?
I’d be happy to provide logs if that helps — and I’m curious:
Is this a known issue?
Are separate installers planned?
Could this be related to the version difference between the M1 (running 2.21.0) and the Air (running 2.22.4)?
Hello @Gr0undEveres1T, thank you for your post and welcome to the forum
And a separate thank you for the details you’ve provided.
Before going any further, may I ask if the situation on M1 Pro is the same with FontBase v.2.22.4 and whether there is a specific reason to keep v.2.21.0 in this case?
sorry for the delayed response — it took me some time to test everything again in the client’s environment (M1 Pro).
When using version 2.22.4 on the M1 Pro, I need to run it with Rosetta, and I occasionally experience crashes.
With version 2.21.0, on the other hand, I don’t encounter any crashes, and it runs natively without requiring Rosetta.
One thing I found noteworthy: when clicking the red close button in the top-left corner, the app actually quits completely. This caused some confusion for the client, as they expected it to behave like many other macOS apps, where closing the window simply hides it and keeps the app running in the background. The yellow minimize button behaves as expected and keeps fonts activated.
This might be relevant for users who switch between macOS and Windows, since window behavior differs across platforms and can lead to inconsistent user expectations.
Hello @Gr0undEveres1T, thank you for the update and the additional information
First off, sorry for not addressing all of your initial questions right away
“…why would the ARM-native version fail to activate fonts while the Intel version under Rosetta works?”
That’s a very good question, cannot be 100% sure that the version here is the root cause, will need further investigation on our part unfortunately.
“Is this a known issue?”
It isn’t from what I understand, no.
“Are separate installers planned?”
Not at the moment from what I know.
“Could this be related to the version difference between the M1 (running 2.21.0) and the Air (running 2.22.4)?”
It shouldn’t be, no, since there were no changes to how font activation works between these two app versions as far as I know.
Also, thank you for the comment on the red button The expected behaviour you’ve mentioned can be achieved by enabling “Hide to tray on close” in the Settings page.
Regarding Rosetta and font activation - in your first post you’re mentioned that sometimes the UI showed the fonts as active, but they weren’t available in applications. Was this behaviour consistent, i.e. did this happen to the same fonts, or was it that sometimes the same fonts would be activated as expected while in other instances the activation issue would occur?
