My thanks to Day One Journal for once again sponsoring Daring Fireball. Day One first launched in 2011 and has been the stalwart of journaling apps on Mac and iOS ever since. Day One’s apps exhibit a commitment to technical and design excellence, and, more importantly, everything they do is deeply informed by the intense personal nature of keeping a journal. (Or journals — Day One lets you create as many separate journals as you want.) The Day One Mac app is Mac-assed and the iPhone and iPad apps are, well, iOS-assed. Fast, familiar, consistent, and intuitive.

Day One recognizes that many people struggle with journalling not because they can’t write, but because they don’t know how to begin or what a “good” journal entry about their day looks like. That’s why they built Daily Chat, a guided reflection experience that helps you talk through your day, organize your thoughts, and shape them into a journal entry.

Early testers commented: “Day One’s new Daily Chat is a true game changer for my daily journaling. The AI-powered chat makes capturing thoughts effortless and inspires creativity like never before. Writing my diary has never been this intuitive and fun!”

Try it for yourself, it will change the way you think about journaling.

Yours truly, back in 2018:

I don’t share the depth of their pessimism regarding native apps, but Electron is without question a scourge. I think the Mac will prove more resilient than Windows, because the Mac is the platform that attracts people who care. But I worry.

In some ways, the worst thing that ever happened to the Mac is that it got so much more popular a decade ago. In theory, that should have been nothing but good news for the platform — more users means more attention from developers. The more Mac users there are, the more Mac apps we should see. The problem is, the users who really care about good native apps — users who know HIG violations when they see them, who care about performance, who care about Mac apps being right — were mostly already on the Mac. A lot of newer Mac users either don’t know or don’t care about what makes for a good Mac app.

This eight-year-old piece holds up well. My concern was justified, but so too was my lack of defeatist pessimism. Truly native, idiomatically correct Mac-assed Mac apps are resurgent. Electron and its brethren non-native frameworks have not receded, but they haven’t gained further ground. For every Claude (Electron) there’s a ChatGPT (AppKit). I’m seeing more new good Mac apps released today than I was in 2018, and longstanding Mac stalwarts continue to thrive. High tide seems to have passed without washing the native platform away.

Apple itself is a good example. The Mac version of Journal, first introduced in MacOS 26 Tahoe, is a profound disappointment — not just because of serious bugs but because it’s un-Mac-like in sad ways. You can’t open an entry into its own window, for example. But the brand-new Siri app in the developer betas of MacOS 27 Golden Gate is pretty Mac-like. You can double-click chats in list view to open them in their own windows, for example. (You can’t double-click chats in grid view to open them into windows, though — presumably a bug.) Siri is not a great Mac app but it does feel like a Mac app, and it’s only a 1.0 in its second developer beta. It doesn’t feel like an iOS app running in a Mac window, like Journal does.

The ironic frustration with Anthropic’s Claude app being an Electron turd is that Claude and especially Claude Code are so capable of helping to create good native Mac apps. It’s one thing for a big company or organization with cross-platform aspirations but no institutional Mac expertise, like Notion or Slack or Discord, to choose Electron to create their Mac client. It’s another when it’s a company like Anthropic, whose only product’s single most impressive ability is generating programming code, including high-quality AppKit and SwiftUI code for the Mac. To return to my hammering-screws-into-the-walls metaphor from yesterday, it’s as though the building into which Anthropic decided to hammer all the screws is a renowned screwdriver factory.

Flexibits:

Calendar Mirroring allows you to connect two separate calendars (like work and personal) so that events from one automatically show up on the other.

The best part? No event information is sent to Flexibits servers or saved outside of your device.

You can choose to show full event details or just block the time out as a mysterious, professional “Busy”. Your coworkers don’t need to know you’re getting a root canal, they just need to know you’re unavailable.

In Flexibits’s example scenario, the idea is that you have a personal calendar with important events that you want to mirror to your work calendar, to block the times for those events off — and you might just want them marked as “Busy” on your work calendar, rather than revealing the actual details.

I’ve been using this feature in beta for a few months and love it, even though my use case is seemingly simple. For recording episodes of Dithering, Ben Thompson and I have a shared Microsoft 365 calendar. (You can guess which of the two of us set that up by that fact.) Fantastical has long had terrific built-in support for Microsoft 365 accounts. So for me, those events have always just shown up in Fantastical. For me.

The problem is, my wife and I share an iCloud calendar, where we put events we want each other to know about. My Dithering recordings have never shown up there. Ben and I record on a pretty regular schedule, but it’s always been a minor irritation that my wife can’t see when I’m booked for Dithering. Fantastical’s new mirroring feature solves this perfectly. I set up a mirror to copy all events from my Dithering calendar to my family calendar, keeping the original event titles rather than obscuring them as “Busy”. (The titles all just say “Dithering”.)

The icing on the cake is Fantastical’s longstanding “Combine identical events” preference setting. Because I have that setting on, I don’t see duplicate “Dithering” events — one from my Dithering calendar, and another from my family calendar. I just see one event for each scheduled recording, with a striped dual-color swatch that indicates that this one event exists on both calendars. It’s just perfect.

One more thing: Also somewhat recently, Fantastical added support for Anthropic’s MCP to integrate your calendaring with Claude Desktop and every other AI agent that supports the standard. David Sparks made a short demo video that shows it off. I don’t really use Claude so this didn’t hit for me personally, but it seems cool enough that it made me at least consider, for a moment, switching from ChatGPT to Claude. Then I remembered what the Claude app is like.

Anthropic released the first version of the Claude “desktop” app for MacOS in October 2024 — an Electron clunker that did not impress UI designers. When it came out, I wrote:

ChatGPT’s native Mac app, on the other hand, is a truly native Mac app. It looks like a Mac app and feels like a Mac app because it really is a Mac app. I’ve liked it ever since it launched back in May, and it keeps getting better. And I keep using it more and more as my go-to resource for answering questions.

I asked Claude, “What is the best way to engineer a native Mac app? What frameworks and developer tools should one use if the goal is a great Mac experience?” Claude’s answer started by positing it as a decision between SwiftUI and AppKit. Perhaps Anthropic’s Mac engineers should have asked Claude this same question before they built this turd of an Electron app.

In March of this year, linking to Anthropic’s announcement that Claude Code and Claude Cowork can take control of your Mac to accomplish agentic tasks, I returned to the same question:

The Claude Mac client itself remains a lazy Electron clunker. If Claude Code is so good I don’t get why they don’t prove it by using it to make an even halfway decent native Mac app.

I’m not the only one who has pondered this. Drew Breunig wrote “Why is Claude an Electron App?” in February this year:

On the surface, this ability should render Electron’s benefits obsolete! Rather than write one web app and ship it to each platform, we should write one spec and test suite and use coding agents to ship native code to each platform. If this ability is real and adopted, users get snappy, performant, native apps from small, focused teams serving a broad market.

But we’re still leaning on Electron. Even Anthropic, one of the leaders in AI coding tools, who keeps publishing flashy agentic coding achievements, still uses Electron in the Claude desktop app. And it’s a slow, buggy, and bloated app.

So why are we still using Electron and not embracing the agent-powered, spec driven development future?

For one thing, coding agents are really good at the first 90% of dev. But that last bit — nailing down all the edge cases and continuing support once it meets the real world — remains hard, tedious, and requires plenty of agent hand-holding. [...]

For now, Electron still makes sense. Coding agents are amazing. But the last mile of dev and the support surface area remains a real concern.

I’m with Breunig up until the point where he accepts coding agents struggling with the final 10 percent as a justification for choosing Electron to create a Mac app. Plenty of people — individuals and teams alike — are using Claude Code to create terrific new native Mac apps. Just among my friends, Glenn Fleishman, Lex Friedman, and Jason Snellman, have all in recent months used not just AI coding assistants in general, but Claude Code specifically, to create genuinely native Mac apps that meet their own personal high standards for Mac-assedness, forged through decades of literally professional Mac snobbery. A comprehensive catalog of Mac-assed apps made with the assistance of Claude Code, would, I suspect, be remarkably long.

The struggle with the last 10 percent is unrelated to AI coding. It’s the nature of all software engineering. There’s a well-known adage that Wikipedia names the “Ninety-Ninety Rule”, attributed to Tom Cargill of Bell Labs:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

Cargill’s mathematically humorous formulation resonates because it not only explains why the final 10 percent consumes half the time, but also why software projects tend to take twice as long as expected. This universal truth holds whether the code is human-written, AI-generated, or a mix of both.

Breunig gets closer to the truth in a postscript, linking to the Hacker News thread discussing his post. The top-rated comment in the HN thread is from Boris Cherny, who works at Anthropic on the Claude Code team. Cherny wrote:

Boris from the Claude Code team here.

Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively. It’s also a nice way to share code so we’re guaranteed that features across web and desktop have the same look and feel. Finally, Claude is great at it.

That said, engineering is all about tradeoffs and this may change in the future!

I would rephrase the guarantee that “features across web and desktop have the same look and feel” as guaranteeing that the Mac app is restrained by the limits of the web and cut off from the breadth of idiomatically native functionality provided by the Mac’s native frameworks. Electron guarantees that an app feels just as wrong on all platforms. But the more relevant tidbit is this sentence: “Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively.” So it’s not that Claude somehow prefers Electron, but that “some of the engineers” at Anthropic do.

Some is doing some heavy lifting there, given that “some of the engineers” includes Felix Rieseberg, currently Anthropic’s engineering lead for Claude Cowork and Claude Code Desktop, and previously engineering lead for the Claude apps for MacOS and Windows. Rieseberg didn’t merely “work on Electron back in the day”. He is one of the principal people responsible for creating Electron, and remains today one of three members of the Electron project’s Administrative Working Group that “oversees the entire governance and project”. He literally wrote the book on Electron.

Felix Rieseberg, quite obviously, is the answer to the question why Claude is an Electron app. It’s like wondering why all the screws in a building were hammered into the walls, and then finding out that the guy who oversaw construction founded and co-owns the world’s biggest hammer manufacturer. Windows uses Philips head screws, Linux uses hex screws, and MacOS requires Torx (of course) — but a hammer works the same way with all screws. That’s Electron. That’s Rieseberg’s baby.

Rieseberg, it turns out, hasn’t only had a hand in Claude being an Electron app. Per both his personal home page and LinkedIn profile, before joining Anthropic he spent over two years as the engineering manager for the desktop team at Notion, whose client for Mac is a massive 518 MB Electron app and a notoriously non-native experience.¹ Before Notion, Rieseberg spent 2016–2021 “as a Senior Staff Engineer and Engineering Manager at Slack, where I got to support a team of amazing C++ engineers building the cross-platform desktop framework Electron — as well as Slack’s desktop apps for macOS, Windows, and Linux.”²

Finding out that one guy — who is a senior Electron maintainer — has led the teams for the desktop clients for Slack, Notion, and now Claude is like discovering that it was one guy — whose family business was a distillery — who helmed the Titanic, piloted the Hindenburg, and then served as air traffic controller for Amelia Earhart.