Known Issues

A few known issues have longer articles:

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". "[10.12.4+]" would indicate any version since Mac OS X 10.12.4 "Sierra".

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 the 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

Short of uninstalling or disabling SentinelOne, the only solution is to use a version of our software that is not hardened. Otherwise, if this software has the capability to whitelist or ignore our software, that may be sufficient to avoid the problem without removing it entirely.

If you are working in a context where SentinelOne cannot be removed from your system, and whitelisting is not possible, you may download 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 Eastern 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 OS X 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 back in 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.