OK, I know I said I wasn’t particularly going to be supporting the Subscribe to Feed Safari extension I released last week, but it so happens I got a lot of great feedback and even some anonymous code contributions to help beef up the behavior of the plugin.

If you already have 1.0b3 or later installed, you can just check for updates in Safari’s extension preferences. Otherwise, download directly by clicking the name below:

Subscribe to Feed 1.0b4

• New toolbar icon with Retina display support
• Support for multiple feeds on a page, selectable from a popup menu
• Convert from http:// to feed:// for faster, streamlined subscription process
• Expand the list of MIME types recognized as valid feeds to cover edge cases

Hope you enjoy these fixes and enhancements. Let me know if there are other glaringly missing features or bugs.

Mac OS X’s centralized Address Book empowers developers to offer users features that go above and beyond what would be possible in the absence of such a resource. For example, an envelope-printing utility on Mac OS X doesn’t need to demand that you painstakingly type in the name and address of your friend before mailing a letter, you can search for them and automatically select from a list of matching addresses. It’s magic, it just works, and it makes a Mac a Mac.

Many other examples of Mac software just working are also based in accessing the Address Book, but instead of needing access to the whole thing, it’s just the “Me” card that is of interest. This is very useful for example if a map app wants to offer you easy directions home. A very common use case for accessing the “Me” card is when an application has good reason to pre-populate personal fields in an inquiry form of some kind: for example, a feedback or crash reporter dialog. In this case, putting the user’s email address in the field for them saves a step and prevents a possible typo.

Starting in Mountain Lion 10.8, Apple has dramatically increased security protections around the contents of users’ Address Book data. On the face of it, this is a good thing, as it protects against applications that either surreptitiously or stupidly access and upload the contents of address books to web servers without permission. The flip side is that fairly innocuous requests for the “Me” card are now met with a foreboding dialog:

Yikes! What is Red Sweater Crash Reporter and why does it want my contacts!? Sounds fishy. In fact, all it wants is the “Me” card, but there’s no way for it to let the user know this. Or is there?

Thanks to Cabel Sasser’s tweet today, I learned that there is in fact a way to express intent, albeit with a very crude mechanism. You can’t specify intent on a call-by-call basis, but you can publish in your application’s Info.plist a single string that will be conveyed to the user as an explanation for your need of Address Book data. The key is NSContactsUsageDescription, and it’s very lightly documented in Apple’s Info Property List Key Reference:

NSContactsUsageDescription (String – OS X). This key contains the localizable description of the reason why an app is requesting access to the user’s contacts information in the Address Book database.

It would be far preferable if there were an API mechanism through which an app could request specific content from the Address Book, along with a dynamically stated explanation. But this is better than nothing. Tweaking my crash reporter’s Info.plist, I end up with this:

Incidentally, if you’re a developer trying to add this to your own app, you’ll find it frustrating that the nature of this dialog provides you only one chance to get the terminology right. As soon as you click “OK” or “Don’t Allow”, that’s the last time you’ll ever see this dialog. Unless you happen to know about this magic little command line incantation (thanks to Jim Correia for reminding me):

% tccutil reset AddressBook

That clears out all permissions for your Address Book access, causing the panel to appear again the next time any app, including yours, tries to access contacts.

Before Mountain Lion 10.8 shipped, I had received reports from one customer that MarsEdit was crashing each and every time he attempted to access the network. For an app like MarsEdit whose entire raison d’être is to access the network, this is quite an unfortunate obstacle.

The public release of Mountain Lion has only confirmed that the problem, while rare, is significantly wide spread that I’m sure it affects at least dozens of my customers, hundreds of the customers of my colleagues, and probably thousands of Mac users worldwide.

The tell-tale sign of this crash is it occurs only as the app attempts to connect to some network resource, and the crashing thread always culminates in some stack trace involving CoreSchedulingSet or EmptyCoreSchedulingSet C++ objects.

Here’s one example, with just the crashing thread a few stack frames deep:

Thread 1 Crashed:: Dispatch queue: com.apple.root.default-priority
0  com.apple.CFNetwork              0x00007fff8d26cc92 CoreSchedulingSet::
			copyWithUpdatesReleaseSelf(CoreSchedulingSet
			const*, CoreSchedulingSet const*) const + 104
1  com.apple.CFNetwork              0x00007fff8d26c995
			CoreSchedulingSet::copyWithAdditionReleaseSelf(__CFRunLoop*,
				__CFString const*) const + 71
2  com.apple.CFNetwork              0x00007fff8d2cfac6
			__executionContextSchedule_block_invoke_0 + 44

And another, where the non-main thread crashes in an EmptyCoreSchedulingSet destructor:

Thread 3 Crashed:: Dispatch queue: com.apple.root.default-priority
0  libsystem_kernel.dylib            0x00007fff8d089212 __pthread_kill + 10
1  libsystem_c.dylib                0x00007fff913b2b34 pthread_kill + 90
2  libsystem_c.dylib                0x00007fff913f6dfa abort + 143
3  com.apple.CFNetwork              0x00007fff8fd8c928
			EmptyCoreSchedulingSet::~EmptyCoreSchedulingSet() + 60

Google searches, and some chat I’ve seen on Twitter, suggests the problem is certainly not limited to MarsEdit. Even Safari is vulnerable to these crashes in the affected configurations.

So what are the affected configurations? I’m not sure. Anecdotally, it seems like you’re more likely to see the problem if you are connecting in an institutional network such as a school or a large company. One customer also mentioned that he crashes when connecting through the Thunderbolt ethernet adaptor, but is able to connect without issue through the WiFi interface for his Mac.

I am posting this here in an attempt to document the known symptoms and scenarios for this crash, in case it helps other developers and customers who run into the issue.

I hope that Apple will issue a fix for this in 10.8.1, if not sooner. It sounds like this is affecting an awful lot of customers and as far as I know there is no workaround, short of changing the circumstances of how you are connecting to the internet by using a different interface or moving to a different location.

Update: I am now convinced by putting the pieces together and correlating my experiences with those of folks including the support crew at Agile Bits, that this is issue is related specifically to the “Auto Proxy Discovery” and “Automatic Proxy Configuration” settings in Network preferences. If you have one of these options checked, you are very likely to crash in MarsEdit, Safari, Tweetbot, and any number of other apps that rely on Apple’s networking libraries.

I recommend turning off the Auto Proxy Discovery and Automatic Proxy Configuration features in 10.8 unless you are on a network where using them is strictly required.

Click here for detailed instructions.

In light of the apparent link to a commonly used proxy configuration, and the growing number of apps confirmed as affected by this issue, I am hopeful that we’ll see a fix from Apple sooner than later.

Instapaper developer Marco Arment responded to the latest installment of John Siracusa’s famously elaborate Mac OS X reviews with an amusing, fairly elaborate review of the review itself. Each is worth reading, or at a minimum, each is worth reading later.

Siracusa’s article is particularly suitable to archiving for later perusal, as it clocks in at a whopping 24 “web pages.” Arment estimated it took him around two hours to read. Given my busy schedule and poor attention span, I suspect this will be split up into several shifts, reading a little bit when I get the chance.

Multi-page articles used to be a bugaboo for Instapaper. Faced with an article like Siracusa’s, it would happily save it to your reading list, but when you sat down to dig into the story, you’d be vexed to find you were stuck with only the first of 24 pages. Happily, in March of this year, the Instapaper bookmarklet was updated to support multi-page archival.

I have an Instapaper keyboard shortcut wired up, so when I’m looking at a page I want to read later, I just press control-p, and up comes Instapaper’s friendly “Saving” panel. When it’s saving a multi-page article, it updates the UI while it cranks through the pages.

I pressed the keyboard shortcut on Siracusa’s article, and settled in for a relatively long Instapapering lull. To my surprise, the save panel appeared and disappeared almost instantly. Uh oh, has Marco screwed up multi-page archiving for a canonical example of its usefulness? On an article that he himself has drawn additional attention to?

Nope. All the pages are there. I confirmed through Instapapaper that the complete, gloriously long article would be waiting for me on my subway ride later this morning. Kudos to Instapaper!

But how did it happen so quickly? Does Marco special-case certain popular pages like this in an effort to boost perceived performance? Or perhaps one of the subtle improvements over the years has been some kind of automatic server-side de-duping of archives. This would save Marco a bunch of space on his servers while also improving performance for users.

Archiving Advice

However Instapaper did it, archiving John Siracusa’s review of Mountain Lion 10.8 with Instapaper was, ahem, instant and complete. Would archive again.