Fantastical 2.4

Michael Tsai - Blog - Fantastical 2.4 for Mac

It’s like they read my mind and implemented my four most-wanted features. Great update. Hopefully attachments and travel time will also come to the iOS version soon.

Fantastical at this point is simply the best calendar application on both macOS and iOS. It is one of the handful of apps that I absolutely must install right away when I get a new device. It has come a long way from the first version, when it was essentially a clever menu bar widget for fast iCal (later Calendar) entry.

When Fantastical 2 first came out, I still kept both Apple’s Calendar app and Fantastical in the dock. Some things were better displayed on Calendar than Fantastical. As Fantastical has improved, I found increasingly fewer reasons to open Calendar, and eventually I removed it from the dock. On iOS, I still (technically) use Calendar. Calendar’s widget is better than Fantastical’s for showing the coming block of time, so I have both widgets enabled in Notification Center.

I have been using URIs, and later Dropbox-sharing URLs, as a workaround for attachments in iCal for a very long time, probably nearly as long as it has been in the spec. This works but has never been very elegant. Since I’ve got those habits and some automation built around it, in practice I’ve found I don’t use actual attachments often, though the implementation in Fantastical 2.4 is well done.

The combined calendar display is clever, and it’s both useful and reasonably attractive. I set up a Zapier-to-Google-Calendar workflow to start certain timers on Toggl sometime after I started doing time tracking full-time at the end of 2016. This update makes it possible to leave that calendar visible as an indicator that those events are properly mirrored, without the calendar view feeling crowded and cluttered. Like many good software innovations, it feels so obvious once you see it that you wonder why no one ever did it that way before.

Undo and redo are features that I would have benefitted from literally only hours before the update was released. The extended month view is a good compromise to deal with the problem of high information density in limited space.

Daring Fireball

It really is a great update. I’m not even sure what to ask for at this point. No app is ever “done”, but at this point Fantastical feels feature complete.

Gruber may think Fantastical is feature-complete, but I’ve had something on my wishlist for years. No software on the market offers the ability to set odd intervals or perform date calculations. I’ve had some recurring duties that are supposed to be done every 10 days, not counting holidays.

I can’t simply enter an event like this in any calendar software with a preset reminder and forget about it until I get an alert. Instead, I have to enter dozens of entries at odd intervals; or enter a repeating event, check every single future event, and move ones that conflict, with cascading changes necessary further on.

Supposedly, the automation of detailed repetitive tasks that are easy to screw up if you do them manually is what computers were made for, but no one seems to have filled this niche. This kind of interval is a really common case for educators and students. Though it might be more rare for regular office workers in many places, it’s quite common in Japanese offices to have duty rosters that don’t follow a normal weekly schedule, like my 10 day rotating schedule.

Most calendar programs don’t even have a way to set something like “the third Saturday of every month”. Fantastical gets this right on either macOS or iOS. But I wish someone would build support for entering arbitrary intervals that could be cross-referenced with another calendar, like a subscribed holiday calendar, for conflicts and automatically enter events so that they fall on the appropriate date.

I was so frustrated with having to enter so many of these kinds of events by hand at the beginning every new work year, that I investigated scripting my own solution. Which is like being annoyed by a single mosquito and deciding to eradicate malaria.1

Also, while Fantastical’s natural language parsing is really good, there should be a way to specify a note for the event as part of your entry. You can set notes using the URL scheme on iOS,2 and both iOS and macOS versions will recognize and appropriately handle anything that looks like a URL in the input, but there’s no way to enter a note through the input box without having to click and drop down into the extra info section. A single basic alert can be set by typing something like alert 1 day but neither something like note foo nor note:foo work for setting notes.

Still, these are relatively minor gripes. Fantastical lives up to its name. It is a true Calendar replacement, and it is simply the best calendar for entering new events, which is something I have to do on a near-daily basis.

  1. Sure, no problem. I’ll just whip up a sterility-inducing retrovirus in my spare time. How hard could it be to learn genetic engineering when you figured out basic bio?  ↩

  2. There’s an excellent guide for using Fantastical’s URL scheme at Geeks With Juniors.  ↩

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

Cartography Comparison

Justin O’Beirne did a great in-depth comparison of the different ways Google and Apple approach mapping.

From the summary of Part 1:

We looked at 54 pairs of maps across three cities (New York, San Francisco, and London) and found several significant differences:

  • Apple Maps, on average, labels more cities than Google at every zoom.

  • Google Maps, on average, labels more roads than Apple on nearly every zoom.

  • For two-thirds of zooms, both maps generally show the same number of roads. For the remaining third, Apple almost always shows more roads.

  • Both maps, on average, label a similar number of POIs [Points Of Interest] —but have only 10% of their POIs in common on an average zoom.

  • Both maps also prioritize different kinds of POIs: Google Maps heavily prioritizes transit, while Apple prioritizes landmarks. Apple also generally shows a greater number of POI categories on a given zoom—and shows twice as many restaurants and shops as Google.

When Apple Maps launched in iOS 6, I wrote a short post comparing it to Google Maps in Japan. I found that — for my location at least — Apple’s implementation was actually better in some ways at launch than Google’s was after several years.

The main reason I don’t use Apple Maps preferentially is the continuing lack of support for transit. Train scheduling and transfer information is hugely useful in Japan, so I end up using Google Maps much more often for station to station directions, while I usually default to Apple Maps for local guidance when I reach a location. It’s interesting to see that my purely intuition-based switching between them for different roles apparently has some empirical support as well.

TextExpander as Subscription Software

TextExpander as Subscription Software

When Should Software Be a Subscription Service?

I don’t contest the fact that developers need income. I have gladly upgraded TextExpander every time there was a new version, even if the changes weren’t important to me. It’s important to support independent developers, to ensure that the Mac and iOS ecosystems have excellent apps. In addition, the race-to-the-bottom pricing that we’re seeing with the App Store model is preventing developers from making enough profits.

This blew up while I was still recovering from some minor surgery and so I missed most of it as it happened. Kirk McElhearn’s take on the pricing part of the equation is very nearly the same as mine.

Besides the huge increase in average yearly pricing that McElhearn laid out very clearly, I have three major problems with the subscription model:

  1. If TextExpander can’t connect to a server, will the snippets disappear until it can? If there’s no offline mode, TextExpander would be basically useless to me. One of the places I work has a very spotty internet connection. Even on my iPhone, I’m occasionally completely offline, but am still doing work that I would normally use TextExpander for.

  2. I have serious reservations about the security of Smile’s syncing solution. I do not have particularly sensitive information in my snippets, but I do have things like email addresses, physical addresses, and phone numbers. All of that will be stored unencrypted on their servers. They seem to be pushing toward an enterprise market, but the level of security Smile is committing to at this point is inadequate for an only moderately-concerned private user like me.

    In TextExpander’s manual they advise against using it to store anything potentially compromising, like passwords, but for many companies contact information or simply the names and positions of certain individuals in an org chart could be considered sensitive information.

    Usually, in enterprise-level software, companies want to run it on their own servers that they control, and they contract with the software provider for support service for their IT staff. I’m pretty sure most companies who might otherwise consider TextExpander would balk at Smile’s proposed syncing solution.

  3. This move offers zero benefit to me, the user. I don’t use Windows, and haven’t for about 15 years. If I did, I probably would be pretty happy about the announced support for that platform. I don’t work with teams and I don’t share snippets with a group. Having to use someone else’s shortcuts sounds like a special kind of hell to me.

    I have no incentive to “upgrade” other than the stick of eventual obsolescence when the old version breaks. While I could possibly justify the price, given how much I use TextExpander on both OS X and iOS, it’s still a significant jump. The announcement of the pricing change has prompted me to explore other options, and I’m sure I’m not the only formerly-loyal TextExpander user doing so, which can’t be good for Smile’s future sales.

One small misstep like this can drastically change people’s perceptions of your company. Apple can get away with taking away peripheral ports and eliminating optical drives because they generally get it right in the long-term, and sometimes offer temporary fixes in the transition.

Smile probably should have offered a two-tier pricing model: Basic users pay a one-time fee for major updates; “Pro” users pay an additional recurring cost for access to certain capabilities. Most people would have had no negative reaction to that model, and even basic users would have considered the pro upgrade to see if it fit their needs.

Unfortunately, Smile alienated a large section of their most loyal user base with an announcement that made it obvious that Smile’s future priorities and their customers’ priorities are definitely not the same. If it was their way of “firing” those customers in favor of a different user base, as some have speculated, Smile has definitely not put in the kind of work they need to successfully court the enterprise market, even though all of the announced features sound as if they were created for business users over individuals.

For me, ultimately, the problem isn’t the pricing. The problem is that I can’t count on Smile to continue making a product that works the way I want it to work. They’re solving problems I don’t have, and pushing features that make me distrust their future versions.

We Could Not Look the Survivors in the Eye if We Did Not Follow this Lead

FBI Director James Comey’s post on the oddly-named Lawfare blog:

The San Bernardino litigation isn’t about trying to set a precedent or send any kind of message.

This is disingenuous at best. Given that Tim Cook directly addressed the issue in his open letter, “Rather than asking for legislative action through Congress, the FBI is proposing an unprecedented use of the All Writs Act of 1789 to justify an expansion of its authority,” and the New York Times reported that Apple had initially requested that the request be kept under seal, it seems pretty clear that FBI Director Comey is deliberately picking a public fight.

The whole piece is an appeal to emotion, starting from the second sentence:

It is about the victims and justice. Fourteen people were slaughtered and many more had their lives and bodies ruined.

And nothing in the remainder is more honest or less manipulative than the opening lines.

You could see this coming years ago. He and other authorities have just been looking for an excuse, choosing the time and battleground for the confrontation.

One of the FBI’s Major Claims in the iPhone Case Is Fraudulent

The ACLU on the FBI vs Apple encryption backdoor:

If this generally useful security feature is actually no threat to the FBI, why is it painting it in such a scary light that some commentators have even called it a “doomsday mechanism”? The FBI wants us to think that this case is about a single phone, used by a terrorist. But it's a power grab: law enforcement has dozens of other cases where they would love to be able to compel software and hardware providers to build, provide, and vouch for deliberately weakened code. The FBI wants to weaken the ecosystem we all depend on for maintenance of our all-too-vulnerable devices. If they win, future software updates will present users with a troubling dilemma. When we're asked to install a software update, we won’t know whether it was compelled by a government agency (foreign or domestic), or whether it truly represents the best engineering our chosen platform has to offer.

In short, they're asking the public to grant them significant new powers that could put all of our communications infrastructure at risk, and to trust them to not misuse these powers. But they're deliberately misleading the public (and the judiciary) to try to gain these powers. This is not how a trustworthy agency operates. We should not be fooled.

Possibly the most worrying thing about this mess is how blatant the FBI and other law enforcement agencies have been about trying to set this precedent. They almost aren’t even bothering to pretend that it is, indeed, about all phones, not just this one.

And again, use my Worst Enemy Test: If you had to permit your worst enemy access to these powers, would you still support the legislation?

I suspect Director Comey wouldn’t be okay with his political opponents being able to compel Apple or Google to create their own backdoors to bypass the encryption on his phone. Would anyone be happy about President Trump having “sooper sekrit” access to anyone’s information?

NSA could crack the San Bernadino shooter’s phone

Clarke added that if he was still at the White House, he would have told FBI Director James Comey to "call Ft. Meade, and the NSA would have solved this problem…Every expert I know believes that NSA can crack this phone." But the FBI wasn't seeking that help, he said, because "they just want the precedent."

Yep, it's pretty obvious that what FBI Director Comey is really going for is the legal precedent, not the information.

Tech giants don’t want Obama to give police access to encrypted phone data

In a Washington Post article from last year:

Tech behemoths including Apple and Google and leading cryptologists are urging President Obama to reject any government proposal that alters the security of smartphones and other communications devices so that law enforcement can view decrypted data…

The letter is signed by three of the five members of a presidential review group appointed by Obama in 2013 to assess technology policies in the wake of leaks by former intelligence contractor Edward Snowden. The signatories urge Obama to follow the group’s unanimous recommendation that the government should “fully support and not undermine efforts to create encryption standards” and not “in any way subvert, undermine, weaken or make vulnerable” commercial software.

I've said before that it's a bad idea to weaken encryption for the sake of law enforcement. This current confrontation between the FBI and Apple has been years in the making.

Multilingual Keyboard Switching

Federico Viticci of MacStories commented on Wang Ling’s proposal for a redesign of the keyboard switching experience in iOS.

Once you throw in a couple of additional keyboards in the mix … the only sensible way to switch keyboards is tapping & holding the globe button then sliding over to the keyboard you want to use again – which takes about 1 second in my experience … That doesn’t sound like a lot, but the annoyance adds up; plus, imagine doing that for years.

I have five keyboards enabled: English, Japanese romaji, traditional Chinese (for writing recognition of hand-drawn characters), emoji, and TextExpander. My wife primarily uses Japanese on her iPhone, and has three keyboards: English, kana, and emoji.

To add a couple of gripes I didn’t see Viticci make, the emoji keyboard moves the keyboard switch one slot to the left and removes the visual indicator of the globe, making switching from that keyboard back to other keyboards especially annoying. And, third-party keyboards don’t (or can’t) honor the tap-and-hold multi-keyboard switch, which has been the case since they were first allowed in iOS 8.

Wangling’s design proposal has my support and duplicate radar report.

  1. Enabled keyboards can be put in one of the two groups: frequently-used keyboards and occasionally-used keyboards.
  2. Considering most uses are monolingual, in order to avoid unnecessary recognition burdens on them, only the frequently-used keyboard group is shown by default. Only after a user enables more than 2 keyboards should the occasionally-used keyboard group be shown and an explanation be given.
  3. Single tap on the globe button only switches among frequently-used keyboards.
  4. Long press the globe button to present the keyboard picker which includes all enabled keyboards so users can switch to their occasionally-used keyboards.Single tap on the globe button while using a occasionally-used keyboard switches back to the previously selected frequently-used keyboard.

Fast Contact Creation with Interact

Last year, I wrote Sending Group Emails in iOS, where I showed how to use TextExpander and Drafts to efficiently send emails to a list of recipients on iOS. Apple’s Contacts app doesn’t let you do that at all, unless by “group mail” you mean, “manually add every single recipient from a group with a two-to-three tap interaction” and “you better hope you’ve already created a group on your Mac, because you can’t do it in iOS”.

Earlier this month, Interact, by the maker of Drafts, was released. Dr. Drang tweeted about it, which is what got my attention. Since Drafts is one of my most-used apps, I bought Interact about 15 seconds after reading the description.

Interact is a contacts manager for iOS. The selling point for me was actually not the group management features, but the scratchpad. Dr. Drang’s post about Interact explains the details, but similar to Fantastical, Interact uses language parsing to figure out what bits of information should be entered into what fields in the contacts database. It works directly with your contacts on your phone, so changes should be instant locally, and sync to your other devices through iCloud via Apple’s native Contacts app.

One limitation I found on the first day I used Interact was that it didn’t support the full complement of fields available. I often use Phonetic First Name and Phonetic Last Name for Japanese names because even native speakers often need pronunciation cues,[1] particularly for given names. You’ll be forgiven a first mistaken reading, but you really need a pronunciation guide to prevent future problems. Japanese businesses have fields in contact forms for phonetic transcriptions of both names and addresses, and people with uncommon readings for their names usually include furigana on their business cards.

I wrote a support email to Agile Tortoise (i.e.: Greg Pierce) basically saying that he’d made something great, but hoping that he’d implement support for those fields[2] in a future update. It makes sense for a developer to address the majority use case before looking at fringe ones like my bilingual operating environment, but lo and behold the change notes for Interact 1.0.1:

  • Change: Scratchpad tag helpers now insert tag at beginning of current line if no text is selected.
  • New: phoneticFirst and phoneticLast scratchpad tags.

(Bolding mine.)

The change I was hoping for someday, maybe: it’s on the second line of the first point-update. I wrote that email only about four days ago. This is a developer who absolutely responds to user requests. Buy some of his apps!

Even without TextExpander snippets for tagging fields, I’d be able to add a contact much, much more quickly and easily than I could with the built-in Contacts app. With TextExpander, I can add a contact in seconds. I have a few times a year where I need to add several contacts in quick succession, sometimes in the person’s presence, so this isn’t just a nice convenience for me, it’s a huge productivity booster. Especially impressive; Interact correctly identified the elements of a Japanese address, even though English is the only language claimed to be supported. It needs help with the names, but that’s a very quick select-and-tap tagging process.

Interact’s implementation of groups makes it possible to actually use groups on iOS. Previously, through the Contacts app, a group was useful only to give you a shorter list to choose from, but was basically useless otherwise. I will almost certainly be using groups more in the future, whereas I almost completely ignored them before.

  1. I’ve had reception duties where we’re dealing with literally hundreds of people. Many family names are quite common, but you can easily guess the wrong reading even for simple kanji. For example, 長田 is usually read Nagata, but could be Osada. It is literally impossible to guess the right reading 100% of the time when there might be several possible name readings for a particular set of characters.  ↩

  2. The Phonetic First / Last fields are actually in the spec for the address book, but are not in the standard set of entry fields displayed when the language environment is English — they are shown by default in Japanese. You can go to the “add field” section of the Contacts app in Edit mode when adding or editing a contact in English to activate them, but you can’t change settings to have them on by default, which is a bit of a pain in the ass if you’re adding more than one contact at a time.  ↩