macOS Catalina: Fixing Emacs After an Upgrade

Since the upgrade to macOS Catalina, I’ve had two serious annoyances with Emacs. Here’s a little insight into how I fixed them.

Issue 1: I Couldn’t Access Certain Folders

After the upgrade, Emacs was unable to access special folders, like the Documents folder. This is a ramification of the User Data Protection enhancements that were made in Catalina.

Here’s the gist of why this exists: In a previous version, macOS started displaying user prompts (similar to iOS) to grant application permission for accessing things like contacts, photos, location, etc. These prompts were displayed when using special APIs designated for those purposes.

Alas, there was an easy way to bypass these prompts. Rather than using APIs to, say, access your contacts, you could just read the contact database via the filesystem. Catalina now enforces these permissions at the filesystem APIs, as well. This means that, because it doesn’t even ask for permission, Emacs is simply forbidden from accessing certain files.

Apple did provide an escape hatch: Full Disk Access. You, the user, can provide this privilege to an application, and it is allowed to access all files that your user would otherwise be able to access. It’s pretty easy: Go to the Security section of System Preferences, find Full Disk Access in the list, and then add Emacs:

But…this solution didn’t work. After doing this, I still couldn’t access my documents folder. Solving this is directly related to the second issue that’s been nagging me since the upgrade to Catalina.

Issue 2: Spotlight Can’t Bring Emacs to the Front

I commonly switch between applications on macOS by pressing cmd-space to bring up Spotlight, then the first few letters of the application name, and finally return. It’s often quicker than finding the icon via cmd-tab. Unfortunately, this method stopped working, too.

As it turns out, the binary embedded in Emacs.app is…actually not a binary. Instead, it’s a Ruby script. From the script:

#
# This launcher code is from emacsformacosx.com and is not part of Emacs
# proper. It exists so that there can be a single download that contains
# binaries for all supported Mac OS X versions.
#
# Why not just use a fat binary? Because fat binaries can only hold 1 of
# each architecture and Emacs has multiple x86_64 architectures binaries.
#
# Why are there multiple x86_64 binaries? Because the Emacs source does OS
# feature detection at compile time instead of at run-time. So if you build
# Emacs on 10.9 then it will contain hard-coded calls to 10.9 APIs and will
# not run on 10.6. If you compile it on 10.6, then it will also run on 10.9,
# but it won't take advantage of any of the features in 10.9.
#

Although this never caused problems on prior versions of macOS, here, it is responsible for both of these issues:

• Full disk access does not apply to Emacs because the permissions were not granted to /usr/bin/ruby.
• Emacs can’t be launched again because it is already running, but the running binary doesn’t actually match the Ruby script. Spotlight gives up.

The Solution

On Catalina, the Ruby script will always choose to launch the bundled binary Emacs-x86_64-10_14. So, if you simply move it in place of the Emacs launcher script, everything starts working as normal. At the Terminal, just run these commands:

% cd /Applications/Emacs.app/Contents/MacOS
% mv Emacs Emacs-launcher
% mv Emacs-x86_64-10_14 Emacs
% cd /Applications/Emacs.app/Contents/
% rm -rf _CodeSignature

And, with that, Emacs should correctly receive its Full Disk Access permission, and Spotlight will correctly bring it to front (n.b., it’s still required to add Emacs to the Full Disk Access section of the security system preferences).

Note that, because we have been performing surgery on the Emacs app, its code signature is no longer valid. The last command above removes the code signature from the Emacs binary. On my machines, I had no issues. If you can’t launch Emacs after running these commands, try following the steps in this document from Apple.

Conclusion

One final caveat: This works for me using homebrew-cask-installed Emacs version 26.3. In future versions of Emacs, it’s possible that the correct binary might be something other than Emacs-x86_64-10_14.

If you’ve been plagued by these problems, I hope this post helped.