September 2019

I had the fun of interviewing old friend Daniel Jalkut on the latest episode of The Omni Show.

NetNewsWire 5.0.1 is almost entirely a bug-fix release — see the release notes for the full scoop.

It includes one sort-of new feature: there’s now a checkbox in Preferences for turning off the unread count in the Dock. (It was a hidden pref — now it’s visible.)

Status

Here’s what else we’re working on:

• iOS/iPadOS app
• NetNewsWire 5.0.2 for Mac — which will mainly be about performance (yes, we can make it even faster)
• NetNewsWire 5.1 for Mac — tentative feature list includes content extraction and at least one more syncing option (but we might change our minds on these: anything can happen between now and then)

We might also distribute NetNewsWire 5.0.2 for Mac on the Mac App Store. No guarantees yet, of course, but work is happening in that direction. This goes to our goal of getting as many people as possible using RSS readers.

Had to get a new key fob at work today — my old one wore out. Just a couple weeks shy of my fifth anniversary at Omni! Time flies.

I figure I’m just over eight years from retiring, so I’m not even halfway done here. :)

People have been asking me about supporting iCloud as a sync method for NetNewsWire.

It would be really cool because:

• There’s no sign-in
• It’s free — no need to spend money on another service
• It would help broaden the pool of people using RSS, since there would be no additional expense or service they’d need — they could just get going

It’s a great idea — no question. Given that my goal is to get as many people as possible using RSS, this makes total sense.

Why we didn’t ship with this feature

For the first release — I still think of it as a 1.0, because it really is — our best bet was to appeal to people already using an existing RSS service. We know that those people like and use RSS, and they’re the people most likely to check out a new RSS app.

(We could have delayed and shipped with support for more existing services, but we figured one was enough to get started with, and we could add other services later. And we are.)

In other words, we tried to make an app that the existing market would like. And that’s the right call when you’re starting out.

Also: iCloud sync makes the most sense when you have both a Mac and an iOS app, and we don’t — the iOS app is still in progress. We totally expect people to use NetNewsWire on the Mac and Unread or Reeder on their iPhone and iPad — and iCloud sync won’t work across apps. This scenario requires using services such as Feedbin.

Why I have no idea when this feature might appear

For any existing RSS service, we can be confident that our effort to support it in NetNewsWire would be successful. This is well-trodden ground: we make some web API calls, integrate with our database, and done. It’s not nothing, but conceptually it’s simple and there’s no cause to worry about technical issues.

But iCloud syncing will mean writing exploratory code and only then finding out if it’s going to work.

Syncing the feeds list should be relatively easy — the real issue is with syncing read/unread/starred states of articles. That means a lot of small records.

Is CloudKit up to this? What are the limits? How fast is it? How reliable?

We just don’t know.

Yes, it’s encouraging that News Explorer has this feature — but that doesn’t tell us much about the limits, reliability, and performance.

Working on this is a risk.

So — as you can imagine — we’re still more keen on supporting existing RSS services, because we know there are plenty of people who for-sure like RSS, and who might like NetNewsWire, but who won’t switch their syncing system just to use NetNewsWire.

That said: I do think we’ll get around to trying this, and I’ll be super-pleased if it works, because it really is a great idea — but we have a bunch of other work to do first. (Including the iOS app!)

Markos Charatzas writes about his excitement in joining the Apple developer world in 2009 to his eventual disillusionment today.

A number of people have asked that NetNewsWire show the full web page — right there, in the app — after clicking a link.

The idea is pretty good! It solves two big problems:

• You get full content, which is great when a feed contains only summaries or truncated articles
• You don’t have to switch to another app: you can stay right where you are

You’d think it’s a no-brainer, and we should just go ahead. But there are other considerations.

One big one is that your ad blockers and privacy extensions won’t run. They work in Safari, but they do not extend to other apps that use WebKit. This means that viewing a web page in NetNewsWire would be less secure and more annoying than viewing the same page in Safari (or whatever your browser is).

This points to one of my design principles: the app should have boundaries. Some features belong in the app, and some features are best left to apps that do that feature way better than NetNewsWire could. One of those things is showing web pages — that’s really a web browser feature.

Having boundaries means we can concentrate on doing a great job at the things that do belong in the app.

(Before you mention SFSafariViewController, recall that it’s iOS-only.)

What about the glory days?

“But Brent! In NetNewsWire 2.0 you added a tabbed browser to NetNewsWire, and it was awesome and a hugely popular feature!”

It was! But times have changed. Many websites are hostile these days. In 2005, this feature was fine — but these days it’s totally not.

A winged messenger arrives with a solution

There is a solution to the problem of showing full content and not leaving the app, and it’s a feature that really does belong in an RSS reader: using content extraction to grab the article from the original page.

If you’ve ever used Safari’s Reader view, then you know what I’m talking about. The idea is that NetNewsWire would do something very much like the Reader view (but inline, in the article pane), that grabs the content and formats it nicely, without all the extra junk that is not the article you want to read.

There are a number of open source options for this. We’re looking at using Feedbin’s content extraction service (which wouldn’t require you to have a Feedbin account).

The generous folks at Feedbin are running a copy of the open-source Mercury Parser, and they’ve offered to open this service up to RSS readers like NetNewsWire. (Reeder uses it already, for instance.)

When?

Right now we’re working on NetNewsWire 5.0.1, which is (almost entirely) a bug-fix release. I don’t know what’s going to be in 5.1 yet — we’re still digesting all the feedback, looking at our original roadmap, and thinking about things.

We’re also working on NetNewsWire for iOS! We’re busy.

But this is definitely the kind of feature that should come sooner rather than later.

John Gruber has mentioned, on The Talk Show, that I’ve got some weird ideas about what beta means.

Here are my definitions:

development (d): everything is in progress and the app might be completely unusable.

alpha (a): the app is feature-complete and has no known bugs — but, importantly, it’s had very little testing.

beta (b): the app is feature-complete, has no known bugs, and has been tested — but further testing is still warranted. Every beta is a release candidate.

These are defined in a NetNewsWire Technote. It’s important to have definitions that everybody working on or testing the app understands.

But why these rather strict definitions?

It’s part of our commitment to quality. What matters is the end result — the shipping app — and these definitions make sure we don’t get to beta, or even alpha, with the app up on the table with wires sticking out and pieces missing.

This gives us a big space between development and shipping, and that space is all about making sure the bugs are all fixed.

This is a matter of ethics and pride in our work. Absolutely.

But it’s also pragmatic. This is an open source app, written by volunteers in their spare time, and having this rhythm baked-in to the process helps make sure we can uphold our standards even without full-time developers, managers, and testers.

* * *

And… it bugs me how little real attention our industry pays to quality these days. In some cases the consequences are disastrous; in other cases they’re merely expensive. It doesn’t have to be this way.

If it seems like I’m going too far with my definitions, well, I’m trying to bend the stick here.