Request for AppleScript

Now that Drafts (19) has begun to support AppleScript I would like to request a specific capability that would allow my macOS app to support Drafts. This is support for 3rd party apps to run AppleScript against Drafts (not internal actions…)

Here’s the pseudo code of what I could use:
tell application “Drafts” to return the permalink of the current draft

This is based on examining the .sdef that was included in the Drafts update.
permalink (text, r/o) : The URL of the draft.

Thanks for Drafts!!

1 Like

It is planned, but this release is just a first step.



This morning I woke up with one the weirdest solution for a long time to a peculiar problem and found out:

”The solution was embedded in the error!” :crazy_face: Nevertheless, I would appreciate if there are better alternatives.

I’ve had a very efficient solution for years utilizing Alfred:

  • Doubletap-⌘ creates a new Draft prefilled with the fundamental questions (from Kipling but in the following order): When, Where, How, Who, Why and What.

Now, when Drafts has started to support AppleScript and CSS templates I thought I would like to extend that solution utilizing Location Helper (since this precedes the Draft but a template and an action could be another option) and other adaptations of a Markdown content with some footnotes and so on.

This AppleScript gives me the new Draft with Markdown in memo and a tag:

set myDraft to make new draft with properties {content:memo, tags:“memo”}

However, that Draft was not then opened for direct access and it seemed impossible to get various properties from myDraft, s.a. permalink, UUID and more. Then I suddenly realized the information was in the error string itself! So I simply wrapped my attempt in a try structure with on error str and then extracted the UUID:

set myID to characters 2 thru -3 of ( last text item of str)
set AppleScript’s text item delimiters to “”
set myID to myID as text

Then it was straightforward to open that Draft:

open location “drafts5://x-callback-url/open?uuid=” & myID

This works like charm but is not so esthetically pleasing as e.g.

set myID to permalink of myDraft

Am I missing some specific syntax that actually should work in the more usual way?

(Until then this may be a tip for other people having the same problem.)

Of course, this is even simpler but a little more direct (recognizing that UUID is delimited by double quotes).

set AppleScript’s text item delimiters to quote
set myID to (text item 2 of str)
open location “drafts5://x-callback-url/open?uuid=” & myID

Also, after that the way is wide open to “Open in New Window” and set to “Float on top” as I usually are working on other thing when these more or less sudden interruptions occur but Drafts lets me stay on top—literally.

Take a closer look at the URL scheme options. Particularly the one for creating drafts. There are options to set for content and tags.

For example, what happens if you trigger the opening of this URL?


Also, don’t forget you can trigger a native Drafts action via the URL scheme which opens up a lot of options for you until the AppleScript support gets to the point where external automation is broader.

1 Like

Thanks, yes that was in fact my old solution and is still an option.

The reason I started to experiment with AppleScript was that I had to compile a lot of Markdown information (extracted from other AppleScript) and just tried to avoid to URL encode everything which I haven’t been very successful doing but from your advice I also tried this solution which works nicely!

set memo to do shell script ("/usr/local/bin/jq -s -R -r @uri <<< ‘" & memo & "’") – URL encoding
set newDraft to “drafts5://create?text=” & memo & “&tag=memo”
open location newDraft

It seem to me a combination of the Drafts URL scheme and AppleScript can give me anything I have wanted so far. At least I now know how I can get the UUID for a created draft from AppleScript even though that is probably not the recommended method which can be changed later when more support is available.

On problem now is that Drafts crashes from time to time and the solution is somewhat shaky especially when returning to Drafts after the new draft was created. “Most of the time” it seems to work though.

Therefore, I will also look into a native Drafts action via the URL scheme later which I also had in mind previously.

If you are having stability problems, that would be worth a support e-mail. If you can reliably reproduce your issue with an example, Greg always appreciates having the details to examine.

If encoding is your main sticking point, and if you are using files, put the files in the Drafts import inbox directory. If you have consistent tags, that would be an easy choice to standardise while you import. You can also drag and drop files in, and then you would just need to set the tags afterwards.

If you are not working with files, you could dump your content to the clipboard and have the URL scheme call an action that creates a new draft from the current clipboard, parsing out any tags from say the first line - allowing you to deal with multiple different tags, or you could have the tags passed as parameters to the action in the URL scheme.

Thanks for that tip, too. It might be an option even though the encoding works fine now.

One of the shortest sequences that seems to cause a crash is the following:

  1. Create new draft with the URL scheme (from my Alfred workflow, AppleScript, triggered by doubletap-⌘).
  2. ⌘W to close the newly created draft (which is now a separate floating window) or ⌘S and then closing the floating window.
  3. Trying to click drafts in the navigation bar.

Crashes ~3 out of 4 times.

However, I’m about to change computer (with Catalina) very soon so will not delve into this too much.

Any progress on AppleScript support?

From the dictionary it would seem drafts can be referenced in the app, but I only get an empty list when I try.

If this is actually possible I’d appreciate a working example.

Scriptability is crucial for me to be able to consider using any text/programming editor.

I’ve used BBEdit nearly every day since 1992, and its combination of AppleScript and shell script support is crucial to my workflow.

  • Referencing and working with any note in the structure.
  • Creating new notes (currently supported).
  • Deleting notes.
  • Getting/Setting the entire contents of a given note.
  • Working with the selected text.

That’s about the bare minimum.

A Mac without adequate automation is about as useful as a balsa wood boat anchor…

I bought a subscription for Drafts some time ago, because it’s quite useful on the iPhone and iPad. But I only recently got a Mac that can run Mojave, so I’m new to the Mac app.

Hopefully I’ll join the M1 crowd on rev-2, and Drafts will get enhance AppleScript support.

Christopher Stone

1 Like

The current support for AppleScript is listed in the docs and the beta currently has no additions to this.

In terms of automation, Action (including JavaScript and the object model for Drafts) x-callback-url, and the running of shell scripts is all included. Of the Mac, there’s also Shortcuts support.

I would also love to see some additional AppleScript support to enable some of the automation /integration things I would like to do on the Mac, but in regards to a bare minimum of automation, I think it more than covers that already.

You can use a URL scheme to run an action and actions are almost limitless in the ways they can query and interact with the app and its content. There are cases where it isn’t quite enough, and of course cases where stronger AppleScript support could make things easier.

Until AppleScript support is increased (Greg has noted that it is on the roadmap) if you have a particular automation in mind, perhaps it can be achieved via existing means, and I’m sure folks here on the forum could help with that.

Hey Stephen,

Thank you for the tips.

I’ll start digging.

The last reference I saw to this was as of April 3, 2020.

I hope to see some progress on this sometime soon.


I’m not sure @agiletortoise has a roadmap…

… It would be cruel to observe that, for example, syntax colouring has been trailed.

Cruel and hypocritical… :slight_smile:

Seriously, I see lots of progress - and much of it driven by what people are doing with both Drafts and other note taking apps. Which is exactly what I want Greg to keep doing.

1 Like

Sometimes the big features don’t move as quickly as one might like when your platform vendor keep throwing new OSes at you. :wink: