Insert the url of the feed you want to read here (e.g.

Brent Simmons’s weblog.

 17 May 2019, 6:15 pm

I’m so looking forward to LIVE near WWDC — not just because it’s fun, but because the App Camp for Girls folks deserve a huge round of applause and a big party!

And, of course, we want to support their ongoing mission, even if doesn’t include summer camps.

 17 May 2019, 2:23 pm

Is it true that UISplitViewController doesn’t support three panes?

If so, then what I want from WWDC is three-pane support. Bigger iPads these days need it.

 17 May 2019, 1:51 pm

Fiery Feeds is looking pretty damn good!

 16 May 2019, 4:11 pm

Slack has a new thing — I think it’s new, anyway — where you can have a page where people can sign up to get an invitation. No longer a need to run your own thing.

Here’s a link for signing up for the NetNewsWire Slack group.

 15 May 2019, 3:59 pm

ScriptWeb for iOS found: it’s Automation Orchard. :)

 14 May 2019, 6:31 pm

Here’s what’s cool for me: normally I’d be stressing right now about a talk to give during WWDC — at AltConf or SwiftBy or somewhere — but I’ve retired from doing talks. It’s so nice not to be stressing!

ScriptWeb for iOS Should Be a Thing 14 May 2019, 4:56 pm

Back in the ’90s and early 2000s — before we forgot how easy and fun it is to code up a little site and put it up on the web — people used to make sites for the communities they were in.

It was like: “I know! Let’s put up a page! It will link to all the cool resources somebody interested in __ would learn from. We’ll update it now and again when there’s new stuff.”

Key point: it’s not a blog. It’s a directory, and often a single-page site. (There might be a few bullet points under a “What’s New” section, though.)

The best example that I know of was ScriptWeb — which still exists, though it’s no longer updated. It was all about Mac scripting, back in the early days of AppleScript, in the days of UserLand Frontier and MacPerl and HyperCard.

ScriptWeb was great. I started off my career as a scripter, and I went to ScriptWeb all the damn time.

So… where’s the ScriptWeb for iOS automation? I’m not going to do it, but somebody should!

* * *

If I were doing one of these sites these days, I’d store the source on GitHub, so that people could see revisions, and, most importantly, be able to make pull requests and file bugs for things they think should be added.

In other words: let the community help with the site. It shouldn’t be a big time commitment.

 13 May 2019, 1:46 pm

NewsWave developer writes about his new app, including the principles behind the app and how he decided on the business model.

 13 May 2019, 1:10 am

I finally converted this site to SSL. It’s not the first site I’ve converted, but it’s the last.

It wasn’t hard. I’m using Let’s Encrypt, and my hosting provider handles all the details, including renewing and updating.

The one thing I had to do manually was edit the .htaccess file so that http requests get redirected to https.

I’m still dubious on the use of https for sites like this one — but mainly I worry about sites that are hard to convert or where there’s nobody to do the work. What happens to what remains of the web’s history if, at some point, browsers won’t let us visit those sites anymore?

I’m thinking specifically of,, and There are plenty of others.

* * *

The change from http to https means all the permalink and guids changed in my feed — so you may get reruns in your RSS reader. Sorry about that!

 11 May 2019, 6:05 pm

I discovered just today that there’s an independent forum for outliner software users: (I’ve been using outliners for decades. Couldn’t live without one.)

 11 May 2019, 6:01 pm

Becky Hansmeyer writes, wisely, of App Store pricing, that “you’re not going to make it up in volume.”

 9 May 2019, 2:03 pm

Dave Mark wonders if Marzipan apps will be available only through the App Store.

I wonder this too. This one of the biggest questions for this year’s WWDC. The answer matters to me personally: if Marzipan apps are App-Store-only, then I can’t use it for my apps.

 8 May 2019, 3:00 pm

More to read: Martin Pilkington on Appreciating AppKit, Part 1.

Hopefully we’ll find that UIKit is awesome for writing Mac apps. But it’s worth knowing what AppKit provides, because it’s part of understanding Mac apps.

 8 May 2019, 2:20 pm

Craig Hockenberry’s What to Expect From Marzipan should be required reading for iOS developers considering doing Mac versions.

I want to amplify a couple things.

If you’re writing a Mac app using Marzipan, you’re still writing a Mac app. You’re a Mac developer now! For real.

As a Mac developer, you should do what other Mac developers do: understand and respect the platform and get help from Mac users, power users, and fellow Mac developers.

I’ve always found that Mac users are rooting for our success. They want us to make great apps — and they reward us for it. It’s a smaller, more intimate community, and warmer than iOS world. But you can also blow it by not trying, by not respecting the Mac and Mac users.

And that’s the biggest investment here. It’s not the coding. It’s your own intellectual and emotional investment in the Mac itself.

If you decide you’re up for it, then great! And: thank you.

The Feature I Most Want in Web Browsers 7 May 2019, 9:14 pm

Websites these days use crazy amounts of resources — and a lot of it goes to surveillance and tracking.

What I want is two related and similar things:

  • The ability to turn off JavaScript by default, and turn it on only for selected sites. (For me that would be sites like GitHub.)
  • The ability to turn off cookies by default, and, again, turn them on only for selected sites.

If it‘s the opposite — if I have to blacklist instead of whitelist — then I’d be constantly blacklisting. And, the first time I go to a site, it gets to run code before I decide to allow it.

I realize this will horrify many web developers: they’re accustomed to assuming that JavaScript is always available.

But we’re long past the time when we have to recognize that the extreme abuse of JavaScript and cookies is the norm. It’s the rare site that uses these for good.

I can’t believe we’ve tolerated this situation for so long.

* * *

PS You can still show ads without JavaScript. You just have to be able to render it server-side. I realize that’s harder.

NetNewsWire/Rainier Status 7 May 2019, 4:40 pm

The big thing remaining for NetNewsWire 5.0 alpha is syncing with Feedbin. My head is just not into syncing right now — I’ve done it too many times — but, luckily, Maurice Parker is into it, and he’s working on it right now, and making great progress.

NetNewsWire for Mac

There are some bugs to fix for 5.0 alpha — most of them small, but on that list is, of course, a new app icon. (Since an evergreen tree no longer fits the app.) There are some other cosmetic changes and very small features to consider too. But syncing is the big thing.

Once we get to alpha, then it’s all about testing, fixing any bugs that come up, writing the Help book, documenting the code, and getting the website closer to its shipping state (adding things like screenshots). A whole lot of writing, mainly — which I hope to get help with. Once that’s all done, then we’ll call it beta. (Beta is all about final testing and finishing the website.)

If things go well, we’ll hit 5.0a1 by WWDC. Fingers crossed!

NetNewsWire for iOS

The app is surprisingly far along (again, thanks to Maurice). It too is mainly waiting on syncing — but it also needs polish and UI review before it gets to alpha. My plan is to get there some time in the summer.

I expect to finish it after finishing the Mac version. I’m not trying for a simultaneous release. (Why bother? It’s harder to do a simultaneous release. It’s better to ship what’s ready to ship the moment it’s ready.)


While Maurice is working on syncing, I’m taking a NetNewsWire break and working on Ballard, the language built-in to Rainier. Currently working on the parser and evaluator (the thing that runs scripts).

I’ve never written a language before, and I’ve always wanted to. It’s fun! And brain-bending. (I’m writing all of it by hand. In Swift, of course.)

One of the goals with the language is to create something simple but easy-to-learn and useful. How-it-works should be understandable to anyone who wants to peek under the hood. (Since it’s open source, you can learn the entire thing.)

The language, and much of Rainier, will also be embedded into NetNewsWire — because that will allow me to use it to write new features for the app and it will allow people to automate NetNewsWire using an easy scripting language with a built-in storage system. (Other apps could embed it too. Even yours.)

My two apps are not just related — I think of them as two parts of the same project. Something about the open web and the freedom and power to make things.

Rainier for iOS

There could be a Rainier for iPad some day. I’m not sure it would make sense as an iPhone app — but as an iPad app, definitely. (Though I’m not sure Apple would approve it. If not, you could build it on your own.)

It’s even possible — depending on what we see at WWDC — that I could write the UI using UIKit and Marzipan. I totally will, if that still means I can make a great Mac app and deliver it outside of the App Store and not have to sandbox it.

We’ll know soon enough!

But, for now, I’m still working on the lower levels of Rainier, which would be shared code regardless (the language, standard library, storage system, etc.).

Anyway. That’s where I’m at. :)

PS There’s a single Slack group for both NetNewsWire and Rainier. Email me at if you’d like an invitation.

Elementary Swift: Catching the Actual Error 5 May 2019, 3:14 pm

I’ve written 100,000 lines of Swift code, maybe? But, even after all this code, I still have a blind spot with Swift try/catch. I’m writing this up just in case you do too.

My problem was with getting the actual error in a catch block. When I learned that there was a magic error variable, my problem was partly solved, because I could do this: catch { doSomething(with: error) }.

So that’s what I always did. But then, just yesterday, I finally had a case where I wanted to catch a specific type of error — and I just couldn’t figure it out.

I looked at the documentation on Swift error handling, which shows catching a specific error type like this: catch is VendingMachineError. (That’s the actual example! No, I’m not writing code for vending machines.)

I figured that, inside the block, there would be that magic error variable, and it would be typed as VendingMachineError. Like this: catch is VendingMachineError { doSomething(with: error) }.

Nope! That’s not how it works. The magic error variable does not exist in this case.


I asked some friends — Dave DeLong and Tim Ekl — who helped me. The answer was this:

catch let error as VendingMachineError { doSomething(with: error) }

The key to this is that you use Swift patterns with the catch, and Swift patterns support variable binding. But patterns are a topic I don’t fully get yet, either.

(For instance, why do we use case sometimes outside of a switch? I don’t actually know.)

* * *

Anyway. This post has four points. One is to help anyone else who runs across this problem. Hopefully a search will land them here.

The second is to suggest that the Swift error-handling documentation really should have this as an example — catching an error of a specific type, and getting a reference to that variable, is (or should be) a common thing to want to do.

The third is a reminder that even long-time programmers are still sometimes learning basic stuff. If your brain likes to justify your impostor syndrome with various tests — like “I’m not a real programmer till I know everything about Swift” — then tell your brain to hit the road.

The last is a reminder that having smart friends is always a good idea. :)

Post-WWDC Lightning Talks at Seattle Xcoders: Speakers Wanted 2 May 2019, 5:09 pm

The Xcoders post has more detail.

This is a great way to get started on learning how to talk in front of an audience. The Xcoders audience is wonderful. And you don’t have to talk long, and it will be on a topic that doesn’t have any experts sitting in the audience.

In other words: nobody’s judging you — we just want to learn what you have to tell us about. :)

NetNewsWire Syncing Implementation Roadmap 30 Apr 2019, 1:23 am

I wrote up three new tech notes:

Why Articles and Statuses Are Separate Tables

Possible Gotchas To Be Aware Of When Working on Syncing

Syncing Implementation Roadmap

The last one is the important one — and it shows (but you knew already) that Syncing Is Not a Small Feature.

The good news is that a lot of it is infrastructure that needs to be written just once. Adding systems later will be much easier than adding the first one.

(I might be done with tech notes for now.)

NetNewsWire Technotes Added 28 Apr 2019, 8:09 pm

I’m writing some documents about NetNewsWire’s code and architecture. In part because I believe this is a good practice for any software project — but even more because I want NetNewsWire to be completely knowable by anybody who’s interested.

It’s one thing to have an open source app, and quite another to have one that anybody — even, or especially, new programmers — can read about and come to understand.

I don’t claim that every decision I’ve made is brilliant. In fact, some are just okay, and some might be bad. That’s fine! But it’s a real, working app, and I like the idea of having explanations of how it works and why it works that way.

I’ll be posting links on this blog as I write them. Note that the tech notes are part of the repo, and they appear in the workspace tree, so everybody who checks out the code has a local copy always at hand.

Two new ones today:

Accounts — notes about the accounts system. (The “On My Mac” thing is an account; later you’ll be able to add accounts for Feedbin and other systems.)

How NetNewsWire Avoids Parsing Feeds — talks about using Conditional GET and other methods to avoid parsing feeds.

PS My favorite, though written quite a while ago, is the Coding Guidelines.

The Under-Appreciated Awesomeness of Apple Events (the Technology) 25 Apr 2019, 7:41 pm

Picture Jane in her office. She gets an email from Bob every month with the latest WidgetX numbers. With that email in front of her, she double-clicks a script (or chooses one from a scripts menu), which:

  1. Grabs the text of that email
  2. Extracts the actual numbers (minus Bob’s signature, etc.)
  3. Tells FileMaker Pro to open a specific database, and then adds those numbers to the database
  4. Creates an HTML page from a template, including the new numbers
  5. Uploads that HTML page to the company’s internal CMS
  6. Creates and sends an email (via Mail), with the new numbers, that goes to the CEO
  7. Updates and saves (on a shared folder) a Keynote presentation with the new numbers

This used to take hours, and it was prone to errors. Now it takes a minute or less — and it’s error-free.

What’s going on here? It’s AppleScript, sure — but, under the hood, it’s Apple events.

How to save a computer company

Apple events (lowercase “e” is correct) arguably saved Apple in the ’90s. Desktop publishing was huge and very Mac-centric, and that was in part because the various tools were automatable. When you can automate, you can save time and money.

This was before Mac OS X: there was no UNIX automation. No shell scripts, no pipes, no Terminal.

Instead, there was AppleScript and UserLand Frontier and an underlying bit of technology called Apple events. And apps like QuarkXPress which were scriptable.

You might say that Steve Jobs — or the iMac or the iPod or NeXT technology — saved Apple. But it’s very possible that Apple, without automation, might not have lasted long enough to get to Steve Jobs.

What Apple events are

Roughly put — they’re a way of calling a function, with parameters, in an app and getting back a result.

There are a few key things to know:

  • The other app is an already-running instance: Apple events do not result in a new instance of an app (exception: if an app isn’t running, you can, conveniently, launch it via an Apple event)
  • The function parameters are not limited to strings — you can send binary data (image data, for instance), arrays, etc. (This is key: the API is much richer than just a URL scheme with some text, which is what we’re limited to on iOS)
  • Apple events are an underpinning of AppleScript, but they’re not limited to AppleScript — they can be sent and received programatically by any app

Mac developers will often use Apple events without even realizing it. For instance, there are methods in NSWorkspace that hide underlying Apple events: opening a URL in the browser, or opening a Finder window rooted at a given folder.

These work because the browser and the Finder respond to specific Apple events, and NSWorkspace knows how to send them.

Another key thing to know: this was early ’90s technology. It survived the transition to Mac OS X because people relied on automation — particularly, as I mentioned, for desktop publishing, but for other purposes too — and, without that automation, they would have left the Mac.

When I say “relied on,” I mean that there were companies whose profits relied, at least in part, on being able to automate away hundreds of hours of manual tasks.

And there are plenty of people today who rely on Apple events to get their work done. It’s quite common.

Apple events are an example of the genius of the Mac

The Mac, the “computer for the rest of us” — for those of us who didn’t want to deal with a DOS prompt and arcane stuff — always promised to be easy for novice users. The UI was consistent, which helped a ton. Designers were encouraged to make commonly-used features the most visible and easiest to use.

And that’s great — but the absolute genius was combining that with power-user features by way of progressive disclosure.

This meant that more power was there, but it wasn’t required in order to use the app well. But, once you needed it, you could find it. And that extra power was as well-designed as the rest of the app, so you could get the most bang for your click.

But what do you do about features that shouldn’t actually be baked into the app? What about the power to do what Jane does?

That’s where automation — Apple events — comes in. It doesn’t get in the way of the UI, but if you can find your way to Script Editor (or a similar app: there are others), you can learn how to write any feature or workflow you can dream of (as long as it’s technically possible).

Part of the genius of this is that you’re scripting the apps you already use. You’re scripting these great GUI apps that you know and love. No command line, no piping/launching/closing. Just pulling information from apps and telling them to do things.

The Mac OS X Accelerator Pedal

I have heard — I don’t know if it’s true — that some people at Apple wanted to ditch Apple events (and AppleScript) in the transition to Mac OS X. It was already a several-year-old technology, and I can see how people thought it might not fit in with OS X.

But the technology was preserved, as I mentioned earlier, because people and companies needed it. So it’s old stuff, but it’s stuck around for very good reasons.

But here’s where the Mac gets even better: OS X is UNIX, and now we can mix-and-match traditional Mac scripting with Python and Ruby and shell scripts and all the power of UNIX tools. (Note: you can call an AppleScript script from a shell script, and vice versa.)

I didn’t mention it, but Jane, in the example at the top, is using AWK to extract the numbers from Bob’s email text.

An outside observer might think Mac users just use pretty — and pretty simple — apps, and that’s the whole story. But that completely misses the power and genius of Macs.

I can’t think of another platform with the sheer level of automation power that OS X (now macOS) has.

So, after all that, a question

What happens to Jane if Mail is a Marzipan app that doesn’t respond to Apple events?

Freedom 23 Apr 2019, 8:37 pm

When my parents bought me an Apple II Plus — in 1980, when I was 12 — I fell in love with this entire new world that was mine. Anything that was technically possible, I could do.

I played games and I learned how to write programs in BASIC and, later, using an assembler.

It was marvelous. There were no chains on me other than the limits of the machine.

* * *

At the same time, grown-ups were sneaking in Apple II Pluses to work so they could run VisiCalc. A little later it was IBM PCs.

And the reason there was similar: the computing power they had access to was tightly controlled by the IT priesthood. Then the personal computer came along, and they had the freedom to solve problems on their own — when they wanted to, the way they wanted to.

This was a revolution.

And then, a little while later, the Mac came out. The PC was great and it democratized computers to a certain extent — but the Mac, and the ideas behind the Mac, took that much, much farther. People who were put off by a DOS prompt on a green-screen monitor had a computer they wanted to use. This extended that revolution, and Microsoft later joined in with Windows.

* * *

After a while, of course, people realized that work computers weren’t really their own. And IT departments did their jobs — as they should — and they networked these computers and worked out administration and so on.

But still, it was much better than what had been.

And — very importantly — outside work, your computer was yours. You had the freedom to use all its power.

And Macs and PCs became ever-more-powerful, with faster CPUs, bigger hard drives, more accessories, and — perhaps most importantly — better software. Things like Photoshop and QuarkXpress and Lotus 1-2-3 and Word.

And (on Macs, which I know best): HyperCard, AppleScript, and UserLand Frontier. ResEdit. INITs. All this crazy powerful stuff, which I loved.

* * *

Maybe because I lived through this — maybe because I’m a certain age — I believe that that freedom to use my computer exactly how I want to, to make it do any crazy thing I can think of — is the thing about computers.

That’s not the thing about iOS devices. They’re great for a whole bunch of other reasons: convenience, mobility, ease-of-use.

You can do some surface-level automation, but you can’t dig deep and cobble together stuff — crossing all kinds of boundaries — with some scripts the way you can on a Mac. They’re just not made for that. And that’s fine — it’s a whole different thing.

In a way, it feels like iOS devices are rented, not owned. This is not a criticism: I’m totally fine with that. It’s appropriate for something so very mass-market and so very much built for a networked world.

* * *

But what about Macs?

Macs carry the flame for the revolution. They’re the computers we own, right? They’re the astounding, powerful machines that we get to master.

Except that lately, it feels more and more like we’re just renting Macs too, and they’re really Apple’s machines, not ours.

With every tightened screw we have less power than we had. And doing the things — unsanctioned, unplanned-for, often unwieldy and even unwise — that computers are so wonderful for becomes ever-harder.

And now comes Marzipan, and I can’t help but worry that it’s another tightened screw. Will sandboxing be a requirement? Probably. Will they be able to send or receive Apple events? Will they support AppleScript? Seems unlikely. Will they be available only on the App Store? Good chance.

And you could say that’s fine — developers will use AppKit. But if AppKit is deprecated — or, effectively the same thing, perceived as deprecated by developers, or just perceived as uncool — then you get only the less-powerful Marzipan apps.

Meanwhile, the iOS triumphalists are saying that we should welcome the end of the revolution.

People will probably tell me it’s generational. And maybe it is. But if we don’t have this power that is ours, then I don’t actually care about computers at all. It meant everything.

NetNewsWire Now Running on iOS 17 Apr 2019, 4:22 pm

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 14 Apr 2019, 9:45 pm

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 14 Apr 2019, 2:54 pm

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

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 11 Apr 2019, 4:20 pm

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.

 11 Apr 2019, 4:09 pm

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 account. Whatever it is — do it! :) #LetsFixThis

* * *

See also: Why is Not Another

WKWebView Rendering Latency in 10.14.4 4 Apr 2019, 4:16 pm

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.

 3 Apr 2019, 2:00 pm

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 2 Apr 2019, 4:24 pm

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 27 Mar 2019, 9:33 pm

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? 26 Mar 2019, 4:43 pm

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?

Page processed in 0.601 seconds.

Powered by © 2004–2019. In cooperation with Fresh Content. Based on SimplePie by Ryan Parman and Geoffrey Sneddon, and licensed under the BSD License.