Known Issues - macOS

If applicable, the macOS version number will be printed before the bug title, such as the following, "[10.13]", which means this bug should only appear in macOS 10.13 "High Sierra", or "[10.12.4+]" which would indicate any version since Mac OS X 10.12.4 "Sierra".

[macOS 14+] Searching for terms in the Help menu that are contained in document titles may cause slowdowns and eventually hang

Symptoms

If there is a term contained in document titles in your Binder that is also contained within nested menu items (examples being “Merge,” “Split,” “Copy,” etc.), conducting a search for that term in the Help menu may cause the program to slow down, and could eventually lead to a hang. This does not appear to occur when searching for first-level menu items.

Cause

The menu search tool is Apple code, and it is interacting poorly with Apple system settings, which causes an Apple infrastructural process to hang. Scrivener itself is in fact not hanging and has nothing to do with it, rather the OS itself is hanging, which is why common recovery necessitates powering down the whole system (which is unusual for a software level hang).

Workaround

You will likely have to power down your system should you encounter this hang. If you recall the term you were searching for when it happened, click the magnifying glass above the Binder to open up Project Search, set the filters to search "Title" only, and conduct a search for that term. Then, if possible, you may want to supplement that word with another that is not contained within the menus, or avoid searching for that term in the future.

[macOS 10.13 or older] MultiMarkdown may throw an error or crash

Symptoms

When compiling to a file type that involves running the embedded copy of MultiMarkdown, such as converting to HTML, the compiler may crash or display an error and fail to produce the intended document.

Cause

The newest official version of MMD was compiled using a newer Mac, so as to provide Silicon and Intel support. This build does not run properly on versions of macOS prior to 10.14.

Workaround

The direct-sale version of Scrivener is capable of using an installed version of MultiMarkdown instead of the copy that it ships with. There are a few ways you could install a version that works with your system:

• Install an older official version that was compiled back when it still worked. Unless you wish to compile the latest version, the package installer for 6.5.2 will be the easiest way to install a working copy.
• If you use MacPorts or Homebrew, you may find that it is capable of installing a more up to date version that has been compiled to work on your system.

For those using the Mac App Store version, it is not allowed to use UNIX utilties outside of the software. You will either need to try installing the direct-sale version which might detect your Apple receipt and unlock itself, or if that does not work, compile using the plain "MultiMarkdown" option instead, and handle further conversion in Terminal.

[macOS 11.x or older] Archived YouTube pages claim to be ending browser support

Symptoms

Those who use Scrivener's webpage archive feature to store YouTube videos will note that the content of the page has changed to state that Google will be ending support for "this browser".

Cause

Scrivener makes use of the operating system's WebArchive format for storing and displaying archived pages. This is the same type of file you will get when saving a page from Safari, using default settings. The WebArchive format has always been somewhat crippled by measures used by Google's YouTube website, making it unable to fully download for offline storage. It seems that this also extends to actual text within the page itself, since that is capable of changing over time (theoretically, once you archive a page you should not lose access to it even if the original website goes down).

We can only presume what the message means, as it is up to Google to make web pages that work with standard display tools. Perhaps they intend to stop people from using WebArchive in the future, or perhaps the message is a mistake or an oversight. Ultimately if you are concerned about it, you should contact Google for a statement of their intent, and ensure that you use Safari to demonstrate that the problem impacts all Mac software that makes use of this mechanism.

Workaround

For pages that force content to be displayed dynamically, it is typically best to use the Project or Document Bookmark systems to store these links (refer to §10.3 in the user manual PDF, for further information on this feature). The preview pane in the inspector may still not display the page properly, but it will be easy to load the page into a fully capable Web browser by double-clicking the bookmark. There may be other methods of more securely archiving content for safekeeping, but we encourage you to ensure that such services are in compliance with Google's terms of service.

[macOS 11+] Korean words are justified incorrectly when word wrapping

Symptoms

Korean text can be justified more simply than English, where words can be broken in almost any place between lines, creating a more uniform text per line. For those experiencing this issue, Korean will act more like English without hyphenation, cutting no words, and introducing too much space between words on line.

Cause

Word-wrapping, justification and how different languages use them, are all handled by the macOS text engine, which Scrivener uses. Scrivener itself has no programming for laying out text, to this detail. The problem can be observed in the free TextEdit program that comes with the Mac, as well, showing it is not a problem that can be fixed in Scrivener.

Workaround

The only known solution is to revert to macOS 10.15, prior to when Apple broke this behaviour.

Use of Latin "gibberish" conflicts with non-Latin fonts in compiler

Symptoms

When using some non-Latin fonts, such as Arabic, in the Compile Format Designer interface, the font will be immediately reset to one that can display Latin characters, on account of how the filler text used to preview formatting uses these characters.

Cause

Given how the text engine works, it will attempt to find a font that can display the characters given to it, if the current font lacks them. Some fonts lack a Latin compatibility character set, and attempting to use them in the compiler will fail.

Workaround

Using a more complete Unicode font that supports both the intended characters of the document and Latin base characters should avoid the problem entirely.

Spotlight fails to index text within projects

Symptoms

When a Mac is functioning correctly, searching for text that you have written in your project will highlight that project as a search result, allowing you to quickly open it just like any other Spotlight document result. In cases where the Spotlight engine is broken, only the name of the project, or any text found in the Quick Look preview, will be discovered.

Cause

The precise problem is unknown, that in our testing we have concluded that it has nothing to do with Scrivener's technology itself, and is rather more likely a symptom of corruption or malfunction in the Spotlight engine, or the macOS infrastructure that supports it.

We recommend contacting Apple customer support for advice on how to fully troubleshoot and repair Spotlight.

Workaround

If you use Spotlight to access frequently used projects, consider using the File ▸ Add Project to Favorites menu command, where will always be easily accessible from this menu.

If instead you use this feature to find stray bits of text you've written over the years, the only good solution is to bulk export text from projects, and file them in such a way that you can locate and open the project they relate to. E.g. in a folder named after the project they came from.

Use of Scratch Pad causes repeated crashing

Symptoms

Any normal use of the Scratch Pad feature, such as creating a new note, or attempting to edit an existing one, can cause the software to crash. This can happen with either great regularity, or now and then.

Cause

We have had a number of potential conflicts reported with other software, but none that could be independently confirmed off of the original machine. However one report was confirmed: combining the Scratch Pad feature with any iCloud synced storage area.

Workaround

If you use iCloud, first try storing your Scratch Pad folder in a location that isn't synced by iCloud.

If you do not use iCloud, or that alone did not work, the other reports we've had suggested other software using global shortcuts could conflict. The root source of the crash makes the assessment unlikely, and as noted above, we've never been able to reproduce for that specific condition, but it's worth trying, by shutting down all other software and testing Scrivener alone with Finder (Pay particular attention to tools that only reside in the "menu bar". Even those can conflict.)

Use of STKaiti font causes system to request font download

Symptoms

When using the Chinese font, STKaiti in your projects, the system may periodically request that you download the font again, as though you did not previously have the font and need to have it installed.

This condition can possibly lead to cases where the text using this font becomes corrupted and cannot be recovered by a mere font change.

Cause

The cause is unknown, and appears to be a lower level macOS issue that multiple applications can encounter.

Workaround

Simply do not use this font. We advise you avoid it entirely, given the low but real risk of losing work due to corrupted text.

[10.15] Slow performance in Composition Mode

Symptoms

Typing speeds can slow dramatically, and the overall system may become sluggish, when using Composition Mode with a background image in Scrivener.

Cause

The source of the problem is not yet known, and we are still looking into fixing it.

Workaround

Simply remove the image from your project's settings. You should find performance increases dramatically when doing so:

1. Open Project ▸ Project Settings....
   
2. In the "Background Images" tab, set the Composition Mode Backdrop to "No Backdrop".
   
3. Click Okay to save your settings.

Crash on launch with CODESIGNING error

Symptoms

Scrivener or Scapple crashes when launching the software. The crash log will contain the following information toward the top of the report:

Exception Type: EXC_BAD_ACCESS (Code Signature Invalid) 
Exception Codes: 0x0000000000000032, 0x000000010fb275c0 
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: Namespace CODESIGNING, Code 0x2

Further in the report, the appearance of the text "sentinel" will appear, followed by a string of numbers, followed by ".dylib". For example: sentinel-4581354897452564.dylib.

Cause

This crash is caused by a conflict with an older version of SentinelOne security software. Some unknown process in that software is causing Scrivener and Scapple to fail the code signing check (which is used by Apple to verify the authenticity of your software), despite our software all being correctly code signed and notarised.

Workaround

The most recent versions of SentinelOne have been patched to fix the conflict that was causing hardened software like our to crash. You should update to this version, or submit a request to your IT department to do so.

If you are working in a context where SentinelOne cannot be updated, you may download an older version of Scrivener 3.1.1 or Scapple 1.3.1, which both have a lower level of security, but should function in tandem with SentinelOne.

Please do note that this version uses an outdated activation system, tied to a company that is no longer in business. When their activation servers go down, you may have to manually cancel activation every time the software is launched. We apologise for this inconvenience.

Spell Check Stops Working

Symptoms

Misspelled words will not be highlighted in red, straight quotes will not automatically switch to smart quotes, double-hyphens and triple periods will not switch to em-dashes and ellipsis (respectively). This may happen immediately after installation, or it may happen after years of the spell-check working correctly.

Cause

This is caused by a timing error where individual elements of the editor window are initialised in the wrong order, resulting in a disconnection with the operating system's spell-checking system. The timing is so sensitive that it impacts very few systems, and when it does, it may not impact them all of the time. For example, a system that was working for years may suddenly experience this problem after a system update or the installation of new software, because the overall timing of the system has shifted just slightly.

The actual triggers involved are unknown at this time. We only can speculate that they are consistently done, and in a unique fashion, so since those that experience this bug do frequently, while most users of Scrivener will never see it.

Workaround

At this time, the only known way to get the text engine's substitution and checking engine working again is to close and reopen the project.

System Text Preferences button does not work

Symptoms

When using the Mac App Store version of Scrivener, clicking on the System Text Preferences... button in the Corrections preference pane will do nothing. This is not a problem when using the direct-sale version.

Cause

Apple no longer allows software that has been sandboxed to request System Preference panes to be opened, using the existing methods of doing so. We will continue to look for alternative methods as time goes by.

Workaround

One can of course simply load System Preferences from the Apple menu and navigate into the Keywords pane, to click on the "Text" tab.

Lists export with extra numbers or bullets/numbers appear where they shouldn't

Symptoms

There are two common symptoms for this same underlying problem:

• Only when exported or compiled, areas of your work obtain list numbering or bullets. There is no sign of this in the editor, though you may see some odd paragraph formatting in the affected area that is difficult or impossible to remove.
• Lists look fine in Scrivener, but when compiled produce additional bullets or numbers, such as "2. 2. The second line item".

Cause

List formatting can be fragile, and sometimes when copying and pasting between different programs, the list markers themselves can be lost or made physical (in the sense that they are just characters in the editor as though you typed them in).

Workaround

Fixing this problem is easy and should be permanent:

1. Select all of the affected text in the editor, and use the Format ▸ Lists ▸ None menu command to strip out any latent list formatting.
   
2. If necessary, manually delete any visible itemisers left behind. As described above, these are not part of the list any more and are normal text.
   
3. Select the text that should be a list, if any, and apply your preferred listing format.

Problems with Asian Scripts in the Outliner

Symptoms

When synopses are displayed in Scrivener's outliner, writing in the synopsis area using Eastern scripts such as Korean can sometimes be problematic.

Example: using "2-Set Korean" and typing "d, k, f, x, p, d, j" should result in "알테어"; in the synopsis area of the outliner, this may sometimes turn out as "알ㅔ테어".

Cause

When synopses are displayed in the outliner, formatted text is used to display the title in bold and the synopsis in a smaller, coloured font. In order to ensure that no other formatting is allowed into the synopsis area--which is unsupported--Scrivener has to ensure the correct font is being used as text is entered. However, some fonts don't support all characters, and many fonts don't support all Eastern script characters. The way the macOS text system handles this is to substitute other fonts that do support the necessary characters, in order to display and enter the text correctly. Unfortunately, there is no mechanism for checking whether font substitution is in progress during typing, so when Scrivener fixes up the font to ensure that no extra formatting has crept in, it can mess up the font substitution, causing certain characters to get entered incorrectly.

Workaround

Given that the issue is caused by Scrivener temporarily swapping to a font that doesn't support the necessary characters, the workaround is to choose a font for the outliner that fully supports the script you are using. To do this, go to the "'Appearance" pane of the preferences and set the Outliner Font. AppleGothic works well for many Eastern scripts, including the Korean example given above.

Status

We still hope to fix this bug in the future so that the workaround is not necessary, but we have yet to find a satisfactory solution.