Scrivener 3: Copyholders and Layouts

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

Ever since Scrivener 1, you have been able to split Scrivener’s editor in two and view two documents alongside one another. In Scrivener 2 we added a new feature which is often missed: the ability to have one editor control the other. So, if you have the corkboard in the left editor, for instance, you can click on the “Automatically open selection in other editor” button in the footer bar (the button showing an box icon with an arrow pointing out of it). With this turned on, selecting a card in the corkboard (or a row in the outliner) causes the document associated with that card (or row) to be opened in the other editor. This added more flexibility to how you could use the two editors.

Ioa recently wrote a blog post on the new bookmarks feature in Scrivener 3. This provides an additional way of referring to documents and research in your projects, because you can now view bookmarked documents right in the inspector. There’s another place you can open documents, too: in Copyholders.


The ability to split Scrivener’s editor in two is very useful. But why only split it two ways? What if you want to refer to more than two documents at a time (or more than three if you’re using Bookmarks)? One problem is the relationship between the two editors: “Automatically open selection in other editor” makes sense if there is one other editor, but no sense if there are several. Likewise, by default, clicking on an internal link causes it to be opened in the other editor—if there were several other editors, you’d have no idea where it would be opened. For Scrivener 3 we wanted to make it possible to split the editor more ways, but without causing the confusion that would ensue with multiple full editors. The solution we came up with we call “Copyholders”.

In the real world, a “copyholder” is a small stand to which you can clip documents in order to refer to them as you write or type—and that’s exactly what Copyholders are in Scrivener, too. In Scrivener 3, both editors now have a Copyholder available. A Copyholder is essentially a subsidiary editor that appears inside the existing editor and which can only show single documents (so it doesn’t support corkboard, outliner or Scrivenings modes). Other than this limitation, copyholders are full editors in their own right, allowing you to view and edit text or look at research files.

To open a Copyholder, you simply drag a document from the binder and drop it onto the editor’s header bar holding down the Option key. (You can also use the Navigate > Open menu, but dragging is fastest.) Below you can see a Copyholder has been opened in the right editor, showing an image of a sunset:

Copyholders therefore provide a great way of referring to more documents at once, but their usefulness doesn’t end there. We’ve extended the “Open selection in other editor” feature introduced in Scrivener 2 so that it can now affect Copyholders. Supposing you have both editors open; one editor is showing the outliner and it has a Copyholder below it:

  1. Clicking on the “Open selection in other editor” button in the outliner footer bar works as before – the icon turns blue to indicate that the feature is active and selecting documents in the outliner will cause them to be opened in the other editor.
  2. Clicking on the button again, though, will cause it to stay blue (on) but the icon will change to indicate that the selection will now affect the Copyholder. So now when you select items in the outliner, they will be opened in the Copyholder instead of in the other editor.
  3. Clicking the button a third time turns it off again.

This makes possible one of my favourite new setups in Scrivener 3. Here’s how I’ve been setting things up:

  1. I split the editor vertically.
  2. In the right editor, I load up the outliner, showing the contents of a folder containing lots of research or notes to which I want to refer while I’m writing.
  3. I Option-drag one of these notes onto the outliner’s header bar to open it in a Copyholder below the outliner.
  4. I click twice on the “Open selection in other editor” button in the outliner’s footer bar so that selecting documents in the outliner will cause them to be opened in the Copyholder below it.
  5. I lock the outliner editor, so that clicks in the binder will not affect the outliner editor even when it is focussed. By doing this, the binder will always affect the left editor.

This results in a dual navigation UI:

Now, whenever I select something in the binder, it opens in the left editor, no matter what. When I select something in the outliner, it is opened in the Copyholder below it. It’s a fantastic way of referring to a bunch of notes and research on the right side of the interface while writing and creating new content on the left. It’s probably the new feature I have used most.


Perhaps that five-step sequence above seems a little too much effort—after all, you’re in Scrivener to write, not play around with the settings. Moreover, Scrivener has a tonne of useful features like this that many users may never discover. We think the dual navigation feature is so useful that we want to make it easy for users to access. To this end, we’ve added several default Layouts that you can choose from the Layouts menu, or from the leftmost toolbar button, and these include the “Dual Navigation” setup:

You’ve been able to create your own Layouts (a way of returning to a particular UI setup with one click) ever since Scrivener 2, but these default Layouts provide some out-of-the-box UI setups that we think will be useful to many users. So instead of following the five steps above, you can simply choose the “Dual Navigation” Layout and all of those steps are done for you. When you’re ready to return the UI to regular navigation, you can choose the “Default” layout (or “Clear All Navigation Options” from the new “Navigation” menu).

Here’s another Layout I think a lot of users will find handy—the “Three-Pane” layout:

And—another favourite of mine—the “Centered Outline” layout:

So, Copyholders provide even more possibilities when it comes to referring to your notes and research, and the new built-in Layouts make it easy to switch between some useful UI setups with just a single click. These are just two of the ways in which we hope Scrivener 3 will prove both more powerful and yet simpler at the same time.

Epub, Kindle and MultiMarkdown Export in Scrivener 3

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

Additional note: This blog post specifically relates to the development of the macOS version, but the improvements that resulted from this development are coming to Windows too.

One of the many areas of Scrivener I wanted to improve for version 3 was its Epub export. Scrivener 2.x creates Epub 2 files, even though the latest Epub specification at the time of writing is 3.1. Moreover, internally those Epub 2 files are a little messier than is ideal. An Epub file is essentially just a zip package containing a bunch of HTML, CSS and XML files (CSS files define the formatting used in the HTML). Scrivener 2.x creates a separate CSS file for each HTML file in the book (when it’s better practice to create a single CSS file that is used by all of the HTML files) and the HTML is a little messy.

Ordinarily, the internals of an Epub file shouldn’t worry anyone except for those who are passionate about parsimony—the most important thing is that it looks as it should on e-reader devices. However, the use of multiple CSS files has a deleterious effect on Kindle files. When you export a Kindle .mobi file from Scrivener, it is constructed using the same code as Epub export, and then converted to Kindle format using Amazon’s KindleGen utility. Scrivener-generated Kindle files look great on Kindle devices, but they don’t work so well with Amazon’s “Look Inside” feature. This is because a bug in Amazon’s “Look Inside” feature means it takes formatting from only the first CSS file in the book, regardless of whether or not it’s the one that’s supposed to be used for the text being displayed. This can result in the text using the wrong formatting—not a great introduction to your book for the reader!

All of these issues originate from a single cause: the HTML generator that Scrivener 2.x uses. To create ebook files, I have to convert the rich text in Scrivener’s editor to HTML format. Apple provides an HTML converter built in to the text system, so I have always used that. However, Apple’s converter only supports HTML 4 (whereas Epub 3 requires HTML 5), it produces rather messy HTML with a lot of cruft, and I have very little control over it (there’s no way of setting it up to use a single CSS for multiple output files, for instance).

For Scrivener 3, then, I needed to find a way of converting Scrivener’s rich text to HTML 5, and I needed more control over the HTML generation. I began by hunting high and low (sing: there’s no end to the lengths I’ll go to) for a third-party converter, but there is very little out there in the way of third-party converters that work with Apple’s text engine. I considered writing my own converter from scratch, but that would be a mammoth undertaking that would require regular maintenance.

The solution? MultiMarkdown. MultiMarkdown can already convert text to HTML 5, and it does so cleanly and allows a great deal of control and flexibility.

The problem? For MultiMarkdown to convert text to HTML 5, the text has to be written in MultiMarkdown syntax—that is, with asterisks denoting bold and italics, pipes and dashes representing tables, greater-than symbols representing the start of block quote paragraphs, and so on. You can’t just pipe rich text though MultiMarkdown and have it come out with the formatting intact.

The solution to the problem with the solution? I spent a couple of weeks writing a full rich-text-to-MultiMarkdown converter. This takes a rich text document and converts it all to MultiMarkdown syntax: bold, italics, footnotes, tables, lists, block quotes—the works. With that in place, to generate an Epub 3 file or an improved Kindle file, internally I could convert the rich text to MultiMarkdown and then the MultiMarkdown to HTML 5.

The result of all of this work is this:

  • Scrivener 3 can export to Epub 3 format.
  • Its Kindle export is also much improved, and should now work fine with Amazon’s “Look Inside” feature.
  • The internals of Epub 3 and Kindle files are tidier, containing only a single CSS file.
  • In Compile, you can optionally override the CSS that is generated. This means that those with experience in CSS will be able to add features such as drop caps (although not many e-readers support that yet) or anything else that CSS and e-readers support.
  • In Scrivener 3, as a nifty side effect of all this work, you can export to any MultiMarkdown format even if you don’t write using MultiMarkdown syntax: you can simply tick a checkbox and have all of the rich text converted to MultiMarkdown during export.

Compiling an Epub 3 file relies in large part on Scrivener 3’s new styles feature—for block quotes and other formatting to appear as expected in the exported ebook, you’ll need to apply styles to the text (something not available in earlier versions of Scrivener). To make the transition to Scrivener 3 as seamless as possible, for the time being it will offer the ability to choose between Epub 3 and Epub 2 export (and between older and newer versions of the Kindle export). This means that you won’t have to worry about updating the text in existing projects to use styles just to get it to work with Epub or Kindle export—you can continue to use the older exporters until you’re ready to update your text or start a new project.

Scrivener 3: Redesigning Compile

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

Scrivener’s Compile feature is powerful and adaptable, but it also seems to be a stumbling block for many users. Whenever someone describes Scrivener as “complicated” and we ask which areas they mean in particular, Compile is usually the first thing mentioned.

There’s a certain degree of necessity to Compile’s complexity (bear with me on this). When I set out to create Scrivener—well over a decade ago now—one of the most important goals for me was that it had to be flexible. I had tried all manner of apps aimed at writers. Back then, most specialised writing apps outside of word processors were built around a particular paradigm. Some wanted you to follow a set story structure, such as Vogler’s 12-step hero’s journey. Those that weren’t built around a popular narrative theory forced a particular structure on you: three acts, each containing several chapters, for instance. Copywrite and Ulysses came the closest to doing anything like what I wanted to do (in that they allowed you to break a larger manuscript down into smaller components without an imposed structure), but they didn’t provide any way of organising the sections of your manuscript into an indented, outline-like arrangement.

What I wanted was to be able to define my own structure, which would be different depending on the project, and to be able to reshape that structure as and when needed. Maybe I’d work in parts, chapters and scenes; maybe I’d only need chapters and scenes, or only chapters. For nonfiction I might organise things differently again. To this end, I built Scrivener around the core concept of a flexible outline—the binder. In the binder you can create folders and text sections and organise and nest them however you want.

Another of my aims was to allow the user to write using any formatting he or she wanted, and then to allow all of that formatting to be changed (optionally) at the export or print stage. So you could write in your favourite font but still output to standard manuscript format.

These two core aims come together in the Compile feature, which takes all of those separate, structured sections and sews them together into a single manuscript, overriding the formatting depending on the output requirements.

The problem we’ve always faced is that these two aims—complete flexibility of organisation and the ability to stitch everything together into formatted documents with specific requirements—are, to a certain extent, at loggerheads. If an app knows that you are writing in parts and chapters, it can provide an export that formats the text accordingly. But if you can structure your manuscript any way you like, when it comes to creating the final document, how can the app know which sections should be formatted one way and which another? How does it know that, say, in Project A, this folder is supposed to be the title of a part, this folder is supposed to be the title of a chapter, and this text document is a scene? Or, in Project B, this text document is a preface but these text documents are chapters, and should be formatted as such?

This has always been the huge challenge underlying Compile, and it’s the reason it has always had a degree of complexity to it: it needs to provide options that allow for any number of possible project structures, along with the ability to format those projects for many different requirements.

For Scrivener 3, we wanted to rethink how we approached this problem. I’m not going to pretend that the solutions we have come up with will mean that you never scratch your head over a Compile option, because there’s no perfect solution (barring machines becoming conscious, in which case I hope Skynet sends back a T-900/715 rather than a T-800/101 to help me, but we’re getting sidetracked). I do hope that Compile in Scrivener 3 makes a lot more sense to people, though.

Compile in Scrivener 2

There are two aspects of Compile that, I think, cause confusion for a lot of people. The first is simply the way we throw all of the Compile options right in your face.

We tried mitigating this a little by adding a “Summary” mode, but generally you need to switch to “All Options” as soon as you want to tweak anything, so most users end up faced with the full gamut of Compile options anyway. These options are powerful and give you complete control over your manuscript, but they are also a little intimidating if all you want to do is change which documents should be treated as chapter headings.

The other source of confusion is the way Compile formatting is applied to the sections of projects. This is all set up in the “Formatting” pane—where you tell Scrivener to show a title for this chapter, insert a “Chapter [Number]” heading for each of these folders, and change the text to Papyrus 16pt for these sections (this is a joke: please under no circumstances use a Papyrus font, unless that circumstance happens to be that the T-900 sent back in time for you accidentally zapped you back to 1997 and now wants you to design the front of a vegan friendship bracelets shop).

The confusion arises over how, in the “Formatting” pane, you have to think in terms of “levels” in the current project outline, like this:

In this example, formatting set up for “Level 1” folders in Compile will be applied to the “Part” chapters in the binder, formatting for “Level 2+” folders (the “+” indicates that this formatting will be applied to level 2 folders and deeper) will be applied to the “Chapter” folders, and formatting set up for “Level 3+” text will be applied to the scene documents.

This is actually a pretty good solution, because it allows you to define how your manuscript should look based on its structure. However, over the years of use and user feedback, we’ve thought a lot of about its limitations:

  • Setting up the levels in Compile like this ties each Compile format to a particular project structure.

  • It’s difficult to have different formatting for the same types of documents on the same structural level.

  • Not everyone finds it natural to think in terms of outline levels. Users think of their documents in terms of what they are as opposed to where they are placed in the outline: as chapters and sections rather than as level 1 folders and level 2 text files.

We spent a long, long time thinking about these problems for Scrivener 3, trying and throwing out a good number of ideas—and implementations—along the way. All those options are needed to offer the flexibility central to Scrivener, and the level-based approach is at heart a good way of applying formatting to projects with an outline structure. So how could we take all that was good about Scrivener 2’s Compile but make it simpler and less intimidating, while also providing more separation between Compile formats and individual projects so that a single Compile format could be used with all sorts of project structures?

Compile in Scrivener 3

This is how Compile looks in Scrivener 3:

Some things you might notice:

  • All of the Compile formats are now neatly listed on the left, rather than being in a pop-up menu. (You can create your own formats using the buttons at the bottom.) This list shows only formats applicable to the currently-selected file type.

  • The middle column shows a preview of roughly how the text will look when compiled. It shows template text rather than text from the current project (because to show the latter would involve compiling the project in the first place). In actual fact, what it’s showing are Section Layouts, a key new concept in Scrivener 3 Compile which I’ll talk about below.

  • On the right are project-specific options. In the screenshot you can see the contents (the list of documents in the project to be compiled), but there also tabs for document meta-data (author name, title) and options (include comments? Include footnotes as endnotes or end-of-page notes?). For ebooks you can also set up the book cover and table of contents here.

  • Next to each document listed in the contents, you’ll notice there’s a Section Type—in the screenshot each document is set either as a “Chapter” or “Section”. This is another key concept which I’ll cover below.

This UI essentially replaces the old “Summary” pane, but it is much more useful. It allows you to set up how the current project should use the selected Compile format, and for everyday use will obviate the need to dig deeper into the more complex options. It can do this because, internally, all of the various Compile options have been separated into project-level options and format-level options. So, for instance, each Compile format contains formatting settings that can be applied to any project, but whether or not you want to include comments for this particular project (for example) is something that you choose here using a quick checkbox.

At the heart of Compile in Scrivener 3 are two new powerful concepts: Section Types and Section Layouts:

  • Section Types are part of a project and tell Scrivener what each document in the project is (for example, a scene or a chapter group).

  • Section Layouts are part of a Compile format and provide different ways for documents to be formatted. So, a single Compile format may contain one Section Layout for formatting chapter titles and another for formatting scenes, for instance.

  • To set up Compile, you simply tell Scrivener which Section Layouts in the selected Compile format should be applied to the different Section Types in your project (“format chapter groups using this layout and scenes using that layout”).

Section Types thus mean that you no longer have to think in terms of outline levels when working with Compile. Instead, you think in terms of what each document is. For example, here are the Section Types that have been set up for the built-in Novel project template:

Each project template comes with some Section Types set up for you, but you can change them to whatever you want. You then assign Section Types to documents in the same way you assign labels or status, via the inspector or outliner (you can also set them in the Compile panel). In this way you can set a folder as a “Chapter Group” or a “Part Group”, for example, and a text document as an “Introduction”, a “Title Page”, an “Appendix”, or whatever the project requires.

Meanwhile, each Compile format is now project-agnostic, and, instead of containing a map of how to format specific outline levels (as in Scrivener 2), they now simply contain a list of different formatting presets (Section Layouts) that can be applied to any documents in your project (based on its Section Type). For instance, the “Standard Manuscript Format” has one Section Layout that simply prints out “Chapter [Number]” in Times New Roman for any document to which it is applied; another prints out the chapter number and title; another prints out the title for a new Part; another formats scene text; yet another formats a whole chapter (a chapter title and text). When you Compile, you simply choose which Section Layouts in the Compile format should be applied to each Section Type in your project, ignoring any that you don’t need:

In the screenshot above, any document that has been set as “Chapter Text” (the Section Type) in the project will be formatted as a “Numbered Synopsis” (the Section Layout) during Compile.

What this means is that Compile formats are no longer limited to working with a particular project structure, and you no longer need to learn how to edit Compile formats just to get them working with your project. Instead, each Compile format comes with a bunch of Section Layouts, and you choose which ones to use with your project. You no longer have to tweak your project structure just to get Compile to format things how you want, and you no longer have to dive into the full swathe of options just to change which documents are treated as chapter headings.

We haven’t completely thrown out the old level-based design, however—after all, it was useful for applying formatting to many similar documents at once. Instead, we’ve moved the level-based setup from Compile to the Project Settings, and it now just provides a way of setting up the default Section Types. So, you can tell Scrivener that, say, any text document at level 3 should be a “Scene” unless you change its Section Type in the inspector or outliner. Where in Scrivener 2 you had to think in terms of outline levels to format your manuscript, then, now this is just something that will save a little time if you learn how to do it. You are free to ignore it and set the Section Types manually.

In practice, if you’re using the built-in project templates, you often won’t need to do anything other than choose the format you want to use from the list on the left and hit “Compile”. But if you’re creating your own project from scratch, it’s now much easier to format that project during Compile. And it’s also easier to create Compile formats that can be used with a wide range of projects.

Under the hood, all of the Compile options that were available in Scrivener 2 are still available in Scrivener 3—and more. But now you access these options by creating your own Compile format.

Many users will never, ever have to use these options, because the pre-provided Compile formats are now so much more flexible. But for those who like to dive into the more technical stuff, or who have specific formatting requirements that aren’t provided out of the box, everything you need is still in there.

We have prepared four videos introducing users to how Compile works for when Scrivener 3 is released. These progress from the basics right through to creating your own formats. Here’s the first one so that you can see the new Compile in action:

Scrivener 3: Doing it with Style(s)

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

Over the years, one of the most oft-requested features for Scrivener has been a styles system such as can be found in most word processors. For those unfamiliar with styles systems, this is what they offer:

  1. Styles are essentially named sets of formatting instructions. For instance, you might have a “Block Quote” style that contains instructions for making the text indented with a smaller font, or a “Heading 1” style which makes the text large and bold.
  2. When you apply a style to a section of text, that section of text knows what style it is. So, when you click into some text formatted as a “Block Quote”, some control in the UI will report that the cursor is currently inside a “Block Quote” paragraph.
  3. If you change the formatting of a style, the formatting of all text associated with that style is automatically updated. This is really the big advantage of a styles system. For instance, suppose you decide that you want all your “Heading 1” paragraphs to be blue and all “Block Quote” paragraphs to be italicised. Rather than having to go through all the text and update each paragraph one-by-one, with a styles system you just update the style, and all text to which it has been applied is updated automatically.

Scrivener 2 on macOS and Scrivener 1 on Windows currently has “Formatting Presets”, but not a true styles system. Formatting Presets provide (1) above but not (2) or (3). You can use them to quickly format a piece of writing, but you can’t easily update formatting to multiple areas of text after you’ve applied it.

All of this changes with Scrivener 3, which introduces a true styles system.

Scrivener comes with a number of styles predefined out of the box:

Assigning them is as easy as clicking in the text whose formatting you want to change and selecting a style from the list. Styles are available from the format bar, the Format > Styles menu, or from the contextual menu. You can even assign keyboard shortcuts to your most frequently-used styles.

Defining new styles works much the same as defining formatting presets in Scrivener 2. You simply select or put the cursor in a piece of text that uses the formatting you want for your style, then go to Format > Styles > New Style from Selection to bring up the New Style panel:

Once you’ve done that, the new style will appear in the styles list for the project, ready for use.

If you want to change the formatting of a style, you follow the same procedure but instead choose Style > Redefine Style from Selection. When you confirm the changes, all text using that style will be updated to use the new formatting across the entire project.

There’s a styles panel that allows you to search through text looking for and selecting particular styles, too.

Scrivener 3 differs from most word processors in that you’ll generally only want to apply styles to text that you want formatted differently—to headings, block quotes and such. In most word processors all text is styled, with the main text using a “Body” or “Normal” style (depending on the word processor). In Scrivener, you’ll want to use “No Style” for most of your text, as this will give you more flexibility when you come to compile or reset your editor default formatting. This system also means that you don’t need to use styles if you don’t want to. For this reason, there is no “Body” or “Normal” style provided by default.

Talking of which, styles are useful enough on their own, but they gain a whole lot more power in Compile. Styles are exported to numerous formats, including Word, and you can use styles to set up the CSS of Epub 3 and Kindle files. Not only that—just as you can override text formatting during Compile in Scrivener 2 (which you can still do), in Scrivener 3 you can, if you wish, override the formatting of individual styles. So, you can style your block quotes in one way when exporting for printing and in another way when creating an ebook. Those working with more technical formats can even enclose styles in custom codes using the prefix and suffix feature.

One of the core ideas of Scrivener has always been that you can write using whatever formatting you want and not have to worry about how the finished product will look until you come to export (Compile). However, historically, one of its weak areas in this approach has been that, although you can override formatting during Compile, any text formatted differently (block quotes and such) can end up getting mangled by these overrides unless you use a complex series of options provided specifically to work around this problem (for instance, Compile > Formatting > Options > Preserve Tabs and Indents). The new styles system solves all of these issues. Now you can tag some text as a block quote or a caption or an email—or whatever you want—and have complete control over how all of this looks in the compiled document, without needing to worry how it looks in the editor (unless you want to—as ever, you don’t have to override anything, it’s up to you).

You might be wondering how this affects the iOS version. In fact, Scrivener for iOS already supports Scrivener 3’s styles system. When you open a Scrivener 3 project in the iOS version, the formatting presets in the formatting palette are replaced by styles.

All in all, styles bring a lot of extra power, flexibility and convenience to Scrivener 3.

Bookmarking Folders in Scrivener 3

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

In a recent blog post, Ioa talked about how, in Scrivener 3, the new Bookmarks feature consolidates and replaces several features, including References, Project Notes and Favorites. You can bookmark any document in a project, or any file on your disk, and these bookmarks sit in a list in the Inspector much as References did in earlier versions of Scrivener.

The big difference in 3.0 is that there’s now an editor directly beneath the Bookmarks list in the Inspector, and the content of any bookmark you click on is opened there. This means that you can browse and edit any bookmarked document right in the Inspector, alongside whatever you are working on in the main editor.

Another cool feature of Bookmarks, though, is that if you bookmark a folder, all of its subdocuments are available for viewing in the Inspector too. Here I want to quickly show how that works in practice.

Let’s say I’m working on a novel, and in my binder I have a “Characters” folder in which I keep a different document for keeping notes on each character in the story. I also have a similar folder, “Locations”, for keeping track of the main places used in my novel.

These are the sorts of notes I’m going to want handy as I’m writing. I therefore add the “Characters” and “Locations” folders to my Project Bookmarks, so that they appear in the Project Bookmarks list in the Inspector:

Because “Characters” and “Locations” are folders with subdocuments, a down-pointing chevron appears on their right in the bookmarks list. If I click on one of these chevrons, I am presented with a menu listing all of the folder’s subdocuments – in this case a list of all my character notes:

From this menu, I select one of my character note documents to load it in the editor beneath the Bookmarks list, allowing me to refer to and update my character notes as I work on my scene or chapter:

Project Bookmarks in Scrivener 3 thus provide a great way of accessing all sorts of reference material right in the Inspector.

(In Scrivener 3’s built-in novel project templates, which have “Characters” and “Locations” folders already set up, these folders are automatically added to the Project Bookmarks list for you.)

3 – That’s the Magic Number

It’s time to open Scrivener’s next chapter.

Scrivener 2.0 for macOS was released in November 2010, and Scrivener 1.0 for Windows in November 2011. Since then both have seen plenty of new features and refinements added in free updates, and more and more people have used Scrivener to write their books. But we’re not standing still: for a while now we’ve been beavering away on the next big release of Scrivener.

I’m talking, of course, about Scrivener 3—coming soon to a screen near you.

Featuring a refreshed UI and some major overhauls, our focus for Scrivener 3 has been not only on new features but also on consolidating and simplifying what’s already there. We’ve taken years of experience of writing in Scrivener, both our own and that of our users, and poured it into Scrivener 3. The result is the best version of Scrivener yet, and we can’t wait to get it into the hands of our users.

Soon, we’ll start posting a series of blog posts about what you can expect. For now, here’s what you need to know about the release.

Scrivener 3 for macOS

Along with the updated features and the revamped interface, Scrivener 3 on macOS has been rewritten as a 64-bit app and to take advantage of new Mac technologies under the hood. Scrivener is more than ten years old now, so for 3.0, whole swathes of code and UI elements have been recoded and rebuilt from the ground up to stand Scrivener in good stead for the next ten years. As a result, Scrivener 3 for macOS will require macOS 10.12 Sierra or above to run.

I’ve been working on Scrivener 3 for a long time, but it’s now in beta-testing and is nearly ready. We’re finalising the updated manual and preparing for release later this year.

Scrivener 3 for Windows

“Wait!” you cry, “Can you guys not count?” Well, we can, but, mavericks that we are, we are eschewing all sense of sequence and jumping straight from Scrivener 1 to Scrivener 3 on the Windows platform. Why? Because our daring duo of Windows programmers has been working very hard to attain parity with Scrivener 3 on macOS. It will look every bit as beautiful as the macOS version, has been reworked to better work with high resolutions, and will bring the feature set much more into line across the two platforms.

Scrivener 3 for Windows is still in development and will follow a few months behind the macOS release. As much as we’d love to release both versions at the same time, the only way we could do so would be by artificially holding back the macOS version for several months. The Windows team has always had to battle not only with the macOS version having a five year head-start, but also with having to write a lot more custom code because of platform differences. So Scrivener for Windows is catching up, but our Windows users still have a little longer to wait. Because we want to make sure it’s rock solid and everything our users have been dreaming of, for now all we can say is that Scrivener 3 for Windows will be released when it’s ready, most likely some time in 2018.

However! The good news is that the more intrepid among you don’t have to wait until 2018 to try Scrivener 3 for Windows. We’ll be releasing an early access beta of Scrivener 3 for Windows on the same day that Scrivener 3 for macOS is released for sale. Anybody who owns Scrivener 1 will be able to run the beta (although it will initially be a work in progress with missing features, which is why I say it’s for the more intrepid). The Windows beta will also allow cross-platform users to upgrade their Mac version and continue to work between platforms with the updated file format.

Scrivener 3 is a Paid Update

Scrivener 3 is the first paid update in over six years. This means that if you own Scrivener 1 or 2 and want to use Scrivener 3, you will need to pay an update fee. (We haven’t yet set the price, but it will be around the same as it was for going from 1.x to 2.0 on the Mac.) There will be free updates for those who bought within a limited time period prior to the release date (more news on that soon). Two notes on this:

  1. Windows users won’t need to pay the update fee until Scrivener 3 is released on Windows. Owners of Scrivener 1 will be able to use the Scrivener 3 betas for free until then, at which point the betas will stop working and you’ll need to pay for the upgrade.
  2. Mac users who bought through the Mac App Store will need to pay full price again simply because Apple allows for no way of providing upgrade pricing on the App Store. We’ll be happy to provide a discount on our own store for any Mac App Store users who email us with proof of purchase, but you won’t be able to get the update on the Mac App Store without paying full price. We wish it weren’t so, but we have no control over how the App Store works.

We hope you’ll find the update cost worth it. There’s some cool stuff a-coming.

Scrivener for iOS

Scrivener for iOS is already set up to work with Scrivener 3 when it’s released. And we’ll be continuing to update Scrivener for iOS, too, of course. At the moment I’m focusing on iOS 11 support and improvements, such as the new possibilities that Files app brings.


…has not been forgotten! Scrivener has taken a front seat for a long time, but once Scrivener 3 is out, we intend to spend some quality time with our Scapple code.

And Finally…

Over the next few weeks, we’ll start talking about what’s new in Scrivener 3 and what’s been changed. Until then, I’ll leave you with a couple of screenshots, one from macOS, one from Windows. We can’t wait to show you more.

Scrivener 3 for Mac Screenshot
Scrivener 3 for macOS


Scrivener 3 for Windows Screenshot
Scrivener 3 for Windows

Scrivener in App Store Best of 2016

Scrivener - Best of 2016

Many thanks to the lovely Apple folk at all the stores that have included Scrivener for iPad in their “Best of 2016” app picks. It’s been a great year (for Scrivener, I mean – clearly it’s not been a great year for celebrities), and being picked as one of the Best of 2016 is a spiffing way to end it.

My sincere thanks to everyone who has supported us this year and all the past years, by giving us nice reviews, telling your friends about Scrivener, or just, y’know, buying it and using it and creating books and scripts and games and words with it.

I suppose I could get all Matthew McConaughey Oscar-speech-emotional on you, but I think we all know that the best speech of gratitude ever given was that of Hightower when he graduated Police Academy:


Iconography in iOS (Or: Yes We Haz Custom Icons)

Scrivener can contain all sorts of different documents: whether you need to gather together notes, research, character sheets, to-do lists or, you know, some actual writing, Scrivener is a big bucket of everything for your writing project. With all those documents ready to hand, you might want to make some of them stand out a little, so that you can see them at a glance as you browse.

In the Mac and Windows versions, you can apply custom icons to your documents. And in this funky world where one of the biggest cheers at this year’s WWDC was for the announcement that emojis are getting three times bigger in Messages, I think it would be remiss of us not to provide some gratuitous graphical goodness in our iOS version. Which is to say: custom icons! In the iOS version! Three times bigger! (Disclaimer: not actually three times bigger.)

I love custom icons, because when my writing is terrible, I can at least make the document it’s in look purdy (I have a lot of pretty-looking documents). You, however, cool professional that you are, will no doubt use them as structural markers and navigational way-points. Which also works.

Scrivener for iOS: Exporting Single Files

A writing app wouldn’t be much use if you couldn’t get your work out of it. In an earlier blog post, we talked about Compile, which allows you to export or print your entire Draft folder (or a subfolder of it) as a single document, piecing together the fragments of your text into a complete manuscript.

Sometimes you’ll want to export (or print) individual documents from Scrivener, however. Fortunately, this couldn’t be simpler: just tap on the “share” button at the bottom of the editor, choose a file format, and off you go. You can choose to email the document to someone, print it, or open it in another app.

Scrivener allows you to export to PDF, Word (.docx), RTF, plain text or Final Draft (.fdx) formats, which means that you can easily share a document with someone on a PC, open a text document in Pages, or send a script document to Final Draft for some final touches.

Scrivener for iOS: Making Writing Easier on (Sm)All Devices

One of the challenges in bringing a complex, rich text app to iOS is how to provide quick access to a tonne of features on a small screen. Things aren’t so difficult on an iPad Pro, where there is lots of screen real estate, but on an iPhone, space is at a premium.

Another challenge is how to provide a frictionless writing experience with an on-screen keyboard. We’ve been able to add loads of keyboard shortcuts for those using external keyboards, and an external keyboard makes it much easier to navigate through text (using the arrow keys). But what if you don’t have an external keyboard handy?

These challenges have been met with the extended keyboard row: a row of eight buttons that sits across the top of the keyboard (which can be turned on or off). These buttons provide quick access to common commands.

Not just eight buttons: in fact, there are twenty-four, divided into three sets that you can swipe between. By default, there is one set containing common punctuation marks, another to make text selection and navigation easiser, and another for formatting commands such as bold, alignment, highlights and footnotes.

The keyboard row is fully customisable—long tap on any button to bring up a list of commands that are available. Tap one to replace the button you long-pressed with the command you selected.

Along with the extended keyboard row, Scrivener for iOS also supports smart punctuation, so you get curly quotes, ellipses for triple-periods, and em-dashes for double-hyphens automatically as you type (unless you turn smart punctuation off via Settings app).

Scrivener for iOS has a whole raft of cool features that will help you organise your work and refer to research—but at its centre we have worked hard to provide a beautiful writing experience.