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.  ↩

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)

Markdown Follow-Up

Following my “Standard” Markdown Controversy post, I’ve had a few exchanges on Twitter with people who made basically three points:

  1. “All Jeff Atwood was trying to do was create a standard.”
  2. “If Gruber had objections or wanted to be involved, he could have been.”
  3. “Gruber had plenty of warning about what they were doing.”

Trying to explain anything on Twitter is like trying to drink a shake through a cocktail straw; 140 characters is not enough even for a proper sentence. So, I’m going to address these arguments here. I often think in similar ways to John Siracusa, so if you listened to the Accidental Tech Podcast episode 81, much of what I will say is substantially the same.

Point 1: Standards

Standards committees effectively wrest control of a project away from a creator, in much the same way that the founder of a company can be kicked to the curb by a board of directors. There is no upside for Gruber to participate in creating a new standard. If he involves himself, he’s lending credibility to their efforts, and collaborating in his removal from relevance.

This completely ignores the fact that he fundamentally disagrees with the direction they want to take the project. The ways they want to change Markdown fit their use cases, but do not necessarily fit any other use case. Gruber’s original Markdown is completely focused on online writing.

They obviously don’t care about tables, for example, or footnotes, because they don’t address them at all. I guess they’re leaving that to “nonstandard” variants like MultiMarkdown, which address usages needed by offline writers and academics, but will not deign to include such things in their One True Way.

But code blocks? Ho, boy, do they like code blocks; indented, fenced, and conceptual. They’re programmers, so of course being able to include and flexibly markup code blocks is far more important (to them) than other issues.

This is the main problem with a new standard: whoever creates the standard defines it. A group of programmers wants to reduce ambiguity and strictly define use cases, make consistent HTML output, and introduce various ways of formatting code blocks within the markup. Shocker. Their standard is not a standard that a group of designers, or a group of writers would have created. Few of the proposed changes would improve actual usage for anyone except programming-focused writers.

Point 2: Involvment

Yes, Gruber could have been involved if he wanted to be. He doesn’t want to be involved (see Point 1). As I wrote in the earlier article, Atwood was agitating for a revised spec at least as far back as 2009. (Probably even before that, but that was the first time I’d heard of it, and I wasn’t even using Markdown at the time so didn’t particularly care.)

So what? Again, as I said earlier, Gruber doesn’t get his panties in a bunch about forks that use the concept but not the name, or forks that use part of the name — with prior permission — while preserving his original usage, but extending Markdown in various ways.

It’s pretty obvious that what he objected to was the attitude of entitlement and propriety Atwood assumed. The lack of respect is palpable in nearly every public exchange between the two that I’m aware of. As Siracusa pointed out, it’s probably Atwood’s frustration with what he perceives as Gruber’s intransigence toward changes in an open source project. There’s no question that from a programming standpoint Gruber has not been making regular revisions and contributions to Markdown, and that must be infuriating for a programmer, like Atwood. It’s likely that his feelings for Gruber as a person have been colored by his interactions regarding Gruber’s work.

However, Gruber is under no obligation to make changes, nor confer legitimacy on someone who wants to change his implementation. It’s his thing, he can do whatever he wants to with it. He has been fairly generous in the past, even in comparison with other open source developers. The sticking point here was the appropriation of the name. Hell, it’s in his license:

Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

(Emphasis mine.)

Point 3: Notice

Silence does not imply consent.

Gruber’s “advance notice” was being told what they were planning to do, not being asked for his permission. There’s a big difference, though it’s apparently invisible to some people, considering my interactions on Twitter and comments I’ve seen in other forums.

It’s the same difference between telling your dad, “Hey, I’m taking the car sometime after dinner”, and “Hey, dad, can I use the car after dinner?” One is likely to result in being able to use the car. The other is likely to get your car privileges revoked for at least the evening, and maybe for a couple of days following, unless you quickly correct your attitude.

No form of the name Markdown should have been used without Gruber’s express permission. They didn’t get it. They should never have proceeded with using “Standard Markdown” without it. And then they compounded the problem by — yet again — changing the name on their own timeline when they notified him (not asked him) that they were going to use “Common Markdown” instead.

What is so puzzling is that Atwood doesn’t need to take anything from Markdown to make this project successful. He could make his own implementation and be within his legal and ethical rights. Don’t like the spec? Make your own strictly-defined one. Just don’t use the name of the original or use the name of its creator to promote your version.

Atwood is well-known enough in the tech/programming community that he certainly doesn’t need to ride Gruber’s coattails. He could have called it something like Flugelhorn and still gotten people trying it out due to curiosity. It really is mind-boogling that naming even became an issue, especially after all the work put into the coding part of the project.

If CommonMark (name changed again at Gruber’s request[1] because of Atwood jumping the gun) is actually superior to Gruber’s standard Markdown, it will be widely adopted. Make something that works better, and it doesn’t matter what you call it, people will use it. Like I said, I use Fletcher Penney’s MultiMarkdown instead of Gruber’s original because it fits my uses better. It’s possible that CommonMark will supplant Markdown and become the better-known, more widely-used version. I doubt it, but it is possible. Committing to winning on the merits of the implementation, not on name-recognition, is what should have been their focus in the first place.

  1. “Edit: after a long and thoughtful email from John Gruber – which is greatly appreciated – he indicated that no form of the word ‘Markdown’ is acceptable to him in this case. We are now using the name CommonMark.”  ↩

How I Write

If you’ve read my past blog posts, you know that I’ve complained (and moaned, and whined, and sometimes even whinged) about long work hours and working 6 days a week. I’ve also got a kid and a wife who I’d really like to spend time with. My update schedule is not particularly rigorous, but I do manage to post occasionally. I would never be able to write anything at all if I didn’t use the little time I have in between other responsibilities as efficiently as possible

These are the main tools I use for writing:

  • Simplenote
  • nvALT
  • Markdown


Simplenote is an iOS app and also a syncing service. I originally started using it because the Apple iOS Notes app was both ugly and clumsy. I got an iPhone 3GS when the only way to sync notes with Apple’s Notes iOS app was to email them. That’s probably less of a problem now with iCloud, but at the time iCloud wasn’t even a twinkle in MobileME’s eye. The legal pad theme with unchangeable Marker Felt font made for a really horrible user experience. It wasn’t good even for short-form notes, and longer sections of text were rendered virtually unreadable.

Simplenote, in contrast, is an app with very lightweight design. It features a plain white background with Helvetica type. It makes note creation absolutely painless because you just start writing; Simplenote uses the first line of your note as the title. It may seem silly, but that one little feature is the main reason I haven’t switched away from Simplenote. Note creation was so frictionless that I had dozens of notes within just a few days of installing Simplenote. Compare this to a handful in Apple’s Notes app after months of having an iPhone.

Apps like Notesy and Byword have some features to recommend them, but because of the ease of note creation in Simplenote, I haven’t switched to using either of those full time. Notesy is my second-choice app, and if you’re dedicated to Dropbox syncing, would be my top suggestion as the best text iOS app for an iPhone. Byword is great on an iPad, but doesn’t feel quite as good on the iPhone’s smaller screen.


One of the points of installing Simplenote was the sync support. While you probably can write long-form articles on an iPhone, it’s far from ideal. I really wanted to be able to view and edit my notes on my Mac too. From the Simplenote website, I picked the desktop app that most people seemed to like using: Notational Velocity.

NV has a really different paradigm for note creation than most applications: you just start typing. The top entry field works both as a search and a note creation function. As you type, it culls the list of notes in the lower pane based on the words you type. If you enter a unique string, there’s your title. Hit enter, and the note file is created automatically. The note body is in the lower pane.

Once I’d used it a bit I realized that this method of note creation was really, really fast and easy. It now seems odd that I have to separately enter a title for a file in other programs instead of having one automagically created for me. You don’t explicitly save either; Notational Velocity always autosaves on exiting a note. Sync is seamless and usually propagates to other devices in a matter of seconds.

I used Notational Velocity for a few months before I found nvALT, which is a fork of Notational Velocity. I immediately liked it a bit better than the original Notational Velocity due to some interface tweaks. nvALT also has MultiMarkdown support including autocompletion features, which I found useful later when I started using Markdown. A preview window allows you to see the results of your markup side by side with the plain text original. You can even make your own custom CSS file if you’re really particular about seeing exactly what the finished product should look like. You can view and save the HTML generated from Markdown from the preview window.

nvALT syncs through Simplenote by default, but you can sync through Dropbox instead of or in addition to Simplenote’s API. This is useful for those iOS apps that don’t support Simplenote sync. I use nvALT more often than any other piece of software on my computer besides Safari.

Simplenote and nvALT are the linchpin of my writing workflow. Simplenote lets me capture ideas whenever I have them, and nvALT lets me work on them when I get a chance to expand on those ideas, check my markup, and painlessly generate HTML for web publishing on any platform.

By default, both NV and nvALT store notes in a database file, but there is support for storing notes as individual RTF or TXT files. Back in college, I got burned by the incompatible format problem. I had half my life in WordPerfect and MS Works files, both of which became imperfectly readable as newer software came out. I ended up having to convert a bunch of files and clean up conversion errors by hand. After that, I decided to stick with plain text instead, and no proprietary databases whenever possible.

For future-proofing, so that I can use Spotlight to search my notes, and so that Dropbox syncs are faster and more granular, I store my notes in TXT format. My setup is basically the same as A Better Mess’s recommendations for working in plain text files with nvALT.

Markdown / MultiMarkdown

So, I’ve mentioned Markdown a few times. What is Markdown? If you’re any kind of ’net geek, you probably know already. For anyone “normal” who actually got this far (close to 1,000 words of geekiness) into this post, Markdown is John Gruber’s1 markup language, created specifically for writing on the web. It’s a subset of the things you can do with HTML, and has deliberately been kept simple. MultiMarkdown by Fletcher Penney is a slightly expanded version of Gruber’s original that makes it viable for more complicated writing tasks. Output from MultiMarkdown (MMD) can be HTML, PDF, LaTeX, and through scripting damn near any other text file format.

I only use a few of the things MMD is capable of, but I learn more about it all the time as I run into situations where I want to use more complicated formatting. It’s extremely useful since it’s much more succinct and easier to use than HTML, and it’s far more readable.

Other Tools

  • Dropbox
  • Notesy
  • TextExpander
  • Scrivener

Dropbox is not completely essential to the way I write, but it’s very useful. If I were doing my finishing work on an iPad instead of a MacBook Pro, I’d probably share the experience of many other people who find that Dropbox is the linchpin for their entire workflow. What I do use Dropbox for is syncing everything else that doesn’t go through Simplenote, and for redundant syncing. While Simplenote’s sync works well most of the time, there have been at least two occasions when the app locked up and became unusable when I had a lot of notes — somewhere between 500 and 800 when I had that problem. I’m not sure if the cause was a syncing backend issue, or the sheer number of notes, but I’ve since culled my pile ‘o’ notes and haven’t had the same problem.

Shawn Blanc experienced the same kind of syncing problems. Like him, the occasional wonky sync led me to look for Simplenote alternatives — the best of which for my usage patterns is Notesy, which doesn’t use Simplenote sync. My nvALT setup syncs to both Simplenote and Dropbox, so I can access my text files in any text editing app, and it also gives me a secondary backup. I use Notesy for some final editing and writing when I don’t have access to a full computer. It has Markdown support (which is oddly not available in Simplenote’s iOS client, but is supported in the web client) so I can check to see that my markup works properly before I commit to posting.

I also use Dropbox to sync TextExpander snippets across both OS X and iOS platforms. I came to TE late in the game, only having installed it in the last few months, but I do find it useful for some tasks, especially for typing common things on my iPhone. I use it mostly for tagging, and some markup and formatting tasks that are more painful on a small keyboard. One extremely useful element is that it can reposition the cursor after expanding a snippet, which is much nicer than the (probably unavoidably) fiddly magnifying glass interface in iOS. In addition to my own snippets, I’ve found Brett Terpstra’s iOS Markdown snippets to be useful.

In the past I used Scrivener for my blog posts, which is an excellent writing tool, but I found it is a bit too heavyweight for the shorter length of blog writing. I’m currently using it for working on several articles meant for magazine / online periodical publication and an outline for a book. If you do any long-form writing, it’s fantastic.

I’ve probably barely even scratched the surface of what it can do, but here are some features I’ve found useful: Scrivener can sync through Dropbox or Simplenote. It supports MultiMarkdown and — via MMD — LaTeX. A Scrivener file is a package, and there are no proprietary formats for the content inside that package. Text is stored as RTF by default, but you can store in plain TXT files instead. It can read OPML files, which most brainstorming / mind mapping programs either use or can export to, so you can automatically create an outline for writing from a file you created in something like MindNode Pro that lets you access radiant / gestalt thinking more easily to spark creativity.

You can work on your document in many small chunks, each stored as a separate text file, and compile them together into one large document at the end, processing text with a variety of scripts to generate just about any kind of text file, including Final Draft, Word .doc files, PDF, and ebook formats, among many other possibilities. For any kind of long-form writing, especially fiction, it’s an extremely useful application.

  1. John Gruber writes Daring Fireball, a site you might have heard of.  ↩