GitHub: https://github.com/IronsideXXVI/Hacker-News
Download (signed & notarized DMG, macOS 14.0+): https://github.com/IronsideXXVI/Hacker-News/releases
Screenshots: https://github.com/IronsideXXVI/Hacker-News#screenshots
I spend a lot of time reading HN — I wanted something that felt like a proper Mac app: a sidebar for browsing stories, an integrated reader for articles, and comment threading — all in one window. Essentially, I wanted HN to feel like a first-class citizen on macOS, not a website I visit.
What it does:
- Split-view layout — stories in a sidebar on the left, articles and comments on the right, using the standard macOS NavigationSplitView pattern.
- Built-in ad blocking — a precompiled WKContentRuleList blocks 14 major ad networks (DoubleClick, Google Syndication, Criteo, Taboola, Outbrain, Amazon ads, etc.) right in the WebKit layer. No extensions needed. Toggleable in settings.
- Pop-up blocking — kills window.open() calls. Also toggleable.
- HN account login — full authentication flow (login, account creation, password reset). Session is stored in the macOS Keychain, and cookies are injected into the WebView so you can upvote, comment, and submit stories while staying logged in.
- Bookmarks — save stories locally for offline access. Persisted with Codable serialization, searchable and filterable independently.
- Search and filtering — powered by the Algolia HN API. Filter by content type (All, Ask, Show, Jobs, Comments), date range (Today, Past Week, Past Month, All Time), and sort by hot or recent.
- Scroll progress indicator — a small orange bar at the top tracks your reading progress via JavaScript-to-native messaging.
- Auto-updates via Sparkle with EdDSA-signed updates served from GitHub Pages.
- Dark mode — respects system appearance with CSS and meta tag injection.
Tech details for the curious:
The whole app is ~2,050 lines of Swift across 16 files. It uses the modern @Observable macro (not the old ObservableObject/Published pattern), structured concurrency with async/await and withThrowingTaskGroup for concurrent batch fetching, and SwiftUI throughout — no UIKit/AppKit bridges except for the WKWebView wrapper via NSViewRepresentable.
Two APIs power the data: the official HN Firebase API for individual item/user fetches, and the Algolia Search API for feeds, filtering, and search. The Algolia API is surprisingly powerful for this — it lets you do date-range filtering, pagination, and full-text search that the Firebase API doesn't support.
CI/CD:
The release pipeline is a single GitHub Actions workflow (467 lines) that handles the full macOS distribution story: build and archive, code sign with Developer ID, notarize with Apple (with a 5-retry staple loop for ticket propagation delays), create a custom DMG with AppleScript-driven icon positioning, sign and notarize the DMG, generate an EdDSA Sparkle signature, create a GitHub Release, and deploy an updated appcast.xml to GitHub Pages.
Getting macOS code signing and notarization working in CI was honestly the hardest part of this project. If anyone is distributing a macOS app outside the App Store via GitHub Actions, I'm happy to answer questions — the workflow is fully open source.
The entire project is MIT licensed. PRs and issues welcome: https://github.com/IronsideXXVI/Hacker-News
I'd love feedback — especially on features you'd want to see. Some ideas I'm considering: keyboard-driven navigation (j/k to move between stories), a reader mode that strips articles down to text, and notification support for replies to your comments.
Discussion (161 Comments)
I'm probably just a anti-app guy, but I tried it out.
First thing I went to do was CMD-F to search for some strings in the comments section.
Actually, the real first thing I did, was click on the left-side article preview on the text that said "1 hr ago | 63 comments" thinking it'd navigate me to the comments. See, I like my native hyper-links.
Am I missing some core concept here? Why would I want to browse the web in this app as opposed to a web browser?
There are various arguments for it (better compatibility/cohesiveness, minimalism, less debugging) but it overall seems like the opposite of the "hacker" mindset which makes how much market share MacOS has in the space very strange.
IMHO your comment is unfair. Native apps really are, when done right, much better. Sadly they are rarely done right.
For many the whole goal is the comments on those links.
I like native apps for things, even link aggregators, because my I want to use my OS's native window management and app management instead of just shoving everything into a browser tab, of which I already have too many. Because then it's just CMD+Tab to Chrome, and then figure out which of the 20+ tabs I'm trying to get to instead of CMD+Tab directly to that specific app.
Anyway, just a bit of old man yelling at cloud but I've always disliked the proliferation of "web app all the things." Might as well not even use a desktop OS at this point and just have a full screen browser window and call it a day.
Ironically, most of the app is a webview. The comments just have some additional CSS styling slapped on top of the hackernews website. So you still have an entire HackerNews site loaded at all times when reading comments anyway.
There will be a way to do user actions like upvote/comment/favorite/flag soon.
Well, assuming you have a browser open anyway, you're still using more memory than if HN is running in another browser tab.
In fact, if every website that you use frequently had its own native app, that would use more memory than you're using now.
A fresh hackernews tab of this thread uses 150MiB (Sandboxed) in Chrome for me, and HN is a pretty lean site by all accounts.
Two of my feature requests: 1. Allow cmd+f search on the whole app - I wanted to search your post on the app but I couldn't 2. A browser button to open the current page on an external browser.
Side note: I am trying to minimize my HN time via getting push notifications for relevant HN posts, and that's how I discovered your post. Would it be cool if one could write custom agents on top of an app? Maybe?
Two things, does anyone else feel like 2017 was not 9 years ago and rather feels like it was just yesterday? I use a 2017 iMac running MacOS 13.7.8. It appears my hardware will not support any newer version of MacOS. For the most part, I haven't been too discouraged by this as I prefer older MacOS designs over the newer ones.
However, this is the second time in 2 days I've actually hit a wall in the Apple eco-system due to an older OS.
Last night I tried to build Ghostty to hack on a feature... it needs Xcode SDK 26 which isn't supported on Xcode 14 (latest version I'm able to install).
Now today, attempting to try this app out, I can't launch it due to being on too old of an OS.
It's really a shame because this iMac from 2017 is quite the capable machine. Absolutely no reason to upgrade it (from a hardware / performance standpoint).
macOS Big Sur and newer on machines as old as 2007
macOS Big Sur, Monterey, Ventura, Sonoma and Sequoia
Personally I'm hapy with my old macOS in no small part thanks to https://www.macports.org
Windows developers would think nothing of keeping their applications running on Windows 7 (16 years old) or Windows 10 (11 years old), but my 9 year old Mac is somehow ancient.
First feature request from me would be to adjust text size. I've start bumping up the default text size on all sites by one or two notches in the past year. Getting old, y'know. But also, as someone pointed out on a design blogpost a decade ago, why not make things easier to read. I didnt need it then, but I appreciate it now.
Really happy that I can run this on MacOS14 cause I've been locked out of some neat things people have built recently. Thanks for targetting older OSes. I'm not upgrading to the crap they've been putting out lately.
I'll be able to read details more later (getting ready for the job). Hope I didn't miss anything and comment about something that was already addressed. Congrats on shipping!
I've been doing this too; at some point I should probably just change the scaling of my desktop as a whole. But I like my high resolution, multiple windows layout too much to do it yet!
https://github.com/Aperocky/hnterminal
Install: `pipx install hnterminal`
This is a good start, but I think a better approach would be to piggyback off of ublock origin's lists. Hopefully less maintenance that way too.
That won’t work. uBlock origin is licensed GPLv3 (https://github.com/gorhill/uBlock), this code is MIT licensed (https://github.com/IronsideXXVI/Hacker-News).
@IronsideXXVI, are you open to changing to gpl v3? Otherwise, there is probably a decent set of filter lists with an MIT license somewhere. The goal is for you to NOT become a filter list maintainer, and by piggybacking off an already respected set of lists, you'd build user trust in your adblocking.
I don't necessarily have a ready solution to offer, but these are the obstacles preventing someone like me from being able to use apps like this comfortably and safely, especially knowing we are entering a transitional period where new apps are being vibe-coded every day and formal verification has not yet caught up.
Even if a given app has had every line of code reviewed by a human, or has well-defined interfaces that allow for sloppier internal code, how do I know that without cracking it open myself or asking an agent to help me audit it?
That opens the door to lots of additional features… Cache responses so you can still read stuff when it gets the HN hug of death. Do a full-text index and offer a secondary search capability over article contents. Maybe build an API for all that so you can have AI Agents ground themselves on articles that got strong quality signals on HN. Maybe sign agreements with publishers like LWN, The Information, or whoever else shows up on HN behind a paywall frequently.
Obviously that would need to be a paid feature.
I sympathize with the desire to release programs/code anonymously or semi-anonymously on the internet. I noticed you don't particularly tie the extension to any identity (unless I'm missing something).
Maybe extensions are more constrained than I realize. Specifically it looks like the manifest has "host_permissions: ['https://squeeze.oj-hn.com/*']," and then presumably the only leakable thing is private contact email or votes. Maybe the chrome api content of the tabs/history permissions also (seems silly for chrome not to scope that to the startUrls though?) Not 100% sure I'm understanding correctly though.
it is all open source and built by CI, including squeeze, which is just a few lines of a CF worker.
https://github.com/OrangeJuiceExtension/
i'm also not anon and i have 16k karma here along with decades of history building open source that you're probably using on a daily basis without even knowing it (co-founder of java @ apache).
i also don't need money, so i won't ever sell this project to the highest bidder and i don't have plans or need to monetize it either. maybe add some ai features in the future that require you to put in your own api token. GPLv3 too, to prevent corporate takeover.
right now, it is just a ground up feature re-implementation of another popular HN extension that the author abandoned. i've done it with over 650 unit tests too, so it shouldn't be too buggy and stand the test of time.
up to you though. i use it daily. ¯\_(ツ)_/¯
Also would be nice to be able store notes or short blurbs about usernames that will show up in the app. Maybe as a tooltip?
https://github.com/timkuijsten/BoundedBikeshed
It lets me see the top-level comments with some indication of the thread depth. Totally changed my post scanning.
You're not kidding! That's actually the first thing I looked at in your Github Repo. It's annoying as I made a neovim gui and downloaded it from GH and couldn't run my own app until I dug into some hidden place in the Settings App. Definitely super helpful to see how it's done.
I'm digging the app too! As another commenter said it'd be cool to see the comments as native SwiftUI elements as well. :)
If anyone wants to see another repo with this, we have it set up for Slippi (and various subprojects, like the Launcher): https://github.com/project-slippi/Ishiiruka
I'm thankful that it's largely a "once it's working, it rarely breaks". If it does break, it's usually because I have to sign in to the developer portal and accept some contract somewhere. Error messages in CI rarely indicate this is the case sadly.
Btw, can you allow me to set the font-family, font-size, etc. for the interface? I can’t even do the default `CMD + +` to zoom in.
noprocrast + maxvisit + minaway on https://news.ycombinator.com/user?id=Brajeshwar is your friend for this :)
> In my profile, what is noprocrast? - It's a way to help you prevent yourself from spending too much time on HN. If you turn it on you'll only be allowed to visit the site for maxvisit minutes at a time, with gaps of minaway minutes in between. The defaults are 20 and 180, which would let you view the site for 20 minutes at a time, and then not allow you back in for 3 hours. - https://news.ycombinator.com/newsfaq.html
I am maintaining the list of what I am reading: https://www.bvaibhav.info/knos-digest
Plan to extend this beyond HN.
One thing: I really like the colors of Hacker News. It feels weird to me when Hacker News is presented in other colors. If I were to use your app I'd want to change the color pallet back to what it looks like on HN.
> Getting macOS code signing and notarization working in CI was honestly the hardest part of this project. If anyone is distributing a macOS app outside the App Store via GitHub Actions, I'm happy to answer questions — the workflow is fully open source.
Yes, in a past life I shipped a Mac application. This aspect is always a little bit of black magic. I will say that the Windows installer situation was a lot worse, IMO.
Congratulations on getting this out!
I'm curious, how much does it cost? Is it per build or a subscription? How do you make it work financially for an open-source project?
Also I appreciate how you made all backend calls just static functions which they always should be. People tend to overcomplicate these things and add a lot of boiler plate and unnecessary bureaucracy.
Going to try your app, thank you!
P.S. tried it, already miss the `threads` tab
A font size setting would be nice, I found the font is a bit small.
I think you should remove Claude as a contributor to your repo. It probably weaseled its way in on its own, I think it’s the developers job to talk about the tools they used not the tool company.
I actually really appreciate it when people do not hide their use of Claude code in their repo like that. It's usually the first thing I check on Show HN posts these days.
Split-pane the content: original article | comments
This is sooo good.
Bravo!
Thank you for the MIT license, I’ll be able to add my own.
It also works on my fork of the old news server.
Your code is just a very limited webbrowser. The webbrowsers, html are a very broken wheel. Alan Kay, the inventor of personal computing, explains why https://youtu.be/FvmTSpJU-Xc?t=961
This lecture Alan aimed at this audience, the computer science (programming) students at University of Illinois, where they programmed this broken wheel 20 years after Alan had showed them how do do it better.
Paul Graham should not have based HN (Hacker News) on the web and html but on WYSIWYG, then you would not have had to fix it with your app.
The Lively Kernel would be another way to fix html but retain the web. Two demos says it all:
https://youtu.be/gGw09RZjQf8?t=147
https://youtu.be/QTJRwKOFddc?t=234
Dan Ingalls implemented most of Alan Kay's invention of the personal computer, in these demo's he shows how to fix the webbrowser's broken wheel a bit. Their Squeak, Etoys and Croquet fixed it completely:
Early Croquet demo: https://www.youtube.com/watch?v=XZO7av2ZFB8
Croquet in webbrowser: https://codefrau.github.io/jasmine/
Demo of webbrowser replacement: https://www.youtube.com/watch?v=1s9ldlqhVkM
Squeak and all its predecessors: https://smalltalkzoo.computerhistory.org
Etoys: https://squeak.js.org/etoys/
How is this superior to an RSS reader?
In other similar news, I've been working on enhancing the HN ux, but still in the browser as an extension. The current build up on the Chrome store is pretty stable.
https://oj-hn.com
[1] https://developer.apple.com/documentation/webkit/webpage
My only nitpick is I wish I could force dark mode on web pages with a light background, but that’s minor.
SwiftUI is something entirely different and not trying to be cross-platform at all.