Font Activation Issue on M1 Pro – Works Only via Rosetta

Questions
1

Hello FontBase team,

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)?

Looking forward to your insights.

Best regards,

~ Gr0undEveres1T

2

Hello @Gr0undEveres1T, thank you for your post and welcome to the forum :pray:
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?

Thank you again,

3

Hello @yuriy,

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.

~ Gr0undEveres1T

4

Hello @Gr0undEveres1T, thank you for the update and the additional information :pray:
First off, sorry for not addressing all of your initial questions right away :pensive:

“…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 :pray: 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?

Thank you again,

5

Hello @ ALL.

I found the solution for my problem. There was an old FontManager on the macOS Client installed which caused issues. On some mac’s it caused issues on others it didn’t.

But to keep it short:

Adjusting Permissions


chmod -R 770 "/Users/<user>/Library/Fonts"
chmod -R 770 "/Users/<user>/Library/Fonts (Disabled)"
chmod -R 770 "/Users/<user>/Library/Application Support/FontBase"
chmod -R 770 "/Users/<user>/FontBase"
chmod -R 770 "/Applications/FontBase.app"

Font Activation Path

Fonts are activated in the following path:

"/Users/<User>/Library/Fonts/FontBase"

If this folder does not exist, fonts cannot be activated. In that case, create the folder manually and apply the permissions as shown above.

Conflict with FontExplorer X

It has been observed that the legacy FontExplorer X includes a helper tool called FontFolderProtector, which deletes the folder mentioned above.

To prevent this:

  • Either uninstall FontExplorer X
  • Or rename the helper tool:
cd /Applications/FontExplorerX.app/Contents/Helpers/
mv FontFolderProtector FontFolderProtector.bak
  • Kill the current running process of FontFolderProtector via the macOS activity monitor or however you want :stuck_out_tongue:
  • After that, recreate the folder and activate the fonts.

Finally, :partying_face:

6

Forgot some pics. Nevermind, I can’t embed them, it won’t let me. And I can’t find the edit button. HELp!!

Btw if you decide to delete the following folder for some reason, you have to restart FontBase:

sudo rm -rf /Users/<user>/Library/Fonts
7

Welcome back @Gr0undEveres1T and thank you kindly for the investigation :folded_hands:
Given this new information it seems more and more likely that permissions were the culprit after all, as suspected :thinking:

Also, the post edit button should appear after you click the three dots icon on the left of “Reply” under a post.

Thank you again,