Tolaria is a “A second brain for the AI era”. It’s a MacOS app that sits atop Markdown files, uses Git for backups, and is open source. It also runs on Linux.

I wrote a similar version of this app for myself (named “Muellerpad” of course) so I was intrigued. I downloaded Tolaria, gave it a spin by importing the 2.5k Markdown files that make up my website to see how would hold up.

It was surprisingly fast.

The UI is an interesting blend of iOS and MacOS things, and I thought at first that it must be an Electron app. So I dug into the package to make sure and I was instantly surprised to see it’s only 23 MB. The app bundle had hardly anything in there - a couple of .js files and the executable. So it’s not Electron, or some other web based UI. But what is it?

I’ll also mention at this point that it reminded me a bit of Zed. There was something about Tolaria’s window chrome that rhymed with what Zed is up to.

So I go digging a bit on it’s GitHub page to find that it’s a mix of Rust and React, and it’s built with Node somehow. Oh, and it appears to only have been in active development since February?

That’s crazy fast development (and obviously AI did a lot of the coding).

The developer, Luca Rossi, has a write up on it with the following statistics: 100K lines of code, in Rust + React. 1900+ commits, 3000+ tests.

That’s incredible for something that’s been in development for such a short period of time.

I wrote a little bit about Zed last year:

Zed fascinates me for some reason, and I can’t quite pin down why. Is it because of the hardware accelerated text rendering? Is it because it’s crazy fast? It’s written in Rust? Some combo of those and other things? Beats me, but I think Zed is cool.

I find that Tolaria is giving me the same feelings. There’s something here about how it’s developed that I can’t quite put my finger on, but it feels … good?

I think it’s the speed. There’s no needless animations. Things just flow. It’s fast fast fast and the tables scroll at 60fps on my M1 Mac.

But it’s also the UI. It feels like a direction that MacOS could have taken. There’s clear a delineation between the content and the chrome. The UI is subtle and doesn’t scream “look at me”. In a way, it’s a contemporary implementation of what Mac OS was 10+ years ago, or maybe even all the way back to Mac OS 9.

To be sure, there’s a lot of things that could be improved. It doesn’t feel quite native - but it gets so much closer to native than Electron apps do. And I certainly like this Rust + React direction a lot better than the 300 MB+ Electron apps that are being foisted on us these days.

I want to dig into it more, but I think there’s something here. In my mind it feels more native to the Mac than Apple’s Messages and Contacts apps do. And that really excites my developer mind.

Update: I could have just read it’s foundational ADR to see what it was written in:

Use Tauri v2 (Rust backend + WebView frontend) with React + TypeScript for the UI, BlockNote for the editor, and Vitest + Playwright for testing.

I‘ve just release Acorn 8.5, which has some new features, nice SVG improvements, and some good bug fixes.

Here are my favorites:

There’s a new “Bendable” type of Arrow shape which lets you add a nice adjustable curve to your arrow. You can also have arrow heads on either end (or both) of the shape. This has been a feature request for many years, so I’m glad to finally add it.

SVG importing has been much improved. Drop shadows, text on a path, poly lines, transforms, reading css colors, and more are all now supported. If you find a SVG that Acorn won’t open - let me know!

The multi-stop gradient filters now have an option to use the Oklab color space for blending interpolation. What that means is the blending between colors is a whole lot nicer (aka, “perceptual”):

The Oklab interpolation isn’t available with gradients on vector shapes yet, but it’s something I’m working on.

Also new: pressing the option-tab keys will hide all palettes and toolbars. It’s a little thing, but I really like being able to see my image without any distractions. And if you have the “Edge to edge” canvas preference set, it’s great being able to see everything your image just floating there in space, “Letting the content shine” as Apple might say.

Various UI refinements with Liquid Glass and palette things when the canvas is set to edge to edge. There’s more to do here in the future as a general consensus begins to emerge for what Mac apps should look like on Tahoe, so expect more refinement in the future.

As a side note, as of today about 74% of you are using Acorn on Tahoe, 24% on Sequoia, and about 2% on Sonoma.

There’s more of course: and the full release notes are available as always.

What’s next? Well, I of course have a long list of things, but if you want to see something specific in Acorn, drop me a note.

There’s been a lot of talk recently about Liquid Glass on MacOS, and it being an abomination (epic rant from Nilay Patel there). OK, it’s not recent, but there’s still a lot of talk and Nilay’s rant got me thinking:

If Apple was to move away from Liquid Glass on MacOS, how would they do it?

As I was futzing around with Acorn’s plist I realized that maybe the answer might already there. Mac apps that haven’t been linking against the newest SDKs or have the UIDesignRequiresCompatibility plist flag set to true get the MacOS Sequoia look and feel. What if that setting was system wide? What if there was an Appearance toggle that said something along the lines of “Use the pro look and feel”, and all apps got a variant of the Sequoia UI, but spiffed up a bit more? It’s Gizmo vs. Platinum all over again.

It wouldn’t solve all the problems people are encountering, but it would be an interesting place to start.

Greg Knauss ▸ Lose Myself:

I got into computers because solving puzzles was fun, and building worlds was fun, and making things — the process of making things — was fun, down at the granular level. It was nice to have something at the end, but the act of creation was the exciting part. I suspect that predilection will begin to disappear (in commercial environments, at the very least), now that the people who do it — who want who do it — can be replaced. The journey actually was the reward for some subset of weird little freaks, but you can now skip all that crap and just jump to the end and get on with it.

I’ve been using Claude Code quite a bit lately, not so much to replace my programming but to augment it. The new animated image export preview in Acorn 8.4.1 was a direct result of that. It was a nice little feature that I knew exactly how to do, but I hadn’t prioritized getting done yet because there were a bunch of other things on my plate. But with a little assist, it was quick to implement.

I get where Knauss is coming from, and I feel it a too. I love coding! But why bother implementing anything when anyone can make an app in an instant? I’ve been wanting to make upgrades to my online dough calculator but have been putting it off because … well, anyone can just vibe code this themself now.

But at the same time I’m not worried about being replaced by AI, or by quick free apps that have been built by AI. And in some ways I’m more hopeful than ever.

For almost 20 years now, I’ve been feeling the pressure from competing image editing apps and the potential of everything falling apart and the utter doom of my chosen profession and company. These feelings are not new to me.

So I kept on making the software that I wanted to build, that I wanted to exist in this world. And though some months or years are rougher than others, people still were willing to pay for what I’m making. And that’s kept me going, and more importantly - employed.

Lately I’ve been thinking more and more about what Acorn should be. In a time when anyone can come up with an app idea and ship with little effort, what is going to make Acorn stand out?

I’m starting to think that’s going to be personality and feel and polish, but turned up a notch. That’s what I used to do when I started writing apps, but in some ways I have really toned it down in favor of OS alignment.

Does an AI know how to do that? Does a coding assistant know that an app is really a giant collection of details?

Maybe I’ll even have fewer competitors in the long run, or at least not as many new competitors. Because at some point it’s not about how good a programmer you are (and I’ve always been a middle-tier programmer), it’s about discipline and vision.

I’ve got feelings because anyone can put an app together now, so what’s the point of me? But at the same time, I can focus on what I want to focus on and hopefully charge forward and maybe everyone else will get tired of little vibe coded apps because you still have to know exactly what you want to build. And you can’t build something you can’t think of. And I know how to think and I have ideas.

And I have discipline and I know how to ship. And in my experience, that’s what has always mattered.

Josh Scott: John Mayer And The Coming Simulacra:

There’s a video making the rounds right now. John Mayer is sitting in his studio, switching between his amplifiers — his actual 1964 Fender Vibroverb, his Dumble Steel String Singer #002, his Two-Rock prototype — and a software plugin that a company called Neural DSP built by modeling those exact pieces of gear.

He’s playing. He’s listening.

He can’t tell which is which.

Digital amp modelers have come a very long way in the past 20 years.

The folks at Neural DSP have created a machine learning stack that will take in live audio from amps, and use that to figure out how to model the sampled amp. They have a neat (physical) harness that randomly moves the knobs on a guitar amp they want to simulate (watch this timestamped YouTube video to see the harness and an explanation). That captured data is then used to train a guitar model. So instead of analyzing schematics to emulate tube amps, they sample the real thing and create a model based on that.

By all accounts it‘s very good.

But there have always been purists, or detractors, or people who are so good at hearing and understanding guitar tone that these software amps just weren’t … true, for lack of a better word. John Mayer has always been in that camp.

But Mayer let the folks at Neural DSP into his studio, they sampled his setup, and then made a model off that. And apparently Mayer can’t tell the difference between the real thing and the model.

And now Mayer’s legendary rig (which includes the mythical Dumble Steel String Singer - an amp which is probably worth more than my house) can be in the hands of everyone.

It’s a moment in the guitar world. A giant shift, whether you believe it’s happening or not. A dream that many guitarists have been waiting for years for is finally here.

Modelers have certainly been very good for a while (I’ve been using one for years and loving it), but there’s something about this moment that’s like a quiet earthquake.

And Scott’s post on this goes into what this might mean going forward.

Anil Dash: How Markdown Took Over the World:

As hard as it may be to believe, back in 2004, the default was that people made new standards for open technologies like Markdown, and just shared them freely for the good of the internet, and the world, and then went on about their lives. If it happened to have unleashed billions of dollars of value for others, then so much the better. If they got some credit along the way, that was great, too. But mostly you just did it to solve a problem for yourself and for other like-minded people. And also, maybe, to help make sure that some jerk didn’t otherwise create some horrible proprietary alternative that would lock everybody into their terrible inferior version forever instead.

A great essay by Dash, about everyone's favorite plain text format and the why and how of the times.

I love Markdown. All of Acorn's documentation is in written in Markdown, and the same with Retrobatch's. All my notes these days are in Markdown too.

Like many things that we come to rely on, Markdown was probably inevitable. However we could have ended up with something that absolutely sucked, but we didn't, and we have John Gruber's good taste to thank for that.

Chris Lewis: Using Coding Agents to Decompile Nintendo 64 Games:

Recently, I’ve been working on a matching decompilation of Snowboard Kids 2, an incredibly underrated racing game for the Nintendo 64. The purpose of this post is to document how coding agents have and haven’t helped with the decompilation process. While much has been written about LLMs, far less has been written about decompilation, so I’m adding another data point

I've used ChatGPT to decompile a little bit of code in the past, which worked pretty well (and is super informative, you should try it. (also thank goodness for Hopper)). But using an LLM to decompile a N64 game is next level awesome.

Lewis also has another post worth reading - The Unexpected Effectiveness of One-Shot Decompilation with Claude.

Acorn is an App Store Awards Finalist for 2025!

I'm pretty excited about this! - thanks to everyone at Apple for the recognition, and congrats to the other finalists as well.

I recently came across a post by Aurimas Gasiulis on Parallel vector graphics rasterization on CPU, which I found pretty intriguing. Gasiulis wrote a vector shape renderer named “Blaze” and made it work across multiple threads. Very cool stuff.

But I was shocked when performance charts were provided, which included comparisons to rendering with Apple’s Core Graphics library. Blaze was around 20x faster at rendering than CG.

This sounds like a wonderful nerd snipe to me.

Does Core Graphics (CG) already do parallel drawing? Not that I’m aware of, at least when it comes to rendering vector shapes. What if we just … draw on multiple threads with the same CGContextRef? That seems like a bad idea and as far as I’m aware, CGBitmapContext isn’t thread-safe. And it turns out that yes - this is a bad idea. Segfaults abound.

What if we make multiple CGContextRefs for each thread, but they all reference the same backing store? And what if we clip to horizontal stripes like the Blaze renderer does?

Well, that seems to work just fine, and it’s a nice speed boost. A quick little test in Acorn where it rendered 28,200 shapes took about 0.93 seconds single-threaded, and only 0.11 seconds with the parallel drawing.

Both are very fast for rendering that many shapes. But if we make the rendering a bit more complex by giving each of those shapes a 5pt drop shadow? Here we get 17.8 seconds for a single-thread render, and 2.7 seconds for a parallel render. Even though the multiplier is about the same (~8× speedup), 15 seconds saved is a lot.

Were there any rendering glitches? There were very, very tiny anti-aliased edges that were not perceptible to the eye, and the images were otherwise identical (and I used Acorn’s “Compare Two Front Windows” command (new in 8.3!) to figure this out). The implementation is very simple as well:

CGContextRef FMCGBitmapContextCopySharingData(CGContextRef originalCTX) {
    CGContextRef ctx =
        CGBitmapContextCreate(CGBitmapContextGetData(originalCTX),
        CGBitmapContextGetWidth(originalCTX),
        CGBitmapContextGetHeight(originalCTX),
        CGBitmapContextGetBitsPerComponent(originalCTX),
        CGBitmapContextGetBytesPerRow(originalCTX),
        CGBitmapContextGetColorSpace(originalCTX),
        CGBitmapContextGetBitmapInfo(originalCTX));

    return ctx;
}

void FMCGBitmapContextParallelDraw(CGContextRef context, void (^b)(CGContextRef chunkContext, CGRect chunkRect)) {

    size_t height = CGBitmapContextGetHeight(context);
    size_t chunkSize = 100;
    size_t chunks = (height + chunkSize - 1) / chunkSize;

    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0);

    dispatch_apply(chunks, queue, ^(size_t chunk) {

        CGContextRef chunkContext = FMCGBitmapContextCopySharingData(context);

        CGRect chunkRect = CGRectMake(0, chunkSize * chunk, CGBitmapContextGetWidth(chunkContext), chunkSize);

        NSGraphicsContext *currentNSContext = [NSGraphicsContext graphicsContextWithCGContext:chunkContext flipped:NO];
        [NSGraphicsContext saveGraphicsState];
        [NSGraphicsContext setCurrentContext:currentNSContext];

        CGContextSaveGState(chunkContext);

        CGContextClipToRect(chunkContext, chunkRect);

        b(chunkContext, chunkRect);

        CGContextRestoreGState(chunkContext);
        [NSGraphicsContext restoreGraphicsState];
    });
}

Can this be made any faster? Maybe by reusing the temporary contexts? But an 8× speed improvement is good enough for me for now. Will I use this code in production? I’m not sure yet, but I’m tempted.

Acorn 8.3 is out and the big new feature is that it supports Liquid Glass for folks who are running macOS Tahoe (which is over 50% of Acorn 8 users at this point!).

Actually, Acorn 8.3 came out a few weeks ago and the current release¹ at the time of this writing is 8.3.2. I wanted to sit on an announcement a bit because I knew the refinements were going to be coming fast and I was really hoping macOS 26.1 would be released soon (it had some bugs that hurt Acorn in a number of ways). Also, you really shouldn’t be running macOS Tahoe unless you’ve updated to 26.1 (the initial release was very bumpy).

At any rate, what’s new? Basically the UI. That’s it. The full release notes are available as usual (and it includes some minor changes and bug fixes).

But the UI was a ton of work! And I made it extra difficult on myself by making Liquid Glass optional. Why the heck would I do that?

There were a couple of reasons (besides some people really, really not liking Liquid Glass).

First of all, Acorn still supports macOS 14 and 15. And if you recall, Liquid Glass is only available on macOS 26. So any changes I’d make to Acorn would also have to work fine on previous OS releases. So in a sense, you could choose to use LG or not based on what version of macOS you’re running.

But I didn’t want to completely keep folks on pre-Tahoe from joining in on the fun. So I actually broke the setting up into two different preferences.

The first option in Acorn’s new Appearance settings is a checkbox for “Liquid Glass palettes”. This does the obvious thing on macOS Tahoe, and on previous versions of macOS this checkbox is disabled.

The second option is “Display images edge-to-edge”. This one works on all versions of macOS that Acorn 8.3 runs on. This is the fancy look where the toolbar floats above the content as if it was a delicate and beautifully manicured piece of glass. It also removes the bottom toolbar, so there’s maximal room for your pixels to shine.

I also reworked the tool palette so that it no longer takes up the whole left side of the window and instead floats above the canvas and gives more space for your image to be viewed. (And every time I look at it, it makes me think of MacPaint and its tool palette. What a great app that was!)

Acorn 8.3 is a free update for anyone who’s already purchased Acorn 8, and we also provide a 14 day free trial from its website. You should check it out and give it a try.

So what’s next? I plan on spending the next couple of months refining Acorn 8’s UI even more. Some things are missing from the edge to edge window look, and I’d really like to see those come back. And it’s also nice seeing how other apps adopt the new UI in Tahoe, and I’m gathering inspiration from that. I’m wanting to see what the developer community coalesces around when it comes to Liquid Glass. So expect Acorn’s UI to change a bit more as time goes on.

* Acorn 8.3.2 is out for folks who have purchased it directly from our store. If you purchased via the App Store, it’s currently waiting for review and should be out shortly.