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.

Bear

Good:

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

Bad:

  • 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

Ulysses

Good:

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

Bad:

  • 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, http://notesy.net 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.  ↩

Twitter’s Missing Manual

One of Twitter’s problems is that it’s tilted a little too far towards the vim end of the scale. It looks like a dead-simple service, but those humble 140 characters have been crammed full of features over the years, and the ways they interact aren’t always obvious. There are rules, and the rules generally make sense once you know them, but it’s also really easy to overlook them.

I’ve known about Twitter since around 2006, but I’ve only been using it — haphazardly at first — from maybe 2011. Even though I’m pretty good about figuring out unwritten rules (see: living in Japan), as a semi-newb to the service there are a lot of things about how it works that I really didn’t know. This is a fantastic resource.

Three takeaways for web developers after two weeks of painfully slow internet access

This writeup on Medium is a great article for app and website developers. Like designing for accessibility, considering and designing for slow data access can vastly improve user experience.

I had to use tethering to get work done over the last month due to a very flaky wi-fi access point at a work location. Because of that, I managed to hit my data cap before the end of the month, and spent over a week with horribly throttled access that rendered anything without an offline mode or a robust low-data mode basically useless. Most syncing worked — slowly; most browsing or even non-text Twitter didn’t.

Third-party apps fared the worst. I could get pages to load in Safari on my iPhone that Tweetbot was unable to display. This experience, not long after the announcement of Safari View Controller across apps in iOS 9, made me fully appreciate just how big of a change more open developer access to Safari will be. Developers won’t have to write their own browsers, and users will get access to all of the caching and performance tweaks implemented in the system browser. When you’re running at 0.12 Mb/s up and down, you really, really appreciate optimizations and performance fallback modes.

Accessibility and iOS

I’m way late in linking and sharing these:

Global Accessibility Awareness Day and why it matters

Why making your apps accessible is just the right thing to do

If you want to find out what it’s like for a blind or partially-sighted person to use an iPhone, set it to Accessibility Mode: Settings -> General -> Accessibility -> VoiceOver On. There are options in that menu for Braille output devices and other assistive settings. You can set VoiceOver to toggle on and off with a triple click on the home button in Settings -> General -> Accessibility -> Accessibility Shortcut; which can be found at the bottom of the Accessibility page.

It’s interesting to experiment with alternative UI (User Interfaces) like this. Those settings are semi-hidden since most people will never need them, but they are essential for some. Since iOS 3 introduced VoiceOver APIs, Apple has steadily added all kinds of features for disabled users.

In addition to literally making the difference between independence and dependence for the people who use their software, some programmers have said that designing an app with usability in mind makes them concentrate on the details. That focus may actually result in better apps for people with unimpaired sight and mobility as well.

Trust Your Designer

… We understand that it’s hard sometimes to let go of the familiar. For instance, we recently had a client that was having a hard time letting go of their preconceived design expectations for their website. They were set on a particular color and typeface that didn’t necessarily appeal to their ideal audience. They were hesitant to allow “white space” (empty space for design purposes) on their website and were adamant about filling up every open spot with their company tagline.

This reminds me of a video I saw recently, featuring an engineer talking to business people. People who don’t know what they don’t know are particularly tiring to deal with. Very few people besides actual designers have any training in design, so nearly every conversation about design must feel a bit like that.

Part of hiring professionals is letting them do their jobs. Presumably, you’re hiring someone to do something you recognize you are unable to execute well, or in some cases at all. Believe me, anyone who isn’t laboring under a cognitive bias recognizes quality when they see it. They also can see when that Dunning–Kruger effect is in full effect by how their eyes bleed from the horrible appearance of a web page and the curses stream from their mouths after their sign-up password is rejected for the third time under previously undisclosed criteria imposed by an incompetent design.

Other fun things for a designer are being told how to do their jobs by someone who would probably not comprehend how anything in my previous links applies to them — but who would oh, so very much benefit from any slight amount of understanding — and being asked to work for free. To the latter, there is only one reply.

To all those who hire professionals and actually trust them to do their work, THANK YOU. The world needs more of you.

Design Is about Intent

The Three Design Evasions The opposite of design, then, is the failure to develop and employ intent in making creative decisions. This doesn’t sound hard, but, astonishingly, no other leading tech company makes intentional design choices like Apple. Instead, they all commit at least one of what I term the Three Design Evasions:

He goes on to explain in detail about Preserving, Copying, and Delegating. This is one of the most cogent and precise explanations I’ve seen of what makes a good design process, and what cripples one.

10,000 Year Clock

The time scale humans operate on is extremely short by geological standards. To provide some reference for how ambitious this project is, the famous pyramids in Egypt are only about 5,000 years old. The history of agriculture itself only goes back about 12,000 years. Ten-thousand years ago, nearly every human on this planet was a hunter-gatherer, and now nearly every human lives in an industrial society. This clock, even if it lasts only half as long as planned, is likely to outlast nearly every other significant artifact of our culture.

Practical Benefits of Good Design

Horace Dediu in his post, Invaluable:

To earn profit is hard, to do so in an outsized way is very hard and to do so with consistency shows a defensibility of market access that is rarest of all. The only cases where this typical is in a monopoly or protected market situation (aka cronyism.) Apple’s lack of market monopoly coupled with a (near-) monopoly in profits can only be explained by disproportionate value creation.

The mystery then is how is it possible to build a monopoly in value creation.

This is a prime example of the “simple, but not easy” adage. Apple’s winning strategy is:

  1. Make something of higher quality than their competitors.
  2. Make it more efficiently than competitors.
  3. Profit!

Credit often goes to Cook for Apple’s logistics, but what often goes overlooked is the efficiency of Ive’s hardware designs. Everyone notes the aesthetic details, but the manufacturing processes he and his team has created are probably more valuable than the external appeal of the hardware.

My grandfather was a machinist, one of the old-style tradesmen who learned empirically rather than academically. He and his team worked on some of the first ejection seats and later the missile bay doors on planes like the F–111. He’d be given a design by the engineers and asked how to make the pieces they needed, because often they lacked the industrial background to plan out processes.

Modern designers of Ive’s calibre are trained about how to make things — how to chose materials and processes — as well as how to make them look pretty. The unibody manufacturing process of current Macs was original to Apple, and they were in fact granted patents for it. Because the cases are made of a single piece, with intrinsic structural support elements, they use fewer parts overall than piece-made cases, which means fewer external part costs, lower material costs, and fewer assembly processes, all of which keep operating costs lower. Added benefits are better structural rigidity, lower weight, and recyclable waste. They’re made with mostly automated machining operations, which again lowers manufacturing costs, and greatly increases the average quality of the pieces with tighter tolerances and vastly fewer flaws.

Jobs was mainly responsible for Ives’ current prominence, and like so many things he was involved in, you can see the seeds of his idea decades before they came to fruition. The manufacturing facility at NeXT was one of the first automated assembly lines for technology products.

While Apple’s manufacturing in the last decade or more has predominantly been in China, I think the Mac Pro production facility is their test bed for moving more processes closer to home. There is huge value in having production close to the designers. Iteration takes far less time, you can talk directly to the people making the parts, and you can see for yourself where bottlenecks or unnecessary steps in the manufacturing process occur.

Time and time again, makers featured in forums like The New Disruptors have cited the benefits of working in proximity to manufacturers. Being able to produce at scale is the main reason given for choosing an overseas production facility, even when in other respects it’s far from ideal for refining the design.

You can be sure that if relative amateurs in the field know this, Cook, Ives, and others involved in design and manufacturing at Apple are keenly aware of the potential benefit of moving critical parts of its production closer to its base of operations.

Look for the Texas and planned Arizona facilites to take on more importance. I don’t expect to see any expansion in the Bay Area due to inflated land costs and high costs of living, but there will be new sites in US states with inexpensive land, favorable taxes, and lots of solar and other renewable energy available.

With the Texas plant refining a new case process, and the Arizona one to produce glass, Apple is strategically taking on critical parts of manufacturing the iPhone and iPad, which make up a disproportionate amount of its current profits. Experimentation here will also yield dividends in any new products they might want to create, lower the chances of “secret” projects leaking, and possibly present lessons for refining manufacturing in their overseas facilities as well.

Using it Wrong

Our previous intranet was bad. This year’s is worse. A single representative example: This button breaks the intranet.

Click here to make sure no one else can read this…

Click here to make sure no one else can read this…

Before, you could mark a memo as “read” without causing problems. It wasn’t perfect, but at least the conceptual model was appropriate to the technology. My main gripe with the old one was that you had to “create” a file to access and delete a previously-created group message, which is nonsensical to anyone but, apparently, a Japanese engineer.

The new system is based on the traditional Japanese office model of circulating information: A cover sheet with a list of the relevant people’s names is attached to the circular. Each person checks off their name when they’ve read it, optionally filling in a read-date. When you’ve read it, you pass it on to the next person. The last person to receive and read it returns the circular and cover sheet to the originator.

In this picture, the ESC button reads “End” or “Close” in Japanese. The F8 button is, “To the Next Person”, and the last is, “Cancel Circulation”. The problem? That button is enabled for everyone, not just the originator. It’s right next to the also inappropriately labeled “Next Person” button, which functions as a read/receipt acknowledged button, so it’s easy to click by mistake.

Nearly 9 months after this system was introduced, someone still occasionally clicks on that button by mistake, or just because it seems like a reasonable action. Everyone has been told — multiple times — not to click on the 回覧中止 button because it removes access to the file. Yet it has happened even in meetings. Maybe half the people haven’t opened the file yet, but one early bird opened it, glanced through the contents, and then clicked the Forbidden Button. Everyone who tries to access the file after that either doesn’t even have an entry in the menu, or gets an error message, and then the originator has to re-upload the file and re-send a link message to the appropriate group list.

If people are “using it wrong” it’s often because you designed it wrong.

There are at least three very simple ways this particular problem could have been avoided:

  1. Don’t have the button there at all. The conceptual model doesn’t fit the use case. Allowing an end-user to stop access to a file that everyone can access independently or simultaneously is Bad Design With Big Fucking Blinking Red Letters Set In Goddamn Comic Sans.
  2. Disable that button for everyone but the originator of the message. If you insist on putting a Global Thermonuclear War option on the main message-receipt page, the least you could do is keep people from starting WWIII by accident.
  3. Don’t honor that instruction until everyone has sent a read/receipt token to the server. Having the button present and enabled is still piss-poor design, but at least you’re not letting the first person in a circulation prevent all other users from accessing it, or even knowing of its existence.