Known Issues - iOS

Scriptwriting Text Appears to Vanish when Switching to Light Mode


Material written using Scriptwriting mode, while using Scrivener in Dark Mode, will appear to vanish to exporting or printing the text. It will also appear to vanish when switching to Light Mode.


When using scriptwriting mode in Dark Mode, all text typed into new documents will be incorrectly marked as white in its formatting. This will be invisible to you so long as you remain in dark mode, given how this mode recolours text to a monochrome light blue, regardless of its underlying colour settings.

Since the text is in fact white, any medium that uses a white background (such as PDF export or the default text editor settings) will result in white-on-white text.


Since the problem is the formatting of the text itself, the issue can be corrected by removing the text colour assignment from the text:

  1. In the affected documents, tap anywhere in the text editor to bring up the contextual menu, and tap "Select All".
  2. Tap the Format Brush icon in the toolbar to bring up the formatting settings for the selected text.
  3. The top entry in this palette will be invisible, since it previews the formatting of the text, which is white. So tap into the first entry in the list within the "Style" tab to access font settings.
  4. The second entry is used to change the text colour, tap this, and select the top left swatch, which shows a red slash drawn through it. This will remove the colour assignment entirely.

Image size changes on Desktop after editing on iOS


Images that have been fully embedded into the text editor (which is the default mode of operation, unless one specifically uses image links to the disk or binder) can lose their DPI setting when the binder item they are embedded within has been edited. The most likely visible effect of this will be the visible image size changing, as DPI is the only tool Scrivener uses to change the visible size of an image in the editor.

The underlying image itself remains untouched, with regards to its pixel dimensions. This bug only impacts the metadata that declares how large the image should display itself.

Images that are set to Mac-native screen resolution (72 DPI) will not see any effect from this bug since the nature of the bug is to reset the DPI to 72.


This is currently done intentionally in order to display the image sensibly. A large print-size graphic when displayed in the iOS text editor would be so large that it might take several seconds to scroll past on an iPhone and would severely disrupt the flow of editing your text. Given the fact that the iOS text engine does not have a mechanism for displaying these large images sensibly, the choice was made to scale the image to its intended size, as printed, and in doing so dropping the DPI of the image down to what is native for iOS, 72 DPI.


If you are not using Scrivener to store print-ready graphics, then you should consider using 72 DPI graphics that have been resampled to the size you wish them to appear. Not only will that save disk space and keep your project from bloating with unnecessary pixels, but it will ensure maximum compatibility across all platforms.

Otherwise for those that need print-sized graphics, this problem impacts images that are displayed on iOS, meaning the best workaround is to ensure that images are not displayed in this simpler editing environment. The most effective and easiest way of doing this on a Mac will be to make use of the Insert ▸ Image Linked to Document ▸  submenu, whilst storing the images themselves in the binder. Those who make use of a great number of images may prefer setting Link to images dragged from binder into editor, in the Behaviors: Dragging & Dropping preference pane, so that this is done automatically.

Otherwise, and for those on Windows, the best course of action is to leave images outside of the Scrivener project, and link to them using the Insert ▸ Image Linked to Disk... command (found in the Edit menu on the PC).

Linked images of all sorts will be displayed as an icon in the iOS editor, indicating where the image will be placed, but the original image will never be loaded or processed (and indeed for disk links the original image would not be accessible from another device).