Medium Permalinks

I was intrigued to read that Basecamp’s (née 37 Signals) Signal v. Noise blog has moved to Medium. David Heinemeier Hansson argues that Medium is “just the right mix of flexibility and constraint,” celebrating its web-based editor, the network of users, Medium’s demonstration of concern for its customers, and Basecamp’s admirable desire to get out of the business of maintaining their own blog-hosting software.

Hansson lists the ability to use one’s own custom domain among the user-friendly changes Medium has made. “By offering custom domains, we’re ensured that no permalink ever has to break, even if we leave the platform.” Indeed, this is a valuable improvement. But it got me thinking: for a blog like Signal v. Noise, with hundreds of posts spanning more than a decade, how would Signal v. Noise’s existing permalinks be preserved? Does Medium offer some fancy permalink customization for imported posts? Is there some ability to upload static HTML content to reside alongside newer, Medium-native posts? Surely a company as obsessed with the web as Basecamp would be concerned about this. How did they solve it?

It took a little poking around and scratching my head to realize that solved the problem in a novel way that doesn’t exactly get them out of the blog-hosting business. Signal v. Noise is now hosted on two domains:

  1. – The previous home of the blog, hosted and managed by Basecamp themselves, continues to host the backlog of archived posts.
  2. – The new home, hosted by Medium.

So when any new Medium post is linked, it points directly to the “”, and is handled by Medium. When any older post is linked, it goes directly to “” and is handled the same as ever. The one change? When the main page at is visited, it redirects with a “302 Found” response to the Medium site, getting a casual visitor on track to viewing only the latest posts.

I continue to admire a lot of the work Medium is doing. I agree with the Basecamp that their web editor is among the best I’ve used. For my tastes, it can’t touch the experience of a native Mac app, but of course I’m biased. Hopefully Medium’s API will continue to evolve and make Medium a more viable platform for folks who share my preference for a desktop editor.

Hey Siri, Don’t Trivialize My Timer

Siri’s dictated timers are a feature I use all the time. Especially given my propensity to be distracted and lose track of short-term time commitments, the ability to blurt out in the kitchen: “Hey Siri, set a timer for one minute,” has saved many a pancake from being burned.

Something that has bothered me about this feature for a long time is the determination Siri has to be lighthearted and downright goofy when creating the timer, when the timer is for a specific time such as one or three minutes.

“Hey Siri, set a timer for three minutes.”

Siri's visual response when asked to set a three-minute timer.

Ha. Ha. Yeah, I’m always cooking an egg when I set a three-minute timer. By contrast, a request to set a two-minute timer is always met with a curt, yet still humanized, “Two minutes and counting.” If you set a timer for one minute? Whoo-ee, you’re in for some sass. Sometimes Siri just says “Your timer is set for one minute,” but more often you’ll hear a quip like “Remember, a watched iPhone never boils.”

I’ve been more irritated by this cuteness after years of using the feature and, I suppose, the frequency with which I set one and three-minute timers. It’s mostly a passing exasperation for me, but it strikes me as an example where emotionally charging a software interaction is a risky proposition.

My one-minute timers are usually for something trivial like pancakes, but what if I were using them in a more fraught scenario? What if one-minute timers play a serious role in the administration of care to a loved one? What if it’s a key interval in a CPR procedure? One of Siri’s cute quips is “The suspense is killing me.” What if the suspense really is killing somebody?

(Radar #23776483)

Siri’s Headphone Tax

I wrote earlier today about Siri’s impressive, instant attentiveness on the iPhone 6s. I remarked that although I had set out to report a bug to Apple, I discovered it was actually a very awesome feature.

Unfortunately, I still have a Siri-related bug to file today. Armed with my knowledge that, as a rule, Siri will begin processing instructions at the moment the home button is pressed, I have been exercising it quite a bit. But after I popped on some headphones and headed out for a walk, I discovered an unfortunate shortcoming: Siri’s instant attentiveness is thwarted by the presence of headphones.

For some reason, if headphones are plugged in, iOS goes through the old-and-busted delay in which you must wait for the audible signal that Siri is ready to listen. The result is that, having gotten used to it being instantly ready, you will push the home button and start talking, only to hear the tell-tale audio signal and realize that it hasn’t actually been listening yet.

I’m hoping this is a bug in which the old mechanism is simply being inappropriately activated while headphones are plugged in. I don’t think there’s anything about activating the audio out through headphones that should inherently limit Siri’s ability to be instantly attentive. In fact, with headphones plugged in I can still get an instant response when I use “Hey Siri” to precede my request.

In summary: Siri starts listening instantaneously on an iPhone 6s, whether you’re in silent or non-silent modes, provides you haven’t made the mistake of plugging in headphones. Filed as Radar #22881933

If It Ain’t Fixed, Break It

I have always kept my phone on silent, and thus come to depend on vibration feedback for a lot of workflow tasks. One such task is invoking Siri by holding the home button, to make a quick inquiry or request.

On my iPhone 6, long-pressing the home button always resulted in a short pause before a pleasant vibration indicating that Siri was ready to listen. I trained myself to wait until that vibration was felt before bothering to speak, lest Siri miss anything important.

On my iPhone 6s, however, there is no such feedback. Apple “broke” it. I was all in a huff this morning to file a bug about this, sure in my knowledge that the usability of the phone had been diminished by removing this feedback. Every time I invoke Siri now, in the absence of vibration feedback, I wait to see the tell-tale animated sound wave detector. I’m never quite sure when Siri is ready for me.

I complained on Twitter about the problem, hoping there was a secret setting that I had missed when restoring my phone. I got lots of commiseration from folks who also miss the feedback, and assurances from others that I simply needed to set my “vibrate on ring” or “vibrate on silent” settings correctly. I appreciate the responses, but they were all wrong. And I’m wrong. We’re all wrong.

Apple “broke” the haptic feedback associated with invoking Siri, by “fixing” the problem that there had ever been any latency before. Have an iPhone 6s or 6s Plus? Go ahead, I dare you: hold down the home button and start talking to Siri. You will not escape its attention. It’s ready to go when you are, so it would be obnoxious of it to impose any contrived delay or to give taptic feedback that is uncalled for. Siri has become a more perfect assistant, and we have to change our habits to accommodate this.

The elimination of latency in Siri’s attentiveness seems related to the fact that Apple have added dedicated functionality to the phone’s M9 chip to allow Siri to remain efficiently at attention:

The integrated M9 works so efficiently and intelligently that Siri is always on and waiting for your voice commands. You can easily activate Siri by saying “Hey Siri” whenever your iPhone 6s is nearby.

The lesson is that sometimes our instinct tells us something has been terribly broken, when it has actually been gloriously fixed. Now you can quickly dictate “Hey Siri remind me to file a bug about Siri feedback,” before quickly amending yourself: “Hey Siri delete the reminder,” and dismiss any perceived obligation you felt to tell Apple just how “buggy” the iPhone is.

Familiar Spell Checking

Even if you’re a great speller, automatic spell checking provides a valuable safety net, often preventing us from sharing with the world our own individual ignorances of the languages we communicate with.

For years, spell checkers of all kinds have relied upon word databases to determine that a word has been misspelled. I’m sure it’s at least a little bit more complicated than this, but in a nutshell: if the word you’ve just typed is not in this enormous list of words, then it’s probably a misspelling, and is marked as such.

Thus as you type your master works, when you either flub your typing or can’t recall the correct spelling, most modern editors will flag the word in question, for example by showing a red squiggle below it.

One challenge, though, is that for any individual, a number of words that are spelled correctly may nonetheless be absent from spell checker’s enormous database. One great example of this is the variety of proper names we deal in that may not happen to be included. For example, if I were a Boston Red Sox fan I might type Dustin Pedroia’s name often, and at least OS X’s built-in spell checker would mark it as incorrect. The workaround for these situations is to control-click the word and, from the popup menu, select “Learn Spelling” to avoid future flagging of the item.

The problem can be especially annoying when the OS repeatedly flags the names of people in your own family. For example, my own last name, “Jalkut,” is incredibly uncommon and would be flagged as a misspelling by most spell checkers in the world. However, on my Mac it is not, even though I’ve never asked the system to “learn” the spelling. In fact, none of the names of my family, friends, or business associates are marked as misspellings. How does this work?

Apple’s engineers realized that they could spare you the hassle of “learning” these spellings, since they already have access to a massive database of proper names that matter to you. Your Contacts database. If you’re on a Mac right now, open up the Terminal application and paste in the following line:


The result that should come flying down the terminal window are the proper names of everybody and everything in your Contacts database. Specifically, Apple consults every entry in your database for the following attributes:

  • First Name
  • Middle Name
  • Last Name
  • Nickname
  • Maiden Name
  • Organization
  • Address
  • City

Each of these words, if present, is used to augment the already-massive list of correctly spelled words. So if you happen to know somebody named Frenk Xssl, who lives in Cwmystwyth and works for Infinitea, you can write all about them and their work, and never be bothered once by the tell-tale red squiggle of a word misspelled.

Everything But The Web

Since Apple announced the new Apple TV on Wednesday, we developers have been poring over the details of what the SDK will, and what it won’t allow us to achieve on the platform.

One of the most surprising, and most impactful limitations to the SDK is that it provides no facility for presenting web content in an app. Not only is there no built-in “browser” on the Apple TV, third party apps are unlikely to be able to offer any web browsing functionality.

This is a big deal, but many people see it as a wise choice on Apple’s part: by forbidding the use of web technologies, they will encourage app developers to design natively for Apple TV. On iOS, by comparison, a large number of “native apps” that are downloaded from the App Store are in fact only thin wrappers around web content. These offer the same interactive experience that a user would have if they navigated to the company’s site in a browser. Forbidding web views on Apple TV all but guarantees that developers will provide a more tailored experience, designed in the spirit of Apple’s guidelines.

But forbidding web content outright will also be an unnecessary impediment to many developers whose apps are either tastefully implemented with the help of web technologies, or whose core functionality is to deliver content — not web sites, mind you — that happens to be formatted with HTML. Daniel Pasco of Black Pixel points out that his company’s NetNewsWire, an RSS news reader, falls squarely into this category. On that point, although I have a hard time imagining the utility of a blog editor on Apple TV, my own MarsEdit would also be “unfairly” restricted by this policy.

As Pasco acknowledges, we don’t know Apple’s real motivation for omitting web views from Apple TV. There may be technical challenges or performance shortcomings that contributed to the decision. But let’s assume for the sake of reasoning that it is purely political, that they want to discourage “web wrappers” and to promote a more native look and feel in TV apps. I propose that Apple could strike a compromise that would serve those ambitions while also supporting the tasteful handling of web content in apps. How? By forbidding network access to web content. Apps themselves could still access the network, but not from within their web views.

Blocking network access from web content would immediately knock out the “web wrapper” type of native app. Any such app that connects to a site meant to also serve regular web browsers will be rendered useless if the referenced resources from the site are not allowed to load. Images would be blank, stylesheets omitted, etc. A clever developer might try to overcome these limitations by taking all network loading into their own hands, but I expect this would be a complicated mess and quickly encourage such a developer to seek a less cumbersome solution.

On the other hand, all apps that use web content tastefully would be liberated to continue doing so. Whether an app simply uses a small web view here or there to support the native UI with styled text and images, or if it is a full-fledged news reader like NetNewsWire, the ability to capitalize on WebKit’s core functionality to convert web content into a visual format should be no more controversial or politically limited than the ability to process TIFFs, JPEGs, and PNGs and turn them into attractive, or not so attractive, visuals in an app’s interface.

I’m not sure where JavaScript support should stand in this “compromise.” It would be somewhat ironic to omit it, seeing as the Apple TV supports a whole framework for creating apps that is based in JavaScript, but I can also see an argument that supporting JavaScript in web views is too much of a lure away from using native iOS technologies. Personally, I think they should include it and let developers decide whether there are suitable use cases for it, but I imagine the vast majority of current iOS developers would be extremely satisfied to be granted the mere ability to render static HTML content in their Apple TV apps.

I’m excited about the Apple TV even if, like many developers, I haven’t quite wrapped my head around what I could or should develop for the platform. These major announcements from Apple always come with a healthy mix of tantalizing allure for the possible, and sobering reminders that Apple defines the constraints in which we must operate. The lack of web views on Apple TV was not a constraint I imagine most developers were anticipating. I hope that it does achieve the laudable goal of encouraging more developers to embrace native designs, but I also hope that Apple loosens up and finds a way to allow responsible developers to use a powerful set of technologies that we’ve grown accustomed to relying upon.


Today I faced a long list of alarms on my iPhone, and decided that I wanted to clean them out. The typical iOS “Edit” interface puts a red “delete” button next to each item, and upon tapping it you must then confirm it by tapping the explicit word “delete” at the other end of the item. Suffice to say: for a list of any significant size, this is very tedious.

On a whim, I decided to give Siri a shot at simplifying the process. I long-pressed the home button, and uttered: “delete all my alarms.”


Well, isn’t that nice?

I realize that when I am faced with a problem on iOS or watchOS, for which I wish there were an automated, “power user” mechanism to simplify it, I reach for Siri and hope for the best.

In this respect Siri fills the gap that is left by the omission of an automating service such as AppleScript. On a Mac, when I’m faced with a problem like this, I look to Script Editor, and hope that the app is scriptable enough to get the job done. For example, if alarms were a service provided by my Mac (and why aren’t they!?), then I would expect a script like this to complete the task at hand:

tell application "Clock" to delete all alarms

Having AppleScript at my disposal is great, but I am also frustrated that Siri doesn’t live on my Mac. I should be able to invoke the dictation UI (fn-fn keystroke, by default) and ask Siri to “add to my reminders,” or to perform any of the other common tasks I can perform with my phone or watch.

Siri is more limiting than AppleScript, because it can only carry out tasks that Apple’s engineers have predicted that I will want to perform. But it’s also much easier than opening up Script Editor, scrutinizing a scripting dictionary, spending 10 years learning AppleScript, and then writing and running a script.

Ideally, I’d like to have the best of both worlds: the ease of asking Siri to perform complex procedures and the option of extending the catalog of procedures that it knows how to perform. And I’d like this perfect combination of ease and extensibility on all of Apple’s platforms.

Since the debut of the iPhone, people have speculated about whether we would ever see an official solution for automation, along the lines of AppleScript or Automator. I think we’ve actually been seeing it since Apple acquired and integrated Siri. I hope that one day this will culminate into the consistent, extensible solution for automation that I have imagined here.

Surviving The Work Week At Home

I was honored when Serenity Caldwell of iMore asked me to contribute a column to The Network. I was racking my brain to come up with a topic for the article, but I found inspiration in my MarsEdit drafts folder, with an article I had loosely speculated writing, but never followed up on. The article went live at iMore today: “How to survive working at home“.

My working title for the article was “Surviving the Work Week at Home,” but they changed it at iMore, probably for the better! I’m a sucker for the passive voice.

The staff at iMore also added helpful headings, and restructured paragraphs where I had simply rambled on. I love the freedom of writing fast and loose for my own blogs, but it’s a nice break to collaborate with a publication that will add the finishing touches to one’s writing to bring it to a higher level.

Thanks to Serenity and the entire team at iMore for helping me get my article polished up, and for sharing it with your audience!

Microsoft WinObjC

Microsoft appears to be following through on its promise to provide resources to iOS developers that facilitate the porting of apps to Windows.

The project, identified by the code name “Islandwood” earlier this year, has been renamed to Windows Bridge for iOS, and the company is making the source code available.

I had a surprisingly hard time finding the GitHub sources for the project. No news on Microsoft’s developer home page, nor on the Interoperability Bridges blog (oops, not updated since January, 2014). I even searched Microsoft’s GitHub repositories but couldn’t find anything matching “windows bridge ios” or variations.

Finally, I searched Twitter for related news until I found a link to a story that actually linked to the GitHub project.

The project’s famiilar name is WinObjC. And yes, it is on GitHub.

Update: If I knew The Verge’s format a bit better I might have noticed they credit the source, Microsoft’s own Windows blog, which in fact links to the GitHub project and includes the WinObjC.

Six In One

Craig Hockenberry’s “Half-Assed” calls out the disparity between Apple’s Mac and iOS App Stores with respect to app analytics, limiting customer reviews from beta OS releases, and support for beta testing with TestFlight:

Mac developers have never had access to TestFlight, either internally or externally. It’s “coming soon”, and until that day comes, there’s no way to test apps that use the iCloud servers. Which sucks for both the developer and the customer.

For years, I’ve harbored my own resentments about the way Apple seems to treat the Mac App Store as a second-class citizen. One point that has nagged at me since the Mac App Store launched five years ago is the lack of effort Apple makes in promoting these products through social networks. For years, the @AppStore account has been extremely active promoting iOS apps to its huge (now 3.8 Million people!) audience. It’s obviously a priority for Apple to promote the iOS App Store, and their Twitter account does a great job of it.

But there is no Twitter account for the Mac App Store, and the @AppStore account has nearly never mentioned Mac software. (Go ahead, do an advanced Twitter search for “from:AppStore mac“). Around four years ago at WWDC, I asked a group of App Store affiliated engineers what they made of this. They all looked at me blankly, paused, looked at each other blankly, paused, and then shrugged as if to say “Huh, I wonder why we don’t promote the Mac App Store?” I don’t know either! But they were all in a much better position than I to find out or push for a change. Evidently, that hasn’t happened.

The neglect makes sense on one hand: iOS and now watchOS are the new hotness, the platforms that represent the fastest and most culturally significant growth for Apple. They sell the most devices, generate the most revenue, and create the biggest headlines, worldwide. It still makes sense for Apple to prioritize the iOS App Store, but it’s a shame they haven’t done more over the past five years to integrate the systems that power the stores so that benefits to developers for one platform’s store would automatically benefit the developers for the other.

On the other hand, let’s acknowledge that the disparity is not all roses for iOS and weeds for the Mac. iOS developers continue to face obstacles for which we have long enjoyed simple solutions for on the Mac. As Craig points out, we can’t ship a useful beta testing app that fully exercises all of Apple’s locked down services such as iCloud, but what can we do? We can ship arbitrary binaries to an unlimited number of people, who can install and run those apps on whatever devices they choose. How do you like them, ahem, Apples?

And what about the absurd steps iOS developers must take in order to stay up to date with beta releases of the OS? Either they commit themselves to running guaranteed buggy and possibly unusable versions of the OS on their machine “machines,” or else they spend extra money on devices whose only purpose will be to act as testbeds for the risky new OS. Want to maintain backwards compatibility? Better keep multiple iPhones, iPod touches, and iPads, of varying generations handy, but be careful not to update them to a newer OS, as there’s no going back.

On the Mac, we enjoy the ability to erase and reinstall whatever version of the OS we choose, whenever we choose. Furthermore, we can maintain parallel installations of the same or different versions of the OS, on easily switchable partitions of the same disk. Even in the context of a single OS install, we enjoy the ability to test varying user scenarios by configuring test accounts and “Fast-User Switching” between them from the comfort of our Mac’s menu bar. Heck, we can even virtualize whole Macs thanks to VMware, Parallels and VirtualBox. When it comes to testing various configurations affordably and expeditiously, it’s the iOS developers who should be crying to Apple that their priorities are skewed.

I guess it’s lucky the Mac was around for so many years before the dawn of iOS, it’s had time to accumulate many developer-empowering features. Although Apple’s priorities with respect to development resources and marketing seem to be focused on iOS today, we enjoy many privileges on the Mac that I doubt iOS developers will ever see. And to top this off with a bit of true optimism for the future: the weird thing is, Apple keeps improving OS X. I’m sometimes surprised by the amount of attention Apple continues to give to the OS given its apparent relative lack of importance. But I guess Apple is well and truly stocked with a bunch of Mac softies, after all.

There’s a ton of totally vexing behavior that seems to be ill-spirited towards Mac developers, but also a ton that seems to hold iOS developers in low regard. I think this speaks to the likely truth that Apple is, more than anything, under-staffed and not well situated to deploy solutions to both platforms in tandem. It truly is a case of six in one, a half-dozen in the other. But wouldn’t it be great if iOS and Mac developers could each enjoy the benefits of all twelve? I’ll hold out hope that one day Apple will unlock the secret of organizing their efforts so that developers on all their platforms can benefit more or less equally from the technologies the company provides.

Full Time Indie

My friend Manton Reece and I have been podcasting for more than seven years. Our show, Core Intuition, has always been dedicated to the topic of “indie” software development, particularly for the Mac and iOS platforms.

From the start, I have been a “full time indie,” in that I have held no regular job, while Manton has been a “part-time indie”: fully employed while also shipping a stunning quantity and variety of apps and web services. I guess I’m better at quitting jobs, while Manton is better at shipping new apps. But I’ve known for a long time that Manton aspired to go full-time, so for most of these past seven years I’ve nagged at him: “did you quit your job yet?”

Last week, he finally did.

Obviously I can’t fault him for taking so long. Going indie is a huge risk and, as countless others have testified, there is no guarantee of success. The App Store model provides an unprecedented opportunity to sell software easily, but the limitations enforced by Apple and the increasing expectation that software should be free or cheap make it less obvious how to eke out a living doing so.

Too many folks who strive to become full-time indies do it the dumb way: quitting their job first, hoping the sudden jolt will motivate them to come up with a successful strategy for earning a living. This undoubtedly works in some cases, but it’s tantamount to jumping out of a plane and hoping you just happen to be wearing a parachute, or that the ocean just happens to be 30 feet below.

Manton is approaching this the smarter way: jumping out of a plane, sure, but doing so equipped with a whole host of equipment. He’s spent the past seven years and more honing his skills with software development, while diversifying his income through his products, our podcast sponsorships, and our Cocoa job listings site. Given Manton’s stated plans to combine all of this with a bit of paid consulting work to bridge the gap, I’m confident he’ll make a smooth landing.

Many congratulations to Manton on the culmination of a long-sought-after and long-worked-at goal. I’m excited to see how things work out for him in the weeks, months, and years to come.