Drafts 5.6

Last week, Drafts released version 5.6. While it is not as big as some of the other releases before it, it does bring some important enhancements to the app.

Adding Shortcuts

It is now easier than ever to add a specific shortcut to run in Drafts. A new interface is presented when adding a shortcut, as you can see by installing this example shortcut and selecting a shortcut to add. It prompts you for a few different items for running the shortcut, and is a better way of implementing them via the URL scheme. I feel that this method is a bit more user-friendly now that a shortcut has been written to quickly add them, and requires no formal coding knowledge.

Workspace Changes

Workspaces have been available since version 5.0 dropped back in April 2018. It is the single biggest improvement to Drafts, providing users with an infinite number of filtered views of the draft list. Extending it further, you can apply action groups and extended keyboards to a workspace and have what I coined as a module. In Drafts 5.2, the script and capability of automatically making this possible was implemented. In this new version, it is now more accessible to the non-scripting user.

Within the Workspaces menu, you can choose to load in action group or extended keyboard for each of the different workspaces you create. This does sync across devices, so for most users, this is a better way to load module with a single tap without having to know JavaScript. You can also now load a workspace to a specific tab, saving a few taps if needed. However, I personally won’t be using this as my setup involves loading workspaces differently based on the device type (as I laid out in my earlier Drafts piece).

Post and File Management Improvements

Drafts uses CloudKit to sync data to the cloud. There are more aspects of the drafts which are stored there, like location, tags, etc. which don’t tie in nicely to syncing to an iCloud Drive folder. You can, however, use different actions to save specific drafts to other services like iCloud Drive, Dropbox, Box, or OneDrive. Previously in Drafts, the idea of keeping things in the app was not always something you would want to do: you might want to save it to Apple Notes via a share action, or send it to one of a handful of other services as a plain text file or Markdown file.

For the most part, I keep all of my writing in Drafts. Over the past year, I have more in that module than I would like to admit. And I feel some stress of keeping all of these posts in the draft list. With the new features, I have several different ways of handling this. First, I could simply mark the drafts which I’m actively working on and load the writing module to the flagged tab; this is easy enough to do in the workspace settings, and would quickly satisfy the need. But the file management capabilities are something else that I wanted to explore.

What I ended up arriving at was this: I can keep one or two active drafts in the list, and save the rest to a specific folder in iCloud Drive. Once I’m ready to work on another one, I can run an action and be presented with a list of titles to choose from; the action would then load the contents of the draft into my draft list with a specific tag, and I can start writing on it again. This is all possible thanks to the FileManager script object methods.

I first borrowed from some of my previous scripts to ensure that I was saving things with the correct title. For the save action, I used a file action step, set the folder location to /Draft Posts/ and set the content as [[draft]]. Once this action is run, the draft is deleted from my draft list.

The next action was much more difficult to create. Within the updated objects, the ability to pull out the file names within a folder is now possible as a path location. Using a little bit of JavaScript, I was able to pull out the file name rather than the entire path: this allows me to present a more user-friendly display of the names. Once I have the selected name, I can load that file into Drafts, tag it with the writing tag which automatically places it into my Writing module, and I can start writing; I also use an "Include Action" step to load my Writing module to bring up everything I need with one tap.

The last action is needed for when I publish a post. I modified my existing standard and linked publishing actions – which I first introduced on MacStories for Drafts 5.4 – to save the file one last time to the /Post Drafts/ folder location, then move it to the /Posts/ folder where I keep my final posts as .md files. This happens at the end of the action after everything is posted.

One of the limitations of using the file management methods is that you cannot specify a folder outside of the Drafts folder.1 For some, this might be something that is a limitation. But because I work so much in Drafts, this isn’t an issue for me. Additionally, I can point other apps to that specified folder location – like Working Copy – to then upload files as I need for collaboration. Rather than keep all of these possible post ideas within my draft list and cause me more stress. And if you’re reading this, you know already how much I hate clutter…

I have also updated the HTML Preview step in my Post to WordPress actions above to include the new rendering options. With this update, Drafts allows the user to specify the rendering of text. Previously, only Markdown was supported in this fashion. But now, you can specify MultiMarkdown or Github–flavored Markdown, saving a bunch of script steps in the process. I updated WordPress actions with %%multimarkdown|text%% for the HTML preview, as well as improved the scripting to commit the Critic Markup changes to pass MultiMarkdown to WordPress, which you can find at the links above. And speaking of Critic Markup, a new highlight syntax color has been added. It provides a bit more visual difference when looking at all of your credit markup notations.

I’m really enjoying these updates. Even small point releases like this one are enhancing my custom writing tool, and I look forward to other ways it can be improved for the future.


  1. This is something that I hope improves with time by Apple allowing access to other parts of the system. 

A Little More on Critic Markup

After the release of Drafts 5.5, I’ve been using Critic Markup even more for the writing I’m doing.1 I hadn’t really used it before now, so leave it to Drafts to provide me some tools to improve the way in which I write.

In that post about the improvements in Drafts 5.5, I had shared updates to my actions for standard and linked posts. These have been super useful for me. But there are others out there that need to use plain Markdown for their posts. I had a follower pose this request on Twitter, and I decided it would be a small challenge to tackle and share.

Unlike my preview action for my site, I needed to keep the raw Markdown, rather than convert it to HTML. This isn’t something I can do natively using the script objects. So I needed a different way to make this all happen. I first needed to identify the Critic Markup elements:

{++add++}
{>>comment<<}
{--delete--}
{==highlight==}
{~~sub~>substitution~~}

Looking at what I needed to do, it was apparent that I needed to first remove the comment and delete elements completely, then keep the text within the add and highlight elements. The substitution element is a bit more tricky, where I need to delete the first word and keep the second word, while deleting the surround elements. With a little help of RegEx, I came up with the pattern:

\{>>.*<<\}|\{--.*--\}|\{==|==\}|\{\+\+|\+\+\}|\{~~.*~>|~~\}

The pipe characters are essentially the “or”, and the rest is to separate the elements. Combining this with elements of JavaScript and the Drafts Script Reference, I created an action to accept critic markup in a new draft, and preserve the existing draft. I did this to show the main RegEx, but it could be used in other ways: this could be a simple script to create a variable for posting; it could be used in conjunction with a step in Shortcuts; or it could even be used when saving out copies of long-form writing.

As the Drafts community and others create new actions that result in tools for writing, it helps to make Drafts more accessible and adaptable to each user. Writing in it may not be for everyone, but you should try it out to be sure. You might be delighted with what you find.


  1. Yes, it‘s been a while. Yes, I’ve been working on things here and there. More to come later.  ↩

Drafts 5.5 – The Markdown Update

The latest Drafts update brings some improvements with Markdown syntax. In addition to the standard Markdown (which has been simplified to represent the original Markdown specification), there are two additional syntax options: MultiMarkdown and GitHub Markdown. MultiMarkdown is a flavor which allows for footnotes, tables, citations, etc. GitHub Markdown is a different flavor of Markdown which supports extensions created by GitHub for rendering on their website, and includes the extensions for strike-through text and tables. I personally use MultiMarkdown, the format with which I’ve been most comfortable writing.

One thing that is included with MultiMarkdown as an option is Critic Markup. Looking through the guide, there are several helpful elements that can be used for editing my writing utilizing Critic Markup. I can highlight some substitutions, additions, and deletions. I can highlight text to show something I might want to work on later. I can also add a basic comment somewhere that won’t be shown in a preview. And with this action, I can easily add any of them with a tap and a text entry, which inserts it in the proper format. This is helpful for creating and previewing the documents in Drafts, and gives users the flexibility to mark up files and save them back to a cloud service. I can see myself using this a lot for longer posts or large reviews. I’ve even modified my own site preview action to render the MultiMarkdown via scripting, as well as updating both my standard and linked post WordPress publishing actions to do the same.

Critic Markup in Drafts vs my site post

There are additional Workspace options for sorting. You can now include flagged drafts in the archive tab – the same way it is done today with the inbox – as well as optionally sort the flagged drafts at the top. And of course, support for using these is also added to the script object. This allows you to give a bit of priority to Drafts in your inbox, depending on how you have your workspace configured. I liken it to something like Gmail: there’s a giant inbox of drafts, and you have a starred list that can be used to filter priority; you can also option to have the starred emails on top to bring them into focus, or have them in their separate list. This smart addition enables more focus on key drafts in your list.

There are some other small improvements and fixes; you can read the full list here. It may seem like a small update to some, but for the advanced users of Markdown, this is a fantastic update. What this should give users a glimpse of for the future of Drafts: custom syntax highlighting. Currently, the following syntaxes are supported: Markdown, MultiMarkdown, GitHub Markdown, JavaScript, and TaskPaper. Whereas I love the new Critic Markup portion of MultiMarkdown, I would love to be able to customize my own syntax. When I used Ulysses for writing, I really liked some of the comment, highlight, delete, and other markup styles. Part of what makes Drafts so versatile to each user is the myriad of ways which it can be customized. Controlling the editor in this fashion would, to me, make the editor the most powerful on iOS. No other editor would allow for syntax highlighting for writing and coding in the same way. I know this will at some point be on the horizon, but that cannot come soon enough. I’ll patiently wait for it after the Drafts for Mac release.

Fantastically Good Parsers for Drafts

One of the small, but powerful for which I use Drafts is sending multiple events to my calendars. And for a long time, I’ve used the power of Drafts’ automation to send those events to my calendar via Fantastical.

That is until Peter Davison-Reiber created something amazing.

The great thing about using Fantastical for this purpose is the natural language parsing capabilities: I can simply type out a calendar event the way I need to type it, and it will populate it for me. But thanks to the incredible scripting capabilities in Drafts 5, it is possible to create the date and time parsing aspects – the part where Fantastical excels – and put that right into an action in Drafts.

The end result is as advertised – fantastically good. Not only does it replicate the way I input events into my calendar, but it does it even faster now that it’s all native in Drafts. There is no longer a back-and-forth dance with the action to create multiple events. It runs quickly, and I can move along with what I was working on when it is completed. I can also include locations and durations as well. I can even use the calendar shortcut syntax (example: /w for my work calendar) with the action. It is a really robust solution.1

And if that wasn’t enough, Peter requested the changed in Drafts 5.3 which provide the same parsing for reminders as well, which replaces the other aspect of Fantastical for me. You can include the level of priority denoted by exclamation marks ! and use the reminder list denoted by the same shortcut syntax as the calendar (/inbox).

These two actions are what I had envisioned in the GTD module of my review. This is a case where I knew that they were going to be possible, but I do not have the technical knowledge to create. Initially, I wanted to create one based on some unique syntax, similar to the Send to Things action. But what Peter has done here exceeded my expectations and is fantastically awesome.

Cheers Peter!


  1. There is a limitation of creating recurring events via the API. This may come in the future.