inessential by Brent Simmons

Immutable Swift Structs

As you read this, consider that I might be a squirrel and not, as I like to pretend, a rational programmer.

My Two Brains

My Objective-C brain — which will never leave me, even though I’ve been writing in Swift for years now — always told me to create immutable objects as often as possible.

Objective-C brain says, “Immutable means you never have to worry about it.”

My Swift brain — which is newer, and has all the fun these days — tells me another thing.

Swift brain says, “Value types are good. Use value types as often as possible.”

So my favorite thing in all of Swift is an immutable struct. It’s a value type, and it can’t be mutated!

Both brains happeeee! 🐥🐣

Var vs. Let

This came up in working on NetNewsWire: some model objects — some structs decoded from JSON returned by a syncing server — used var instead of let for their properties.

These model objects are not mutated anywhere. So, I figured, those declarations should use let instead. (Which would make my brains happy!)

An immutable struct is, after all, the greatest thing ever, right? You don’t have to worry about it. It never gets copied (at least in theory). If you share it across threads, it’s the same everywhere: you don’t get some number of different copies.

So I asked the author to change the vars to lets.

I didn’t expect the response — which was “Why?” (Asked earnestly, of course.)

I struggled with the answer.

Value Types Are Good

Here’s the thing: value types are good. Even though those structs aren’t being mutated now, we could imagine cases where they could be.

Why not leave it up to the code that has one of these to decide to mutate or not? After all, as value types, this makes a copy and doesn’t affect other instances. Value types are safe, regardless of mutability.

And yet…

Here’s Where I Might Be a Squirrel

I still insisted on using let for the properties in these structs.

There’s something to be said, of course, for always starting out strict and loosening up only when it’s actually needed. Don’t loosen up in anticipation. But that’s hardly a big deal here.

Instead I think it goes to code-reading: if I see let instead of var, I have some understanding of the intent. In this case, the structs are parsed versions of stuff-from-the-server, and that’s a case where you could expect immutability, and be surprised to find something else.

Those structs don’t get saved anywhere as-is; they don’t live long; nothing the user does can change them.

These structs are a report: “Server says this.”

So… I think it’s the right call, but I’m absolutely aware of the possibility that I’m just distracted by my Objective-C instincts, and I’m over-tidying.

I don’t know! What do you think? Should I have left it as-is?

The NetNewsWire team continues to rock — there’s a new TestFlight build up.

Note the change notes — they represent just three days of work. We’ve got the best team. 🎸

NetNewsWire for Mac Mystery Scrollwheel Crash

For NetNewsWire for Mac, I get one or two crash logs a week referencing scrollView:​scrollWheelWithEvent:.

Here’s the bug for it.

Chris Campbell, in a comment, writes:

FYI, I see this crash reported very frequently in the commercial Mac app I work on at my Day Job. Unfortunately, we’ve never been able to reproduce it first-hand. I used a Tech Support Incident to correspond with Apple about this issue (giving them hundreds of sample crash reports), only to have them ultimately give up and credit back the Incident.

-scrollView:scrollWheelWithEvent: is an API of the private NSScrollingBehavior class and its subclasses (class cluster). Those objects are an implementation detail of NSScrollView that are stored in an external structure, so there is significant opportunity for mismanagement of the memory references.

There has been speculation that “responsive scrolling” is somehow involved…

If you know more about this bug, or have more ideas for working around it, please comment on the issue. Thanks!

Update 2:20 pm Jeff Nadeau writes:

This should be fixed in 10.15. The 10.15.2 crash I see linked is something different.

This is great news! I hadn’t noticed that almost all of the scrollWheel-related crashes were in 10.14.

I have just one crash log that references the scrollWheel on 10.15, and it includes this:

Assertion failed: (![currentGestureList containsObject:​self]), function NSScrollingBehavior​ConcurrentVBL​AddToCurrent​GestureList, file /BuildRoot/​Library/Caches/​com.apple.xbs/Sources/AppKit/​AppKit-1894.20.140/Scrolling.subproj/​NSScrolling​BehaviorConcurrentVBL.m, line 102.

Estimating NetNewsWire for iOS Demand

As we get closer and closer to shipping NetNewsWire for iOS, I’m starting to realize that the iOS version could be quite a bit more popular than the Mac app.

Here are a few numbers:

  • NetNewsWire 5.0 for Mac was downloaded 24,789 times.
  • The NetNewsWire for Mac beta builds are downloaded anywhere from around 630 to around 1,360 times.
  • Number of people who signed up for the public test of NetNewsWire for iOS: 5,263.

Five times more?

The number of testers tells me — very roughly — that there’s about five times more interest in the iOS app than in the Mac app.

If that holds true, then NetNewsWire 5 for iOS, once it ships, will get downloaded about 124,000 times.

Let’s round down — call it 100,000 downloads in the first two weeks. I would be amazed if we got that that many downloads. I’m really expecting a number much closer to the Mac app. But I could be very wrong — I admit to thinking like a Mac developer and not really feeling the greater size of the iOS market.

It’s quite possible that 100,000 might be too low.

At any rate, I’ll be sure to report the actual numbers on this blog. 🐣

What does this mean for interest in RSS readers in general?

Remember that NetNewsWire is just one of many RSS readers on Mac and iOS. There are readers for Android and Windows — and a whole bunch of browser-based readers, such as Feedbin, Feedly, Inoreader, and others.

You can’t just multiply my NetNewsWire estimate by the number of apps and come up with something meaningful.

But you can look at some things and get an idea. For instance: on Feedly, one of the most popular browser-based readers, there are 1.6 million people subscribed to Engadget. No, I have no idea if those are all active readers, but still.

I think it would be reasonable to guess that the number of people who use an RSS reader is probably greater than a million, and could be several million people.

Those aren’t Twitter user numbers, obviously, not even close — but I’m betting it’s more than what most people assume it is.

PS This blog has 16K followers just on Feedly. If it were possible to add up my subscriber counts from each RSS reader, it would be quite a bit more than the 18K Twitter followers I have. Which is as it should be.

The New Ranchero Software

Ranchero Software, my old company, has actually technically existed in three different forms over the years — I’ve been an indie, then got a job and shut down the company, went back to indie and rebooted it, got a job, etc.

The most recent version — Ranchero Software, LLC — shut down a while ago. A year ago? I forget.

We got tired of reporting every month that it made $0. And we realized we had no plans to ever make money, since, well, I have a great day job at Omni.

But now it’s back, in a new way

The new Ranchero Software isn’t a company: it’s an organization on GitHub. Just today we moved NetNewsWire and associated repos to this new location.

We realized it would be easier if we had an actual organization with various teams — easier to manage, easier to add people, easier to set permissions, etc.

There was a little talk about what to call it. Name it after NetNewsWire? Or use the name Ranchero?

One of the things to remember is that it’s not just about NetNewsWire: there are also stand-alone frameworks and there’s another app: Rainier. (Which is way behind NetNewsWire. Nothing to see yet.) And we might do other apps, too.

So while we could have — a la the Apache folks — named the org after its founding project NetNewsWire, everyone preferred using the Ranchero name.

For me, at least, this is super cool. Ranchero Software lives!

PS You might wonder where the name Ranchero came from. It was 1996, and we were looking for a domain name that was 1) available, and 2) trendy. In those days, the hot stuff was Tango and Marimba and similar. We found that ranchero.com was available, and it kinda fit in with those names — plus it sounded kinda western — so we grabbed it.

PPS No, Ranchero Software isn’t an actual organization with papers filed anywhere. It’s just a thing on GitHub. But that’s all it needs to be.

My New Year’s Resolution Is to Focus My Anger

For the last few years I’ve found myself getting angry at small things, which is so unlike me.

My resolution is to try harder to get angry only when it’s actually worth it. I can be angry at cruelty, angry at the forces destroying democracy for their own corrupt power, angry at the malevolences driving our climate crisis.

But I need to not get angry just because Instruments won’t profile my app, or I get a robocall, or someone on Twitter completely misses the point of something I wrote.

Anger — righteous, smashing anger — is completely called-for right now. But only at the right targets. This is the hard part, at least for me — it starts to spill out to where it doesn’t belong, and I can feel it corroding me.

I’m not by nature an angry person. Quite the opposite! But I do care deeply about some things.

My emotions somehow need to get smarter about what’s worth the anger and what things are not actually part of the current vast project of destruction.

I don’t know how to do that other than to constantly remind myself, when I feel it bubbling up over something small, that it’s not worth it.

But the problem with anger — even our current justifiable and necessary anger — is that it becomes a habit, and then it goes blind.

NetNewsWire won an Upgradie for Best Newcomer Mac App! The whole team is so happy for this.

Other awesome stuff won too — one of my favorites is Automators, which won Favorite Tech Podcast.

Here’s the episode where Myke Hurley and Jason Snell talk about the winners and runners-up.

There’s a new public TestFlight build of NetNewsWire for iOS. The NetNewsWire blog has the details.

KVO, My Enemy

One of the keys to the stability of the shipping versions of NetNewsWire is that we don’t allow KVO (Key-Value Observing).

KVO is a false convenience — it’s often easier than setting up a delegate or old-fashioned notification. But to use KVO is to just ask for your app to crash.

And not just crash, but crash in hard-to-figure-out ways.

* * *

So we don’t let KVO into the app — except, well, we’re using Operation and OperationQueue for Feedly syncing, and the thing about Operation is that it uses KVO to signal when it’s finished. There’s no way of getting around that if you want to use Operation.

Okay. Fine. It’s worth it, right? It’s just this one small use of KVO. Surely we’ll be fine.

Nope.

KVO is why I drink.

Reminder: Select and Choose Are not Synonyms

From the Apple Style Guide:

Use choose, not select, for menu items. In general, the user selects something (such as a file or disk icon, an email message, or a section of text) and then chooses a command to act on the selection.

…and…

Use select, not choose, to refer to the action users perform when they select among multiple objects—such as icons, graphic images, radio buttons, or checkboxes—or when they highlight text for editing.

People often think, mistakenly, that select is the polite or proper form of choose — but, in user-interface-world, they actually mean different things.

How We Run the NetNewsWire Open Source Project

People ask me, “So — I can just show up, see something I feel like doing, do it, and then it will just show in the app?”

The answer, perhaps surprisingly, is no. Or, mostly no.

Well, kind of yes. It’s complicated. I’ll explain.

We run the project as if it were a commercial app

There’s a misconception about open source apps: people often think they’re not really intentionally run — they just kind of accrete whatever features and fixes that people who show up feel like doing.

NetNewsWire is not willy-nilly like that. We plan features and fixes the same way we would if the app cost money. We have a help book, a website, a blog, a Twitter account. We work especially hard on design. In most respects it’s indistinguishable from a commercial app.

We even set dates internally — and then blow right through them. :)

I’ve become fond of saying that NetNewsWire is a team. It is! But it’s also true that the app has my name on it.

My leadership style is to ask questions, talk things over, look for consensus, and trust people — but the last call is mine. It’s not a democracy, and it’s certainly not a thing where people just show up and ship whatever they feel like.

We definitely do not run the project as if it were a commercial app

But remember that NetNewsWire is free, has no budget (not one cent), and everyone who works on it is volunteering their time.

So there are some things we do differently from a commercial app.

Quality

A big one is app quality: we have to do way better than commercial apps.

This may seem surprising, but consider: we don’t have a support team. We help people when they have questions, but it’s vitally important that we ship the highest quality app possible so that we don’t get bogged down doing support. (The Help book is a big part of that too! But we’d do the Help book regardless, because it’s a matter of respect for people who use the app.)

You may remember older versions of NetNewsWire with fondness, and you may be missing some features the older versions had — but make no mistake: NetNewsWire 5 is a much higher-quality app than any older NetNewsWires.

And — this is smaller, but real — we publish the source code. Anyone can read it, and we don’t want to be embarrassed by it. Even better: we hope that people can learn from it! I’d bet that the majority of for-pay Mac and iOS apps couldn’t survive this kind of scrutiny. (I don’t say that to be mean. They don’t have to, so they don’t.)

This may sound paradoxical, but it’s true: because NetNewsWire is free and open source, we have to have a higher bar of quality than commercial apps have.

People show up

I said at the top that people can’t just show up and work on whatever and then we ship it.

Except, well — sometimes people actually do show up and work on what they want to work on, and then we ship it.

The difference is planning and design. We talk things over on our Slack group, in the #work channel: is that feature right for the app? Will it perform well enough? Does it depend on something else being done first? What’s the design for the feature? Does it need to go into 5.1, or 6.0, or…? Is it a Mac-only thing, or iOS-only, or is it for both? Etc.

(We also use the GitHub bug tracker and create milestones for different releases.)

Consider the situation with syncing systems. I knew we wanted to ship NetNewsWire 5.0 for Mac with Feedbin syncing. We couldn’t ship with nothing — and Ben Ubois at Feedbin has been super-helpful, and Feedbin is awesome, and so it was a no-brainer.

And then consider that, after that, Feedly syncing was by far the most common request, so it was obvious to prioritize that one next. (The iOS TestFlight build includes Feedly syncing, and the Mac app will follow suit.)

And then consider that our goal is to support all the various systems. Which one will come next, after Feedly? How do we choose? This decision is based in part on people who show up: what systems do they want to work on?

This is not how you’d do things with a commercial app, but in this context it works fine.

By which I mean there absolutely is an element of going with the flow of who shows up and what they want to do. That’s actually part of the fun.

No Revenue

People have offered money — just in general or for a specific feature. But we won’t take any money at all. Money would ruin it.

When money’s involved, it becomes an issue, and in this world it’s the issue. We have our own little utopia where we can pretend like it doesn’t exist. (“How fortunate!” you say. Yes, indeed, and we don’t forget that fact for a second.)

This means, though, that our decisions can be entirely about what’s best for the app and the people who use it — we never, ever have to think about what’s best for revenue.

This is so nice!

Transparency all the way down

No part of NetNewsWire is behind closed doors. The code is available, the bug tracker is open, and anyone can join the Slack group. You can watch us — and help us! — make decisions.

Because of this, I can’t do that thing commercial apps do where they keep quiet about stuff and then do a big surprise release with a bunch of new features. Luckily, I’ve done that enough in life — I have no interest in doing that over and over.

Instead, we’re honest and open about our goals and what we’re doing and when we’re doing it. Nothing’s hidden.

Which makes me feel sometimes like I’m doing a high-wire act and everybody’s watching. The level of difficulty is certainly higher than with the average commercial app, since we can’t hide our code or our thinking, since everyone is a volunteer, since we have to do better than for-pay apps.

But I wouldn’t have it any other way. I have always loved making apps, but making this app with this team is the most fun I’ve ever had. By far. (And I’ve worked on some pretty great teams.)

And you can join us if you like! Everyone’s nice. 👍

PS My favorite part of the page where I announced the TestFlight beta is the Credits, near the bottom. You could be in there next time.

NetNewsWire 2020: Roadmap Schmoadmap

We don’t have a detailed, plotted-out roadmap. Who does? Software is fluid, and software schedules are hot air.

But there are things that seem most likely for 2020. Consider this all as an educated guess, not as a promise.

NetNewsWire 5.0 for iOS: Q1 2020

We hope to be able to ship this in the first quarter. There’s no guarantee, but — given that it’s now in public TestFlight — it’s looking close to being finished.

NetNewsWire 5.0.4 for Mac: Q1 2020

This will be a bug-fix release, and it will be the last release that will run on macOS 10.14 (Mojave). The most important part of this release will be database clean-ups — it will be much better about pruning the database of old stuff.

It will also improve performance and reduce memory use.

But, given that we’re concentrating on the iOS app right now, and we don’t know how long that could take, this could easily slip to Q2.

NetNewsWire 5.1 for Mac: Q2 2020

This release will require macOS 10.15 (Catalina). It will add features already present in the iOS app: Feedly syncing and a Reader view. It may add other features, including additional syncing systems (no, I don’t know which ones). Tentatively — not for sure yet — we’re planning on sandboxing this release and publishing it on the Mac App Store.

Ideally we’d ship this in Q1. If we can, we will — but I’d put money on Q2 instead.

Now picture me waving my hands

There will be more releases, obviously, on both Mac and iOS — we’re just getting started! — but it’s too soon to make more definite plans.

But I can say some of the things we’re thinking about. We just don’t know when we’ll get to which ones, or what they’ll look like.

  • More sync options — we’d like to support all of the various systems
  • Sync via iCloud — we’re investigating the feasibility of this now, and I’m optimistic
  • Article view theming — possibly much like older versions of NetNewsWire
  • Setting font sizes for the sidebar, timeline, and article view on the Mac — we consider this a form of accessibility support (we already have this in iOS via Dynamic Text)
  • User-created smart feeds
  • The ability to delete articles — support already exists, under the hood, for this
  • More sharing options — sending to Instapaper and Pinboard, for instance
  • Some kind of triage/queueing system — so you can quickly go through your articles, then go back later to the articles you actually want to read
  • Panic button — for marking things as read based on time criteria

Those aren’t nearly all of the features we’re considering, but they’re the highlights. We’re not going to get all those done in 2020, but we’ll get some of them done.

NetNewsWire 2019 Year in Review

About a year ago, in early 2019, NetNewsWire for Mac was at the “d” (development) level, where it had been for years. For instance, we released NetNewsWire 5.0d8 on January 27.

We shipped the first alpha — feature complete, free of known bugs, but needing testing — by WWDC. NetNewsWire 5.0a1 was released May 31.

We reached beta in August, and then shipped NetNewsWire 5.0 for Mac on August 26.

We continued to ship updates to the Mac app — NetNewsWire 5.0.3, the most recent, shipped October 22.

Maurice started working on the iOS app before we shipped 5.0 of the Mac app — and, on Dec. 22, we shipped a public TestFlight beta of NetNewsWire 5.0 for iOS.

At this writing, four days later, 3,148 people have signed up to help test the iOS app. This is far beyond what we expected, and it’s super-exciting for the team.

* * *

The upshot: in 2019 we made both apps, Mac and iOS, great foundations for our future work. Getting to this point was no small thing — it took years, after all. But we shipped the Mac app, and we’ve gotten the iOS app to nearly-shipping.

I feel great about our pace! I know it can be frustrating for anybody waiting on some one specific thing — especially if it’s support for the syncing service you use — but, in 2019, the NetNewsWire team rocked.

Remember that it’s a group of volunteers who are doing this for love.

P.S. I’ll write another blog post soon-ish on plans for 2020. :)

Update a little while later: Here’s the 2020 roadmap.

NetNewsWire 5 for iOS Public TestFlight

NetNewsWire for iOS icon: Earth with a satellite orbiting above it, in the foreground.

You can go sign up on our testing page for the TestFlight beta for NetNewsWire 5 for iPhone and iPad.

The testing page has a bunch of info on it — including how to report bugs — and it’s way too long, and I’m totally cool with that.

Happy holidays! Happy NetNewsWiring! And thank you. :)

I can’t help but wonder if — given equivalent knowledge of UIKit and AppKit — iOS development isn’t harder now than Mac app development. At least for some kinds of apps.

Mac apps don’t have to deal with size classes, safe area insets, two very different classes of devices, getting killed by the system, a split view controller that isn’t suitable for some common purposes, presentation controllers, user activities, and — toughest of all — background app refreshing.

And some things that were Mac-only, such as multiple windows and contextual menus, are now iOS features too.

Even if I’m wrong, I can’t help but notice, as we work on NetNewsWire for iOS, that iOS development is starting to approach Mac-app-like complexity, and is already more complex in some areas.

Why I Listen to Podcasts at 1x Speed

On my microblog I mentioned that I always listen to podcasts at 1x speed.

Here’s why:

We’re in danger, I think, of treating everything as if it’s some measure of our productivity. Number of steps taken, emails replied-to, articles read, podcasts listened-to.

While accomplishing things — or just plain getting our work done — is important, it’s also important that not everything go in that bucket. The life where everything is measured is not really a full life: we need room for the un-measured, the not-obsessed-about, the casual, the fun-for-fun’s sake.

So I’m in no hurry. I will never, ever be caught up on all the podcasts I’d like to listen to. So, instead, I just play whatever I feel like whenever I feel like listening.

I’ll miss things, and that’s totally fine. But, in the meantime, I get to listen to the human voice somewhat close to realistically, with its the natural human pauses, with its rhythms and flows relatively unmediated and natural. Its warmth and music means so much more to me than being caught up.

But, again — I’m not saying this is right for you. But I would remind people that we have choices about what falls under productivity and what doesn’t.

Archive