inessential by Brent Simmons

November 2019

NetNewsWire Status: Progress Toward Shipping the iOS App

The team — we have a team! which you can join! — is continuing to work on several different things: NetNewsWire 5.0.4 for Mac, NetNewsWire 5.1 for Mac, and NetNewsWire 5.0 for iOS. We’re also figuring out what will go in subsequent releases.

The most attention has been going to the iOS app. We’ll be doing a public TestFlight beta as soon as it’s ready, which I’ll announce here and on the NetNewsWire blog. It’s getting close! A bunch of us have been using it every day for a while now.

In second place for attention is syncing with Feedly, which will appear in the iOS app and in NetNewsWire 5.1 for Mac. (We’re working on adding other services too, but it’s yet to be decided which ones will appear in which versions.)

No ETAs, of course — we’ll announce dates only when we know them for sure.

* * *

The design of the iOS app is what you’d expect, I hope. As NetNewsWire for Mac is so very much a Mac app, the iOS app is very much an iOS app.

Our design goals are the same as with the Mac app: make it stable, fast, clean, modern, and — most importantly — as obvious as possible, which helps make it easy to learn and use.

In other words, we did what we always do, which is to do the best job we can by using classic user interface design principles.

It definitely looks like an iOS 13 app. You can see its bones.

While I think it’s awesome, people who prefer something richer have other really great apps to choose from. We know NetNewsWire is not the only RSS reader, and we’re not trying to please everyone. Which is very freeing — it means we can please the people who like apps like this. :)

A Naming Challenge

In NetNewsWire, we have a concrete Feed type that’s what you expect: it describes an actual web-based feed.

But there are other things that are feed-like in some important ways. Smart feeds, script feeds (in the future), search results, and folders.

They have some things in common: an icon, the ability to fetch articles, the ability to provide an unread count, etc. These common abilities each have a separate protocol: UnreadCountProvider, for instance.

But this is so common that we should have a single protocol that bundles these up into one.

The problem is — what should we call it?

* * *

Maybe the right for that single protocol is Feed. If so, then what should we call the concrete type for web-based feeds?

* * *

In the original design for NetNewsWire, five years ago, Feed was going to be a protocol. Then I started working in Swift, found that I wanted to use Set<Feed> and couldn’t, so I made it a concrete type.

I love Swift, but this limitation keeps coming up for me. I use both protocols and sets a lot, because they’re often the best choice, but in Swift they just don’t play together well.

* * *

Update a couple hours later, at 1 pm: We’re going with a protocol named Feed and the concrete type name WebFeed for, well, web feeds. This means a bunch of renaming in the app, but I think the result will be worth it.

Remember that it’s an open source app. The marketing team is not counting on a specific deadline. Our goals are 1) app quality, and 2) making it easy for people to work on the app (which really supports the first goal).

PS The marketing team is me. :)

For the entire 20 years of inessential.com, I’ve been in the same house, at the same desk, with even the same keyboard.

Happy 20th to This Blog!

Today is my blog’s 20th birthday!

It started like this: at the time I was working at UserLand Software on a blogging app called Manila, and this was my own personal Manila blog. It’s gone through a few other engines since then. (These days it’s rendered — as a static site — by some Ruby scripts.)

* * *

It‘s tempting to think that The Thing of my career has been NetNewsWire. And that’s kinda true. But the thing I’ve done the longest, love the most, and am most proud of is this blog.

* * *

The original tagline was “You don’t need to be here.”

The name inessential sounds like a low self-esteem thing. It’s not. It was named for the idea that literature is inessential. Without it, people would still go on fucking and fighting and grocery shopping.

In other words, the name comes from huge and unwarranted self-esteem, as if my blog would be the first to be literature. Sheesh! Now I laugh at myself. What arrogance!

I hope I’ve matured, at least a little, since then. But I keep the name, because nowadays that’s just its name.

* * *

Old proverb: “The best time to start a blog is 20 years ago. The second-best time is today.” :)

This Feature Should Be Easy

From time to time people note, in feature requests, that a particular feature should be easy, and they’re surprised it hasn’t been done yet. Sometimes they even say that it’s so elementary that they really consider it a bug that it hasn’t been done yet. Especially given how easy it is.

I’ve written about this before. See Bug Guilt Trips from 2003 and Anatomy of a Feature from 2009.

A feature is pretty much never as easy as it seems. The main function of a feature — whether that’s making a https call to a read-it-later service or adding some fairly simple new view — is often the easiest part.

It’s everything around the feature that makes it harder: UI design, localization, refactoring, accessibility, state restoration, getting new artwork (for a toolbar button, for instance), dealing with errors, testing, updating the documentation, etc.

And then you still have to schedule it: as important as a feature request is, there might be others with a higher priority, and resources are always limited. Doesn’t matter who you are.

* * *

When you get developers alone, and you make a joke like “Why don’t you just…” or “I bet you could do this in an afternoon…”, they all laugh, because they’ve all heard this.

I most definitely do not want to discourage people from making feature requests, whether for my app or anybody else’s app. Please make feature requests! And report bugs!

But I would ask that you try not to call something easy. The developer of that app will have a pretty good idea of the requirements and the level of effort, and it’s never as simple as it looks on the surface. And they also have a good idea of what needs to happen, for various reasons, before work starts on that feature.