Scrivener on Sequoia

I realize Keith’s policy is to not comment on compatibility with unreleased OSs, but I’ve been running the developer beta of Sequoia with Scrivener installed and (touch wood) so far no issues found (other than a need to get around to installing some fonts.

FYI, I am booting Sequoia from an OWC TB3 Envoy Express Enclosure with Gigabyte 1TB NVMe with performance that closely matches the internal install of Sonoma. Anyone considering it, don’t try with a USB 3.x device - dismal outcome.

Useless bit of info. The Macintosh wallpaper option is ‘interesting’. Selection of colors to try.

1 Like

For less experienced users who might encounter this thread, this is your annual reminder that running Scrivener with any beta operating system is unsupported and entirely at your own risk.

You can expect to see a Sequoia-compatibility update to Scrivener (if needed) soon after Sequoia’s official release. Generally speaking, though, I recommend waiting for at least the first couple of Mac OS maintenance releases.


Agree completely, and even for ‘experienced’ users it can be a minefield.

That’s why I have in the past had a second system reserved for such risks. Being between ‘second systems’ using the boot from external to separate the beta and apps running on it is the next safest.

I’d go further than @kewms warning and add anyone tempted to do the same - DON’T use your active projects in this scenario. A foul-up could wreck them.

Edit: You might be tempted to ask, given this caveat, why bother? Simple. Being in a beta program involves trying out the beta OS, trying to stress it, trying to find incompatibilities and that involves installing and running the apps one uses day to day, but carefully keeping it clear of essential data.


Have you messed with APFS’s volume feature yet? This is what I use exclusively now for testing versions, as you can add new volumes to the master partition on the fly, and each will will resize themselves only as big as they need to be, to hold whatever you put into them.

It used to be I’d never recommend playing with the new beta to anyone but someone with a fair amount of experience with using a computer, as repartitioning a live drive isn’t something you want to do lightly. But now it’s a piece of cake to get a second bootable volume.

Now the hard part is finding the convoluted and buried instructions for how to do something as basic as installing an OS on a fresh disk though.

The other upside to this approach is that you can continue to evaluate the stability of the new OS as time goes by, and switch easily when you’re ready. It’s already there, you don’t have to upgrade your previous installation, you just stop booting into it and copy your user folder over. You can delete the old volume when you’re comfortable in the new slot. This has the added side-benefit of meaning you get a clean install every year, which seems to cut out a lot of the problems in my experience.

1 Like

I’ve used the volume feature, but on my current system (2TB) I’m over ⅔ used and have a couple of major video projects to work on so decided the easy way was to go with the external I just happened to have recently erased.

That’s encouraging. I’ve been leery on occasion of going this route despite it seeming the simple, intended method because Apple’s page on running multiple operating systems notes that

Later macOS versions can install changes designed to keep your Mac secure, and these changes can affect your computer’s ability to continue using a significantly earlier version.

The key there is, I assume, the unspecified “significantly earlier”; are you typically running only one version off? I’m nearly always lagging behind that in an ongoing resistance to Apple “improving” everything I use.

I’ve never run into a case where a newer version bricked an older one. The widest spread I have is 10.14–11.x on an old Intel though, and that one can’t install anything newer, while the newer computer can’t install anything older than 13.x.

The oddest thing I’ve run into historically was how newer system volumes than what you booted into sometimes won’t auto-mount and throw a harmless error dialogue on every reboot. But I think that’s mainly an issue between 10.14 and anything macOS 11 or later (or maybe .15 and later). I don’t actually know because I fixed it.

The fix...

This, along with suppressing auto-mount on any volume you please, can be suppressed with the following procedure:

  1. Fetch the UUID of the volume using the following command:

    $ diskutil info /Volumes/NameofVolume | grep 'Volume UUID'
  2. Edit the fstab file analogue:

    $ cd /etc
    $ sudo vifs
  3. Add the following line to the file, where the part following UUID= is copied from what was discovered in step 1:

    UUID=FF9DBDC4-F77F-3F72-A6C2-26676F39B7CE none apfs rw,noauto

    (Note: older volumes should use ‘hfs’ of course.)

  4. Save the file, and execute the following command to cause the system to become aware of the configuration file:

    $ sudo automount -vc
1 Like