Now that Safari 6 is available as part of Mountain Lion 10.8, and as a software update for Lion, I can finally explain the rumblings I made months ago about an extension facilitating feed subscription directly from Safari.

The motivation behind my foray into Safari extension development was my early adoption of Safari 6 during the beta phase. I noticed they had removed the long-standing, built-in “RSS” button near the URL bar. This button makes it easy to subscribe to an RSS or Atom feed for a blog, or any other site that offers such a feed.

I’m disappointed by Apple’s decision to remove the button, but when life hands you lemons …

My beta-quality, more-or-less unsupported Subscribe to Feed extension adds a handy button to the toolbar that, when a page offers RSS or Atom feeds, can be clicked to easily open the feed:// link, which should automatically open your favorite news reader.

I hope this extension fills a void for those of you missing the beloved RSS button from Safari 5 and earlier.

Updates:

• Since I posted this on Wednesday (the day Mountain Lion 10.8 was released), the response has been overwhelming. I didn’t realize there would be so much interest in restoring the functionality of the Safari RSS button.

  The interest has been so strong that more than a couple people have installed the extension apparently unaware of its purpose. The gist of the extension is to make it easy to subscribe to RSS and Atom feeds in an external application, separate from Safari. For example, it will open in NetNewsWire, Reeder or any other application on your Mac that claims to support “feed:” style URLs.

  Some folks who are just getting in to desktop RSS readers are discovering they don’t have a “default app” setting on their Mac, and Apple no longer provides a simple UI inside Safari for setting the default. The best solution I know for this issue is to download and use the venerable RCDefaultApp to set a default RSS reader for your Mac.

• A number of users who use Google Reader through the browser would like it if there were a way for this extension to automatically subscribe in Google Reader instead of through a Mac client. I’m not sure exactly how this would work but I bet it’s possible with a preference in the extension that would offer the ability to open a Google Reader URL for subscribing. This is a little ambitious though, so if you want this feature and happen to be able to code Safari/JavaScript solutions, please send me a proof of concept for subscribing to Google Reader from JavaScript on a web page, and I’ll see if I can integrate it into the extension.
• On August 2, 2012, I released Subscribe to Feed 1.0b4, addressing a number of issues from the initial release.

MarsEdit has featured support for connecting to Tumblr blogs since February 27th, 2009. Since that time, it has always lacked a few features such as support for editing video and audio posts, but with the exception of some particularly flakey periods in Tumblr’s network availability, the feature has been solid, and appreciated by mutual customers of Tumblr and MarsEdit.

Earlier this week Tumblr quietly, and without warning, changed the behavior of the API that MarsEdit and countless other apps rely upon, removing the ability of clients to authenticate with a user’s username and password. In particular, when asking Tumblr to provide a list of posts stored on the server, authentication fails and an error code is returned in lieu of the requested posts. The result for users of MarsEdit is a never-ending string of requests for the username and password, and posts from the blog never appear in the app.

After learning of and researching the issue, I contacted Tumblr’s engineers with a message to the Tumblr API discussion group. I was heartened to receive a reply within minutes, from John Bunting of the Tumblr team, that they were looking into the issue. A few minutes later, it was clear that they understood the cause to be a policy change within Tumblr that was made on purpose.

The policy change is, in short, that user credentials may no longer be provided as part of the URL scheme in requesting assets for the blog. For example, a request to read draft posts on a Tumblr site might look like this:

http://myblog.tumblr.com/api/read?email=joe&example.com
			&password=123badpass&state=draft

Instead, the same authentication details should be provided in the body of the POST request. The security improvement here is modest: as the connection the API is not over HTTPS, the entire content of the POST request could be intercepted as easily as the URL for the request. However, my friend Mike Ash pointed out that there is some rationale for keeping sensitive data out of request URLs as they are more likely to be logged and kept around longer-term than the content of a request.

In the previously linked Tumblr API discussion, Tumblr proposed that clients such as MarsEdit should switch to providing authentication information in the body of the request, but offered that perhaps they could temporarily restore the “old behavior,” for perhaps two weeks, while developers update client apps to meet the new requirement.

First, two weeks is not a lot of time to adapt to a sudden change like this. Anybody who develops for the Mac or iOS App Stores knows that sometimes an app can sit in review for two weeks before it’s even considered for approval. Still, a grace period would be better than leaving all of my Tumblr-blogging customers in the lurch, so I immediately set out to adapt MarsEdit to work with the new requirements.

Here’s the rub: the new requirements don’t work, either. For the API call in question, the “/read” endpoint, none of the arguments, username and password included, are recognized by Tumblr from the body of the POST. As far as I can tell, parameters must be provided in the URL for the request, except Tumblr has now explicitly stopped respecting the username and password arguments.

In short: clients of the V1 Tumblr API are no longer able to read posts with authentication from the service. Since the early, attentive responses in the discussion group two days ago, there has been no further update. MarsEdit, and other clients of this API, are effectively broken until and unless Tumblr restores functionality of the API.

If you’re familiar with the Tumblr API, you may be wondering why I haven’t yet adopted the newer V2 API. It supports OAuth authentication which is certainly more secure than the scheme being used in V1. But when I looked into supporting it, I hit different hangups that would alter the behavior of MarsEdit and prevent me from supporting current features. For example, it appeared impossible to access “private” posts through the V2 version of the API. I wrote them about that, too, a year and a half ago, and never heard a reply.

As a developer who relies upon Tumblr’s API, there has been no shortage of frustrations over the years. Whether it be the reliability issues, the absence of certain important API calls, or sudden changes in behavior such as this. I’ll come out and say it: it’s damned frustrating to support Tumblr, and sometimes I wonder if I was a fool to ever try to do it.

If you use MarsEdit for Tumblr, you are undoubtedly frustrated by the recent collapse of support for the service. I’m frustrated, too. I’d like to say it’s all in my hands to fix things, but it isn’t that simple. I can make further concessions, removing features to adopt their V2 API. But doing that will take time, testing, and energy. With Tumblr, more energy than it should. It takes two to tango, and Tumblr doesn’t dance.

Update: A very helpful reader who has experience with the Tumblr API suggested that I should be able to adopt the OAuth authentication of the V2 API while continuing to use the V1 API (for features that aren’t supported on V2). This is a promising lead. It doesn’t diminish my frustration with Tumblr for yanking the rug out from under existing clients like this, but if it works as advertised, it does put the situation squarely back into the domain of “something I can solve on my own.”

Marco Arment quipped on Twitter that web designers need to take HiDPI displays seriously, and adapt their designs to look great on them.

If you’re a web designer, you really, really need to get a Retina MacBook Pro so you can see how bad your site looks on it and fix it.

— Marco Arment (@marcoarment) July 5, 2012

The short-sighted reactions he received revolve mostly around simple mathematical analysis: because HiDPI displays represent a relatively tiny percentage of all users, it is not worth a designer’s time to cater to that niche group.

I confess that after the iPad 3 was released, I paid little attention to adapting my site to support HiDPI. But when Apple announced the Retina MacBook Pro at WWDC, revamping all of my apps and my web site jumped to the top of my list of priorities. My apps are shaping up nicely. My site? Let’s just say it’s still on the top of my list.

Why? Because HiDPI customers may be a fringe group, but they are a forward-facing fringe. They represent the users of the future, and the more we cater to them now, the more deeply embedded our products and designs will be in their culture. The future culture. The same arguments apply to aggressively embracing newer web browsers standards, and the latest technologies in platform operating systems such as iOS and Mac OS X.

It doesn’t hurt that the forward fringe tends to be rich and influential, compared to other niche audiences. When some backward-compatibility quack notices that your site renders poorly on IE5, they may scream it from the rooftops, but it won’t make a serious dent in your sales or reputation.

In contrast, when a Retina early-adopter discovers how beautiful your site and software look on their fancy computer, they’ll be that much more likely to open their wallet again. When John Gruber or Jason Kottke happens upon your beautifully designed, HiDPI site, he’ll be that much more likely to spread the news about your forward-thinking design to their friends and readers.

Target the forward fringe.

I’m excited to share that the upcoming MarsEdit 3.5.5 will be revised with high-resolution graphics for optimal appearance on Apple’s new “Retina” line of MacBook Pro computers.

If you’re lucky enough to have one of the new notebooks, please try the new version as soon as possible. I’d like to iron out any residual issues in the app, and I’d like you to enjoy your new computer even more with a crystal clear version of MarsEdit.

Click to Download MarsEdit 3.5.5b4

If you don’t have a Retina-display Mac, feel free to download the beta. It won’t be too thrilling but if you happen to use VoiceOver assistive technologies, it does address a crash that folks have been seeing related to the Tags field.