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.
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.
KVO is why I drink.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I’m always happy for a friend when they start a job at Apple — but I’m also sad when it means they have to stop their community activities: no more podcasting and blogging, developer meetup organizing, presenting at conferences, writing side-project apps, contributing to open source things.
Another friend of mine at Apple, who worked in an area relevant to some trouble we were having with NetNewsWire, wanted to look at the source code – and they had to go ask permission before they could even look.
I understand! I understand why Apple PR and legal departments are the way they are. But I still feel a loss to the community every time somebody I know goes to work at Apple.
There’s a curtain between us and them. Colorful, well-designed, made by lasers — but still a curtain.
PS This would even prevent me from ever working there. I have a great job, and I intend to stay at this job till I retire, but if I were unemployed and saw the openings in Apple developer publications based here in Seattle, I totally would have applied. Except that working there would have meant the end of NetNewsWire and, effectively, the end of this blog. I would have had to give up the two biggest pillars of my career. It’s flat-out not worth it.
PPS I don’t write this to make any of my friends feel guilty! Working at Apple is a wonderful thing. But it’s bittersweet, and I do wish Apple would do more to take out the bitter part.