inessential by Brent Simmons

NetNewsWire Now Running on iOS

Maurice Parker took his proof-of-concept code and moved it into the main NetNewsWire repo — and now we have a version of NetNewsWire that builds and runs on iOS.

This morning, during my bus commute, for the first time I was able to read my feeds using NetNewsWire on my iPhone. So. Damn. Cool.

* * *

A TestFlight build is still quite a way away, I think. There’s still a lot to do. You could build it and run it on your own phone right now, but I wouldn’t recommend it yet.

* * *

I’ve been working on the app for five years. Most of the work is under-the-hood stuff — the UI is always the tip of the iceberg. UI is super-important, obviously, and takes a while to write too, but it’s not the bulk of the code.

Along the way I’ve had many moments where a thing I’d written years before — because I knew I would need it — suddenly becomes useful. For instance, I wrote the OPML parser early on (one of the very first things), and it was only years later when I added OPML import to the app. (There wasn’t even an app at all when I wrote the OPML parser.)

Those moments are great. The pieces start to click together, and you realize you planned well.

And this particular moment is one of the greatest of all — because it means that all of that under-the-hood code, written over so long, was ready to run in iOS with just the barest amount of rejiggering. (We needed to deal with NSImage vs. UIImage, for instance. We needed to restructure the workspace tree to make it easier to work on the two apps.)

So: I’m continuing to work on wireframes. We’ll iterate over appearance and behavior using a running app. I’ll get back to working on syncing pretty soon (because it won’t ship without syncing).

* * *

If you’re interested in helping — testing, coding, giving feedback, helping me think things through, etc. — I’d be happy to invite you to the NetNewsWire Slack group. Just send me email asking for an invitation.

Swift Generics Improvements

Several days ago Joe Groff posted Improving the UI of generics on the Swift forums.

This proposal felt important — but it was, I hate to admit, really slow going for me to figure it out. For one thing, I had no idea what an “existential” is.

This is no criticism: this stuff, like a scientific paper, has to be written precisely and with agreed-upon terminology. It’s just that I don’t know all the terminology.

So, on another discussion forum, some of my friends were talking about it, and two people really helped with everyone’s understanding of the proposal: Greg Titus and Tim Ekl.

And then Tim went on to write a blog post which explains all of this in a way that regular Swift users — like me! — can understand.

Go read it! Swift Generics Evolution by Tim Ekl.

I’ve used generics a little, but I didn’t like what it did to the readability of my code. Now that I understand this new proposal, I like it. Very much.

More Thoughts at Random on Blog Search Engines

I can dream about how I’d build one of these. (I’m not going to! This is way outside my expertise, and I have other things to do.)

Instead of having it crawl blogs, I’d have it download and index RSS feeds. This should be cheaper than crawling pages, and it ensures that it skips indexing page junk (navigation and so on).

To get feeds into the system, I’d add an accounts system to the site. A registered user can do two things: 1) add individual feeds and 2) upload an OPML file of feeds (which they’d probably get from their RSS reader).

Registration (with an email confirmation loop) would be required for feed-suggesting.

And: a feed gets added to the crawl-and-index list once it’s been suggested by at least two users. This should help cut down on spam.

Accounts that are suggesting spam would be just shut down. And suggestion counts for all the feeds they suggested would be appropriately decremented. (And of course all spam feeds should be removed from the index.)

There would also have to be a way for users to report spam. And report hate speech and other things that shouldn’t be there.

* * *

Anybody should be allowed to use the system: it doesn’t require registration. The main page is like Google or DuckDuckGo — a big search field.

Registered accounts can login and see their saved searches.

Searches should be able to look for incoming links to a given site as well as search terms.

It should also provide search results via RSS — to all people, registered or not — via an easily-constructed URL, as in https://blogsearch.example.com/search.rss?q=some+search+term

Since a search results feed includes items from different feeds, it should use the RSS source element.

* * *

I don’t have any solid ideas about making this a business. I’m sure that it would be way easier to build than the search engines we had in 2005. And it should be way cheaper to maintain.

It could display ads on the website. Maybe it would offer a subscription that gets rid of the ads and perhaps offers some kind of extra features.

Years ago you could probably get VC funding for something like this. I consider it a blessing that we’re way past VC interest in RSS and blogs — you don’t need that amount of funding to get it built and running, and you wouldn’t want it anyway.

Could a person or small team run it as a labor of love, like I do with NetNewsWire? I’m not sure, because I don’t know enough about the costs involved (other than that they’ve gone down). Maybe?

One of the key would be to keep it simple. It’s just one component in an ecosystem of tools. Do search, and do it well, and that’s it.

Wishing for Blog Search Engines

One thing I wish we had that we used to have: blog-only search engines.

You could go and search for a hash tag. Or for links to your blog or elsewhere. Or for keywords. Etc.

It should have an API that returns RSS, so RSS reader users could set up persistent, updated searches.

There used to be a bunch of these, and now there are none that I know of.

* * *

Sure, it’s easy to search on Twitter. But you only get things posted on Twitter, and it doesn’t search the content of linked-to articles. So you’ll miss all kinds of things.

I can’t do this work myself — partly because I’m too busy with work and with other apps, and partly because I’m no expert at web-based stuff like this. I wish I could.

Jeffrey Zeldman, Nothing Fails Like Success:

On an individual and small collective basis, the IndieWeb already works. But does an IndieWeb approach scale to the general public? If it doesn’t scale yet, can we, who envision and design and build, create a new generation of tools that will help give birth to a flourishing, independent web? One that is as accessible to ordinary internet users as Twitter and Facebook and Instagram?

I think so. I hope so. My part is to write a free RSS reader — and make it open source so that other people can easily use RSS in their apps.

RSS isn’t the only part of the solution, but writing an RSS reader is in my wheelhouse. So this is what I choose.

Do I claim it’s as accessible to ordinary internet users as Twitter (for instance)? I do not. But it’s the step forward that I know how to take.

My point is: don’t give in to despair. Take a step, even if it’s not the step that will solve everything. Maybe your step is just to start a blog or open a Micro.blog account. Whatever it is — do it! :) #LetsFixThis

* * *

See also: Why Micro.blog is Not Another App.net

WKWebView Rendering Latency in 10.14.4

I noticed, starting in MacOS 10.14.4, that switching between articles in NetNewsWire was way less smooth than it had been.

NetNewsWire uses a WKWebView to display HTML. Before 10.14.4, there was no perceptible delay when switching to a new article.

With 10.14.4, there is. It’s quite noticeable, enough to be unacceptable.

I did some more detective work, and I’ve narrowed down the problem a little bit.

I’m using loadHTMLString(String, baseURL: URL?). The HTML is generated locally, and I set the baseURL because I want relative paths (especially for images) to get resolved properly.

What I found:

  • If I make baseURL nil, then the latency is gone.
  • If baseURL is the same as in the previously-loaded article, then the latency is gone.

Probable workaround

Here’s what I’m exploring: instead of using loadHTMLString for each article, I will:

  • Call loadHTMLString with a nil baseURL exactly once, to load a template.
  • To make relative paths resolve, I’ll parse and rewrite article HTML with resolved relative paths.
  • To load a new article, I’ll pass data to a JavaScript function inside the template that will swap-in new HTML in the right places (title, body, byline, avatar, etc.).

This is not work I was planning, and it means taking a break from syncing to get this done — because, right now, with 10.14.4, the app is not nearly as nice to use as it was.

PS While I’m rewriting the HTML, I’ll also remove ping attributes.

On the latest episode of The Omni Show, Annette Fuller, Support Human, joins the show to talk about writing, storytelling, and helping people. And the Marvel Universe. And Harry Potter. And more.

I love doing this show — it’s now about a year-and-a-half old. This is the 37th episode. (We publish every other Wednesday.)

I love that it serves as a kind of documentation for a specific company with specific people at a specific place and time — and it’s also a good look away from the celebrities of the podcast world.

What are the people like who — sensibly! — have hobbies other than recording podcasts? (Well, they’re pretty cool!)

Efficient Software

In an in-progress build of NetNewsWire, I turned off embedding the Swift libraries — which brings the app size down from 18.4MB to 6.9MB. Which is a huge saving, and I’m so glad we can do this now.

It reminds me of a thing I’ve been thinking about. I don’t have anything super well-put-together — just some provisional thoughts.

It seems to me that software uses electricity, and electricity use should be minimized for the health of the climate. Right? The larger the download, the more electricity it takes to download it.

And, of course, in general, the more efficient an app is, the less electricity it uses. It’s not like making NetNewsWire smaller and more efficient will change the planet — but if every app maker were to do better, it might help?

I’ll put it another way: I used to work on performance because people like apps that feel fast. (I sure do. I’m a speed junkie.) I still do that — but now I also think in terms of efficiency (which helps with performance), because I also think about the environmental cost of my software.

But, were I to bet, I’d put money on websites being the biggest-by-far abusers of electricity. Page sizes, and the amount of JavaScript that goes into them, has ballooned. It’s absolutely nuts.

(This is one of the reasons I favor static rendering. Pages are rendered once instead of on-demand — it seems obvious that this is most likely way more efficient. But if you’re still using a ton of JavaScript, maybe not.)

Should we be thinking green as we’re programming? Is it pointless? I hope it’s not — and I think we should be thinking green with everything we do, including programming.

And, along the way, we might find we make software and websites (especially) that people like better, since they’re faster and lighter.

Follow-Up on Publishing NetNewsWire on the Mac App Store or Not

I got a lot of feedback on this question, and here’s where I ended up: don’t publish 5.0 on the Mac App Store — publish direct-only — and wait and see if the app is having the hoped-for reach, and then re-evaluate. (Here is perhaps the first tweet I saw along these lines.)

I like that, because it lets me avoid spending time on work I don’t want to do, and I can spend more time on features.

And, as some commenters reminded me, good old-fashioned marketing does more to bring users than just putting the app up on the app store.

(Note: there was always going to be a direct-download version. The question was whether or not to also publish on the Mac App Store. I should have made this clear in my initial post.)

The feedback was interesting, though. Very few people were adamantly for or against the Mac App Store — people who expressed an opinion tend to lean in one direction or the other, but it wasn’t a deal-breaker either way.

People who were for the Mac App Store cited security, having a single place for updates, and not having to deal with licenses. The licenses thing is not an issue for NetNewsWire, since it’s free, but I understand the other concerns.

People who were against the Mac App Store tended to note that, well, it’s a kind of silo. And more than one person suggested that an RSS reader — an app that’s all about getting people out of silos (Twitter, Facebook, etc.) — shouldn’t itself be in a silo.

(Of course, you might also say that you have to go where the people are in order to lead them out!)

* * *

Anyway, to reiterate — I’ll be doing a direct-download version and not publishing to the Mac App Store with 5.0.

But if I find, at some future date, that I believe it could reach substantially more people, and I believe the Mac App Store will help, then I’ll publish it there too.

NetNewsWire on Mac App Store or not?

I’m not ready to upload NetNewsWire to the Mac App Store — months away, probably — but it’s worth thinking about now.

I’m on the razor’s edge with this one. Here’s my thinking:

Reasons not to appear on the Mac App Store

I have nights and weekends to work on the app, and doing a sandboxed version and fulfilling all the metadata requirements is quite a bit of work. It’s probably at least a week, possibly two. (Again, because I don’t have all day every day to work on it.)

I’d rather spend that time working on the next version (and on my other app ideas). I have a lot to do!

And then there’s the issue of reviews — which for free apps (which this would be) are notoriously severe.

I can already picture them: “The developer ruined the one great thing about the app when he removed the in-app browser,” “This is a con game because it says syncing is a feature and it’s free but you still have to pay some other service for syncing, and I bet he gets a kick-back,” and “This app isn’t very Mac-like, plus [other app] is prettier.”

Do I need to read this kind of thing for an app I do for fun and give away (even the source code)?

And — last thing — the last time I uploaded NetNewsWire to the Mac App Store was NetNewsWire Lite 4.0 (in 2011, I think), and it was delayed several weeks due to an Apple issue (regarding WebKit and favicons). Do I want to deal with possible frustrations like that? Maybe that’s hardly a thing these days?

Reasons to appear on the Mac App Store

My political goal is to promote the open web — the web of indie publications and blogs, the web outside the silos. And that means getting as many people as possible using it.

Being on the Mac App Store will increase that number. It furthers my goal.

Which do I choose?

This is such a difficult case because I have no real idea how many more users the app would get by being on the app store.

And I don’t really know how much time it will take to do the extra work, and I don’t know that the reviews would be as bad as they often are for free apps.

Is the gain — the increase in users — worth it? Maybe?

Seattle Xcoders meeting this week is unofficial — no actual meeting. Just show up at the Cyclops (in the back, in the restaurant section) for food and/or drinks and conversation. Thursday (March 28) at 6:30 pm.

Lots of Apple news this week! But of course we talk about whatever. We could talk about Apple stuff if you want to. :)

NetNewsWire Sync Diary #1: It Starts with NSBezierPath

In my Vesper Sync Diary I wrote about designing and writing both sides of a syncing system. I could make syncing work however I wanted it to work, and I had control of all of it.

Which is a great way to go. But it’s also terrible, because it means writing and running a server.

With NetNewsWire, I’m lucky in that there are existing systems — such as Feedbin, Feedly, Newsblur, and others — to use. I only have to write the client side.

I’m starting with Feedbin as the first syncing system. The first one is the hardest, of course — since there are a bunch of things the app needs for syncing that can be written once, but that do still need to be written.

How syncing will work

Users will add accounts to NetNewsWire — much as you do in Mail. Each account will have its own section in the sidebar (again, like Mail), which means you could have an On My Mac and a Feedbin account both active at the same time. (Just like you might have work and home email accounts active at the same time in Mail.)

You could even have multiple On My Mac and multiple Feedbin accounts. And, later, accounts with other systems.

When you make a change to the structure of your feeds and folders, the app will communicate immediately with the syncing system to perform the appropriate action. When you make a change to the metadata of an article (such as read/unread/starred status), the action will be coalesced and periodically (though fairly quickly) sent with other actions to the syncing system.

NSBezierPath

So I got started working on this, and almost immediately I found myself doing some custom drawing using NSBezierPath (which is a thing you use to fill and stroke lines, rectangles, circles, and other shapes).

Which sounds crazy, right? NetNewsWire has almost no custom drawing — in fact, before this, the only custom drawing was for the unread indicator (a circle).

And — bigger point — what does drawing have to do with syncing, anyway?

Well. There’s UI. Of course there’s UI — there’s always UI.

Users need to be able to add and edit their sync accounts, and I decided to do it the same way (surprise!) as in Mail — because this way the UI will be familiar to people who use Mail, which is surely a lot of Mac users.

I added a preferences pane called Accounts, and it uses the system-supplied icon for this exact case, and it has a thing like this on the left side…

Screenshot of the table and buttons on left side of the Account preferences

…or…

Screenshot, in dark mode, of the table and buttons on left side of the Account preferences

Looks much like Mail, right? (Not exactly the same, but it’s not important to make it exactly the same.)

The big space on top is a standard NSTableView, and the two buttons underneath are standard gradient buttons.

But what about that bordered gray thing to the right of the buttons? It has a background color and a border on top, right, and bottom edges — but not on the left edge, because that border belongs to the button.

There are a bunch of different ways I could have composed this whole thing, but in the end I just made that a custom view — AccountsControlsBackgroundView.swift — that draws its background and draws those three lines as a border.

(There’s probably an even simpler way using just one NSBezierPath instead of three. Or even a few NSBoxes used as lines. Whatever.)

My point isn’t that there’s anything interesting about this drawing — it’s that, when you go to work on a feature like syncing, the actual meat of the feature (communicating with sync servers) is often very small and easy.

User interface — design and implementation — tends to take up the bulk of the time, by far. By an amount that would surely surprise the heck out of people who don’t make apps.

In other words, it should never be surprising that work on a feature like syncing starts with an NSBezierPath.

Next step

What you see in the screenshots above is as far as I’ve gotten so far. The table view is empty; the buttons aren’t hooked up to anything.

The next step is to make that table view show a list of accounts, which, at the moment, is just the default On My Mac account. It should show the name and type of the account, along with an icon which represents the fact that it’s local-only and not synced.

On Twitter, Pádraig asks a great question, and probably every app developer should read the replies:

What are some of the reasons you would delete an app within a day of installing it?

We don’t take him seriously because he’s crazy.

But crazy people do take him seriously.

The Nordic Museum in my neighborhood is now officially the National Nordic Museum. Very cool!

We also have a statue of Leif Erickson. And we hold a parade for Sytennde Mai every year.

Big story on RSS readers in the iOS App Store today:

Really simple syndication — better known as RSS — is an enduringly useful technology that collects online articles from various sources in one convenient place.

The bummer about these articles is that the full thing can only be read in the iOS App Store. It would be nice if they actually appeared on the web, too.

The articles are often very well done and beautifully illustrated — and it would be to the benefit of Apple, and app developers, if these articles were findable and readable by people sitting in front of a computer.

Archive