iOS Writing Apps — The New Wave

Prompted in part by Jason Snell’s article, “My iOS writing app of the moment is Editorial”:

Though people have raved to me about Bear, I don’t think it’s for me. I can configure it to be a usable text editor, but it really wants me to use its internal tagging and linking system, and that’s not how I want to work. It doesn’t sync with Dropbox and makes some styling choices (like hiding the content of Markdown links) that I don’t really appreciate. In short, Bear looks like a thoughtful notebook-style writing app, but it doesn’t really fit with how I work today.

And in part by “Bare-Metal Writing: What Our Word Processors Are Missing”:

I’m writing these opening lines in Markdown, using a Mac app called Focused, one of many attempts to rethink the word processor as a minimalist exercise. Every one of my articles starts out in this app (or at least in John Gruber’s neglected gift to the world), and yet, I always find myself looking for another option, periodically launching into a Google deep dive that rarely leads to a better solution. I always feel like my words deserve a better vessel, something that will allow me to write them faster, more efficiently, and with as little friction as possible.

(Full disclosure, one of the links in that Tedium article points to my post, “Standard” Markdown Controversy on this blog, which is how I found it.)

Text editing apps have been a very popular category of the iOS App Store from the beginning, but there has been a recent second wave of note-taking and writing apps that support Markdown.1 While past iOS apps could sync files, most of them didn’t have OS X / macOS versions, leaving that to built-in tools like TextEdit or third-party text editors like BBEdit or TextMate. These new-wave editors have macOS counterparts that integrate coss-platform.

While I have been happy with Editorial , it has been a while since it was updated, and so I re-evaluated my options when new versions of Bear and Ulysses came out recently.

These are both excellent apps, but I have not adopted either of them for writing on macOS or iOS. My preferred apps for writing on iOS are still Drafts and Editorial. I use mostly nvALT, with BBEdit for some tasks, and have Marked 2 as my preferred previewer/converter on macOS.

Obstacles to Switching

The main problem with switching to one of these apps is that my writing process is antithetical in one way or another to how Ulysses or Bear want me to work.

I think one of the main reasons that many developers are now expanding their offerings to Mac apps for cross-platform integration is because of Apple’s improvements to iCloud sync. With iCloud sync, app developers don’t have to depend on the cooperation or existence of a third party solution like Dropbox.

Apple’s expansion of the types of apps that can charge subscription fees is the other change driving cross-platform development. Sync has become valuable because it’s viable, and since it’s valuable, it can be a source of revenue.

This is both a strength and a weakness. I don’t mind paying for good apps, and I understand why going with a platform-native API is preferable in many cases. The problem from the user side is that iCloud is not a replacement for Dropbox.

In iCloud, each app gets its own file bucket and no other app can normally access it. With the changes introduced in the iOS 11 Files app, you can access text documents, but you can’t edit them in-place; you must send a copy to another app. That means that the ease of using different writing tools for different tasks on the same file is just not possible the way iCloud currently works.

I don’t want to import my files into an app, because then I have to keep track of two versions of files, or fully commit to having the canonical version in a proprietary format or location. I don’t want to have to export for the same reasons.

I don’t want to use a special syntax that works only in that app, because then I lose the fluidity of changing apps whenever the task or the situation dictates. It also means that if I want to switch apps, I have elements that I may need to revise or migrate in the future, which is one of the problems that writing in plain text was meant to avoid.

Dropbox Is My Everything Box

I use a folder (very originally named Notes) in Dropbox as my Everything Box. I might create a note in an iOS app — usually Drafts — but my notes sometimes begin as highlights and comments on an article saved in Instapaper through Instapaper notes, or the file could begin life as margin notes on Kindle. On the Mac side I work primarily in nvALT, but I could just as easily start directly in BBEdit or TextEdit and simply save that file to my Notes folder in Dropbox.

The important thing is that everything can read and write to the same place, and that place is Dropbox.

When I first started keeping the majority of my notes in digital form rather than using paper, I used Simplenote because it was fast and its sync system was simple and reliable compared to the built-in Notes app on iOS. When I started working on my note files directly, syncing across iOS and macOS, Dropbox integration wasn’t a given, and Notational Velocity had Simplenote sync built-in. Later, when I’d built up a large enough library, the sync started to run into problems.2 I had already been paying for “premium” and switched to the alternative Dropbox sync which was offered for Simplenote subscribers.

Dropbox sync opened the door to using anything I wanted at any time to work on those files. Evaluating a new note-taking or writing app was as simple as pointing that app at my Notes folder and going to work. It was thanks to the ubiquity and ease of use of Dropbox sync that I tried out Notesy 3 and Byword, experimented with Drafts, and eventually adopted Editorial as my main writing tool on iOS when Notesy development stalled.

Bear and Ulysses

I tried out Bear and even paid for a year up front because I liked it, a lot. It’s beautiful, well-designed, and easy to use, but I soon found that I can’t get over the friction of using its iCloud sync system. I use different tools for different jobs, and I may use 4 or 5 apps to interact with the files depending on what I’m doing with them at the time.



  • It’s pretty, it’s well designed and well thought out.

  • It’s theme-able and comes with a particularly nice theme that is unlocked with the very reasonable annual sync fee.

Panic theme in Bear

Panic theme in Bear

  • It’s relatively powerful already for a new app, despite its surface simplicity. The developer is already promising some changes and improvements in the first couple of updates. There is support for x-callback URLs, with many common actions available, as well as some uncommon ones.

  • I liked it enough on trying it out to go ahead and pay for a year of sync (¥1,600) up-front when I could have just gone the cheap route of a monthly plan, just because I want to encourage Shiny Frog to keep developing it.


  • No Dropbox sync. You can import everything from Dropbox, and then it syncs with Bear on iPhone, iPad, or Mac automatically through iCloud, with no need for signing in, exchanging tokens, etc. But once it’s in, you have to export to get it out again. It’s a one-way process; no editing files in-place with different apps from then on.

  • Bear hides links, as does Ulysses. I prefer Bear’s implementation for editing links because it provides a better tap target and the popover is faster and less intrusive than the whole-screen slide-down Ulysses uses, but I still can’t just glance at a link to see if it goes to an appropriate URL.

  • There’s no footnote support yet. I use footnotes a lot.4



  • I remember trying a version of this (Ulysses 1.5, I think) on OS X before the iOS App Store existed, back when Open Office was a thing. Because it’s not a new program and has been hammered on by users over the years, most use cases have been tested pretty thoroughly. The new version is a substantial re-write and presumably incorporates what they’ve learned.

  • It’s extensible. There are styles and highlighting themes and ways to import fonts5 for use on iOS, as well as other customizations.

  • It’s powerful. You can define your own markup, publish to various platforms right from the app, organize files, and add non-text elements. There are many x-callback URL actions, and it has an extensive set of keyboard shortcuts for iOS.


  • Dropbox support feels like it’s only grudgingly supported. Sync with Dropbox is slow and buggy on iOS. I tried using Ulysses for several non-work writing projects during the 14 day trial period. It sometimes took over 10 minutes for sync changes to propagate to the actual files on Dropbox. This doesn’t take more than a few seconds with any other Dropbox-synced app.

  • It’s slow to start. Editorial takes about 3 seconds to load, and usually the full list of files from Dropbox loads in about the same time — depending on available bandwidth and the number of files that have changed. Search on Editorial is also very quick. Ulysses takes about 8 seconds to load on my iPad, and the list of files pops in over literally minutes. nvALT is lightning-fast compared to Ulysses on macOS.

  • Even after I set it aside to give it time to completely sync all files after authorizing Dropbox access, Ulysses still seems to want to load everything from scratch and becomes extremely unresponsive for several seconds every time I open it.

  • I don’t like some of the additions to the syntax. For example, comments could use Critic Markup syntax or even HTML. Instead, Ulysses used their own markup. Critic Markup is useful across applications, and HTML comment syntax will be hidden on export by default without any application-specific processing needed. Ulysses comment syntax 6 shows up as regular text unless you process the file with Ulysses’ export. So, to make your files Markdown-processor agnostic, you can’t use that syntax, nor several other app-specific additions.

  • I don’t like the hidden links or the interface for editing links. It’s slow and wasteful of interface space. Double-tap. Wait for animation. Edit. Tap to exit. Sigh in frustration as you have to do it again for the next link. I want to be able to determine the link URL at a glance and edit everything directly. That’s one of the reasons I started writing Markdown in the first place; transparency.

In the course of evaluating Ulysses (including using it for early drafts of this piece) I also found something that is truly a deal-breaker: Ulysses automatically moves references to the end of the file and then numbers them in the order they occur. It does the same with footnotes.

Don’t do that. I deliberately name my references in ways that make sense and convey meaning to me. If I don’t include an inline link, I put any references directly after the paragraph while writing a draft. In the course of writing I’ll often insert the Markdown bracket syntax for a link without bothering to actually find a URL at that time. That’s a signal to future-me that I need to find that information, but doesn’t interrupt my writing flow at the time.

In editing read-throughs or my final proofreading pass I’ll fill in the targets for those links. Just before publishing, I will often use one of Brett Terpstra’s Markdown Service Tools to move inline links to reference links at the end of the file, but while I am writing I want the reference to appear in context.

When Ulysses changes those reference links from something like [Ulysses][Ulysses iOS] to a number, based on the order that item occurred in the text, it destroys information and disrupts context. In the example above, the reference text tells me that I need to find a link for the iOS version of the Ulysses app, not the macOS version. This is much easier to understand than [Ulysses][5].

When I encountered this behavior and didn’t find a way to turn it off, this automatic switching of link style and reference re-naming got Ulysses summarily kicked to the curb, despite some other appealing features.

Editorial’s Shortcomings

While it is powerful and customizable, Editorial is not perfect. My wishlist for a new version includes:

  • Settings sync, so that iPad and iPhone versions have the same workflow tools and shortcuts in place, and changes to one propagate to the other.

  • Adoption of the TextBundle spec to simplify the inclusion of images.7

  • More regular updates, including better support for external keyboards — like arrow key navigation of file lists — and iOS 11 improvements.

I can see the appeal of both Bear and Ulysses. They include interesting features that, if I were starting out fresh, without established preferences or workflows, might be enough to give up the flexibility of Markdown-agnostic syntax or Dropbox’s universal access and edit-in-place capability. However, Editorial is still the iOS app I prefer to use for most long-form writing.

Given the amount of use I’ve gotten out of this app over the last few years, along with its stability and robustness, I’m more than willing to throw money at Ole Zorn if he came out with a new version. Even if my wishlist items weren’t included right away, I’d have hope that some similar feature was coming in the future, and honestly at this point I almost feel indebted for the time I’ve used Editorial without paying anything more than the very reasonable purchase price (¥600, about $5).

  1. Well, some flavor of Markdown. Both Ulysses’ Markdown XL (go to the Editor section of the FAQ) and Bear’s Polar Bear add elements to standard Markdown. You can elect to ignore their additions to the syntax, however, as both properly support Gruber’s original Markdown spec.  ↩

  2. Detailed here in a post from a few years ago about my writing workflow. As of this writing, I have over 1,700 notes in that folder, compared to the 500–800 I had when I first started having problems with Simplenote’s sync system.  ↩

  3. Notesy is now, unfortunately, completely defunct. The old website, is no longer in service.  ↩

  4. Even though this meta-footnote was the second footnote in an early draft, I’m dead certain it will not be the second in that order by the time I publish, nor will it be the last footnote. Edit: Oh, look, there are 3 4 5 6 7 footnotes now.  ↩

  5. Look in the FAQ under iOS Editor → How do I add fonts to the app?  ↩

  6. Since I don’t have Ulysses installed anymore, finding a useful reference for the comment syntax was unexpectedly difficult. Apparently, there’s no comprehensive Markdown XL reference guide outside the Ulysses app itself. You have to dig through the FAQs or the blog posts to find references.  ↩

  7. Including inline images in Editorial is possible using standard Markdown syntax. Gabe Weatherhead wrote a post about the iOS tools he uses to make “rich plain text notes” with Workflow and Editorial’s macro tools.  ↩

Neuromancer…Still the Best Science Fiction Novel Ever Written


Gibson even at his worst — which is still better than the best of many other writers — creates startlingly lucid images with lyrical prose. In interviews he has said that he knew the tech would be horribly dated in very short order. What keeps snagging new readers, and keeps old ones coming back over and over, is his use of language.

Structure Does Not Trump Content

The author of an extensive post, titled Star Wars Ring Theory: The Hidden Artistry of the Prequels, Mike Klimo, was featured on Unjustly Maligned not too long ago. He makes a strong case for a previously unnoticed complicated interlocking narrative structure for the 6 Star Wars movies. Lucas’ own words in past interviews and Star Wars supplementary materials support the theory also.

But, using such a framework doesn’t absolve Lucas from the multiple technical, storytelling, characterization, and dialog failures in the prequels, as discussed in the RedLetterMedia video reviews, which are directly referenced by Klimo. (If you haven’t seen these yet, you really should. The only weak points are the bizarre “real life” insertions of the Plinkett character, and even those are entertaining in their twisted way.)

If you were to show all of the Star Wars movies to someone who had no prior knowledge of them, any of the original three would be judged as being superior movies to the prequels in nearly any metric you’d care to define. The Empire Strikes Back is obviously the standout even among that group. It seems that Lucas benefitted both from the strictures of studio production and the stronger influence of the directors of the earlier movies. Without those balancing forces, his vision ran unchecked.

Poetry forms like sonnets are a similar confining structure for writing, albeit on a much smaller scale than classical chiasmus which is meant to provide links between entire passages or scenes in a large narrative. For every gem by a Shakespeare or Keats, there are hundreds of thousands of sonnets by poets who dutifully followed the demands of the form, but which are utter failures as poems, however well they conform to the structure of a sonnet.

Literary structures are best used as scaffolding to aid creativity. There are few things more terrifying or paralyzing to a creative person than an utterly blank space with no limitations. By confining yourself to a particular form, or material, or subject, you can spark ideas that may never coalesce without some limiting factor. One of the most famous quotations of Michelangelo, “I saw the angel in the marble and carved until I set him free,” reflects how in working around the limitations of his tools and the flaws in a natural material like marble, an artist has to see the possibilities. Without some limits to force the artist to use ingenuity, banality might be the rule and genius the exception.

Competently done, the parallels and echoes in the Prequels would have been evocative and thrilling. Instead they felt ham-handed, trite, and formulaic. Episodes 1–3 are occasionally beautiful-looking films, but the visuals don’t make up for the lacks. Even worse, while at the time the CGI was cutting-edge, it often doesn’t hold up as well as the seat-of-their-pants practical effects that Lucas’ fledgling studio were essentially forced to create a generation earlier in order to get the original Star Wars movie made.

The first Star Wars movies were an alchemic blend of Lucas’ ideas and the talents of the directors and artists who worked on them. Lucas on his own couldn’t recreate that magic resulting from synergy, and his predominance as the director, producer, and financier gave him essentially unchecked power in making the prequels, resulting in an intricately-crafted structure reflecting both Lucas’ obsessions and his weaknesses as a movie maker. His arguable genius in structuring his masterpiece as a classical ring composition apparently could not also encompass effective characterization, dialog, plotting, or pacing.

RIP Terry Pratchett

“Don't think of it as dying, just think of it as leaving early to avoid the rush.”

Condolences can be left on his Facebook page.

I didn’t get into Pratchett when everyone else did in the 90s. I’d already grown out of humorous fantasy like the Xanth novels in my early teens and wrongly assumed that Discworld was roughly the same. Pratchett is a much, much (much!) better writer than Anthony, and practically requires annotations or an extensive yet wide-ranging education and acute attention to possible allusion to fully appreciate. A decade later, I finally read Pyramids and later Small Gods. The latter has proven to be a reliable gateway drug to of the other Discworld books for many of my friends and acquaintances.

Something I didn’t appreciate until fairly recently is that writing humorous fiction — particularly fantasy — is bloody hard. It’s far too easy to slip into parody, and consistently writing things that are both clever and funny for most people is very difficult to do. You can count on the fingers of one hand the people who managed the feat at all[1]. Pratchett managed to do it for 40-plus novels in the Discworld setting alone, which makes him frankly amazing and deserving of every penny he earned from it.

“I realized I was rich,” he recounted, “when I got a call from my agent one Thursday. That cheque I mailed you—did you get it? He asked. And I realized I couldn’t find it: lost down the back of the sofa or something. Can you cancel it and mail me a new one? I said. And he said, yes I can do that, but you realize you won’t be able to deposit it before next week and you’ll lose the interest on it? And I said sure, just go ahead, cancel it, and send me a new one. Then I put the phone down and realized it was for half a million pounds.” — anecdote recounted by fellow author Charles Stross

He will be remembered for decades as that be-hatted fellow who wrote all those wonderfully many-layered books about a cosmologially (and temporally) improbable nexus to humor. I sincerely doubt that in my lifetime any other author will even come close enough to be compared to him. Take good care of him, Death.

  1. In my opinion at least: L. Sprague de Camp was clever, but rarely laugh-out-loud funny. Fritz Leiber, ditto. Piers Anthony was always more punny than funny, best appreciated before age 14, and the sexual subtext of nearly all of his work is more than vaguely creepy once you get old enough to start recognizing it. Robert Asprin’s output was inconsistent, and I strongly suspect that Jody Lynn Nye was heavily involved in everything he wrote after Myth-Nomers and Im-Pervections, whether credited or not.  ↩

A Long Goodbye to File Systems

In response to Matt Gemmell’s “A farewell to the filesystem”

These days, I expect the machine to accept my query, and throw the relevant set of my stuff back at me. Browsing through directory windows seems anachronistic now, and - interestingly - it also feels artificial.

I wouldn’t have said that a few years ago. The file system was the only reality, and everything else was a fancy search interface, slicing and dicing my data from moment to moment with algorithmic sleight of hand.

While I share some of the same feelings, my experience is slightly different from Gemmell’s. Shortly after Spotlight came out in OS X Tiger, I quit using nested folders and instead started using Spotlight comments and its ability to look into the contents of files to find what I was looking for.

I wrote back in 2009:

As we accumulate more and more information on our computer systems, effective interfaces become even more necessary. Way back in the early days of the Internet, I realized that search was going to be a massive problem. And it was. The reason Google is now well on the way to becoming a tech behemoth is because sorting through the incredible amount of information on the Internet to find the few bits you’re looking for is the single most difficult and important task everyone needs to have done.

Our home systems will obviously never become as large as a worldwide network, but most users already are coming up against the limits of their capability or inclination to organize the information they do have. I reached my limit with self-organization years ago, which is why I had to find more effective ways of doing things. Creating better, more intuitive and effective tools for search and organization will continue to be a very important task for software engineers for a long time to come.

I tried out different launchers over the years, starting with Quicksilver, but nothing stuck particularly well. While all launchers allow you to do far more than just find files, most of the time that’s all I need to do: find it, open it, work on it. The vast majority of the other manipulations that utilities like Quicksilver, LaunchBar, and Alfred enable you to do are complicated overkill for me. I found that I spent far more time fiddling with learning how the tool worked than I did actually using it, and after a few days often forgot it was even installed and running.

I was a late convert to Hazel, but now I use it for creating a modicum of file hierarchies. In the rare case I can’t find something through Spotlight, I can fall back on looking for one of the shallowly-nested folders that I set up Hazel to automatically create and use as a sorting destination for various types of files and topics. Before system-level tagging was introduced in Mavericks, I started experimenting with OpenMeta tags, and tags within the files themselves in some cases. I detailed how I use these tools in writing and organization more extensively last year.

The thing both Gemmell and I agree on is that the traditional hierarchical file system is disappearing, and few users will miss it. While it may still be functioning behind the scenes, it will be at best a backup for search and other less linear systems.

New Year's Resolutions

I don’t make New Year’s resolutions. If I’m going to make a change, I do it right then. Why put it off until next year when you can Do it Now? Aside from falling back into bad habits [1], procrastination and basic laziness short-circuit most people’s attempts to establish new patterns.

It may take longer than you think to establish a new habit — depending on the behavior you’re trying to change — but that’s no reason to hold off on doing it until a particular date. Instead, you should start immediately.

Whatever you do, do it. Keep doing it. Make the changes in your life that you want to make. You can’t control the outside world, but you can change how you interact with it. So do it.

  1. For those who are aural learners, here’s the You Are Not So Smart podcast on extinction bursts.  ↩


Serendipity is virtually absent in online discovery. We have an unprecedented level of access to information, but because of the sheer volume of it, discovery relies on search algorithms, or directed browsing — which is really just algorithms with a false-front. With Facebook and Twitter, your peer groups serve as a filter and serve up information that is (sometimes) suited to your interests…but only if you’ve picked the right friends.

One interesting experience back in the dark ages of the 80s and 90s used to be going to a local video store, which usually had an idiosyncratic stock of videos since they were mostly privately owned, not chain stores. Before the Blockbuster model of super-stocking the latest releases while having a very limited back catalog took hold, you could have the experience of browsing the aisles and finding something odd slotted there among more mainstream movies. And you just might take a chance and rent it, and be delighted, or disgusted, or have your mind blown.

For all the talk that Amazon suggestions are bizarre, those suggestions are the result of some correlation between the things that you searched for and things that other people have bought in the past. (It’s probably also cross-referenced with things Amazon would really like to get rid of.) If you’re buying straight-razors and Amazon is giving you suggestions for monster-sized dildos, you might think that it’s pure randomness, but it’s not. Frighteningly enough, there’s some past real-life correlation that the system is using to serve up that recommendation.

What I’d really like online is more randomness. While I do want a search to return a precise focused list of results, while browsing I’d often like to have a more organically semi-organized experience.

For instance, in used book stores, I would often find interesting books by authors I’d never heard of — by authors that sometimes no one I knew had ever heard of — simply because I’d pick up a random book with an interesting cover or intriguing title while walking through the stacks. Serendipity is finding something you immediately love that you never knew existed before then.

Recommendations from people I know rarely convince me to buy a book because my tastes are very different from most other people’s, even if we have read a handful of similar books. But I’ve bought probably hundreds of random finds at a book store.

I most often choose based on both a quick flip-and-read-through of a couple pages at the beginning, and at some spot in the middle of the book, in order to get the flavor of the writing. Because of that, I still find it hard to buy anything by an unknown author online because Amazon’s “Look Inside” feature usually has only the first couple of pages. Beginnings are easier to get right. Sustaining interesting writing even in the middle of a random passage buried in the middle of the book is much harder. I find that I fall into a rut much more easily now, where I buy more things by the same small set of “safe” authors that I know I’ll like because I don’t have a broader more varied mix of things to browse through and choose from.

Randomness doesn’t just help you find books or movies or other entertainment, it helps you solve problems. I’ve taken trips to hardware or hobby stores to find specific materials for some project, only to change my plans because I found a part that would work better than my original conception. That kind of happenstance is much harder to experience online. Most of the time, you either find exactly what you want, or you don’t find anything at all.

The Quest to Automate my Workout Log

I recently spent more time than I really want to think about to change one tiny thing about my workout log workflow. I would have given up long before, but I’m stubborn, not being able to solve a problem — especially one I think I should be able to solve — tends to make me fixate on it, and I thought that what I learned would pay dividends in the long run.

You need a few apps to copy this specific workflow. However, I think it can serve as a more general example of how to chain multiple apps together.

First, you need at least Drafts 3 (apparently, this version is no longer available, but I’ve kept the link intact anyway). This is the linch-pin of the whole series of actions. The newly-released Drafts 4 will certainly work as well. Based on its predecessor, I insta-bought Drafts 4 when it came out, but haven’t fiddled with it much yet. Hell, as of this writing it’s still 50% off, so go buy it now!

Drafts is highly recommended for geek users — especially URL automators — but I would also recommend it as a very fast-launching and simple app for anyone who works with text a lot on their iPhones. I previously wrote about my writing workflow, which included a section on Drafts, or you could read about it on the developer’s website, Agile Tortoise.

You also need Dropbox; TextExpander (the new version now features a custom keyboard in iOS 8 so you can use your snippets in any app); Editorial (from the same guy who made Pythonista); Launch Center Pro; and Day One.

The main URL is called from Launch Center Pro, using its built-in support for automated URL encoding using double braces, i.e.: {{text to be encoded}}

drafts://x-callback-url/create?text=Notes/[textexpander:ldate]&action={{Copy to Clipboard}}&afterSuccess=Delete&x-success={{launch://x-callback-url/dropbox/clipboard?path={{[clipboard].txt}}&afterSuccess=Delete&x-success={{drafts://x-callback-url/create?text=[clipboard]&action={{Hashtag}}}}}}

Why do you need to encode parts of the action? If you don’t, then it won’t be interpreted properly. The action either won’t work at all, or will error-out at some point during the chain. I initially beat my head against the wall trying to get several layers of encoding to work, even going so far as to manually encode sections using online tools, but never got anything over 3 layers deep to work properly even though I swore it should work. This is part of why I had to call part of the process through a Drafts action, which I’ll detail later.

The TextExpander snippet ldate you see in in the first action expands into the date format I chose to use for my date tagging, ISO 8601 (see Randall Munroe’s brief argument for using it here). I use this date as the file name for my workout logs.

The above action:

  1. Creates a note in Drafts using TextExpander to generate the current date as essentially a variable in the action. Notes is the Dropbox directory where I keep all of my text notes. Then it …
  2. Copies that path to the clipboard, deletes the unnecessary draft, and throws it to Launch Center Pro, which,
  3. Appends a file extension, which is .txt in this case. (It caused me some frustration before I eventually found that some of my files, but not all, were in fact not plain text files, but had Markdown .md or MultiMarkdown .mmd extensions.) The action won’t work if you don’t specify an extension. I found out the hard way, through trial and error. Mostly the latter.
  4. This provides the path for Launch Center Pro’s built-in Dropbox action to get the text of a file previously saved in Dropbox.
  5. The contents of the retrieved file are fed back to Drafts as a new document.
  6. After Drafts gets this text, it runs the Hashtag action to continue the chain and again deletes the unneeded draft.

The Hashtag action in Drafts 3 was one I created to implement this chain. You can create your own URL actions by going into Settings → Custom Actions → URL Actions. You can create actions entirely in Drafts itself, which is no surprise considering that the spec for x-callback-url originated with Greg Pierce of Agile Tortoise.

(Shout out to Alex Guyot at The Axx for his Drafts URL creation snippets, which make typing this kind of stuff in iOS much easier, and which provided me with a helpful framework for the initial version of the URL. Also, his Drafts 3.0 Stress Test gave me some hints I needed to get the rest of the action working when it looked like I was insolvably roadblocked.)

The Hashtag action code is:


You can see that this action sends the text of the file we grabbed with Launch Center Pro to Editorial, which also runs an action I (unoriginally) named Hashtag. What does this do? After some abortive attempts to learn how to pipe things through Pythonista using the replace command, and being stymied by not knowing enough to get the output anywhere useful, I experimented with Editorial’s built-in find/replace tool. You can save really elaborate workflows, but all I needed was that simple character change from @ to #, so that’s what I used.

(I now know that I probably could have done this whole process in Editorial, without doing all this app jumping, but Editorial was literally the last app I installed in all this tinkering around, and giving up without making the x-callback-url work would have felt like defeat.)

Once Editorial does a search-and-replace, the output is fed back to Drafts, which sends it to Day One as a post, and deletes the superfluous draft.

Without the deletion actions, you’d end up with several drafts in your Drafts archive, unless your default is to delete a draft upon use. My default is to archive and occasionally purge, since sometimes I want to perform another action on the same draft, and in case something doesn’t work properly I don’t want to have to retype my note if I can just archive it.

The action does require interaction part of the way through. I actually don’t know for sure if it’s one of the apps involved (at a guess, probably Launch Center Pro), or a system dialog, but I do have to tap Allow to let part of the URL callback proceed. There is another minor interaction as Day One sees the hashtag and asks if I want to add it as a native tag. Of course I tap, “Yes” because that was the point of this overly-elaborate exercise.

So there you have it, a Rube Goldberg machine that jumps between 4 different iOS apps, and uses the capabilities of a 5th, all just so that I don’t have to copy and paste manually, position a cursor, and hit a delete key. Is It Worth the Time? Maybe.

By my earlier calculus, I’ve probably wasted several thousand yen of effort on this problem if you only consider the time saved. But, I also learned a lot about URL schemes and iOS automation, which I have already leveraged to create other time-and-effort saving actions. Plus, success! Nothing feels quite like solving a problem that had previously defeated you.

Markdown Classic

Something else that came up in Twitter comments, that I didn’t address in my follow-up post about Markdown, was the question of tone in exchanges between Gruber and Atwood. Frankly, neither side comes out looking like they took the high road to my eyes, but Atwood’s supporters seem not to see his inherent disrespectful attitude toward Gruber, going back years. While Gruber can definitely be abrasive, in this case it appears to be a reaction to being pushed, not inherent jerkitude.

I’m glad to see that at least a few other people see it too, and that I’m not just imagining Atwood’s petulance.

Gabe Weatherhead at his blog, Macdrifter also weighed in on the new flavor of Markdown days before I did. I just read his piece today.

A few select quotes:

To attempt to replace some of the Markdown guidelines and call it “Standard” was juvenile.


It’s now called “Common Markdown”. The explanation does not seem to fit the sarcastic and childish comments posted on Twitter or in the project comments, but hey, the name is coming along nicely. Funny thing is that I think “Standard Flavor Markdown” was much less offensive and a safer bet.

and his second footnote:

Jeff’s own comment on the matter is rather childish.

So, there’s that. If I’m mistaken about Atwood’s attitude, at least I’ve got company.

(via Dr. Drang)

Legitimate Text Processing

Joe Steel at his blog, Unauthoritative Pronouncements, earlier pointed out a couple of the same things I did today, as well as a few others that I hadn’t considered.

In the “Standard Markdown” spec, they include GitHub Flavored Markdown’s “fenced code blocks”. Oh! Well, would you look at that! It’s a feature that serves the needs of one of the “Standard Markdown” contributors. It has nothing to do with the original specification of Markdown. This isn’t solely about removing ambiguity, of course, it’s about making the Markdown someone wants in to the correct Markdown.

Where are the tables? Tables are not a “core feature” like GitHub fenced code blocks. Where’s ids for headers? No one needed it, but Jeff agrees about maybe putting it in. Where’s the metadata storage? Guess no one needed metadata storage. Maybe they’ll come later on, and we’ll have “Standard Markdown 2.0 Compliant” badges we can adorn our blogs with. Maybe we can put a special header in our text files that says what the human-readable text should be processed with? You know, like “!#/usr/bin/StandardMarkdown/Official/2.0.1.a/” Something easy on the eyes.

(via Dr. Drang)