Dottie: a native macOS pixel art editor (WIP)

by Matt Sephton — Thu, 28 Aug 2025 10:00:00 +0000

For the past several months I’ve been working on a pixel art app for macOS, with the goal of making it as much of a first class citizen and great Mac-like experience as possible. To that end it is fully native and built using Swift and SwiftUI, with a tiny bit of AppKit.

As with all the macOS apps I build, they start with a personal need. This one was to replace the aging and unsupported Piskel electron/web app. I like it and I loathe it, so I wondered if I could do better. My friend Jason Morley was the additional momentum I needed to actually get moving and try some things out—so thanks Jason!

A little bit of history repeating

I’ve been into pixel art since Deluxe Paint ST (yes, on Atari ST not Commodore Amiga!), and of course on the classic Macintosh. I also collect information about the multitude of Japanese “dot art” pixel art apps, which are quite different to the apps that I grew up with. All this to say that I already had a list of features I missed, pined for, or otherwise thought should make a return. Naturally, dithering should be a tent pole feature affecting all tools.

A dither smudge like the one shown below was last seen by me in 1992’s Multi Paint System (PC-98).

Look, Ma—no dependencies!

And as an additional constraint—which you may know I love to set for myself—I decided that I would use no packages or external dependencies, just system frameworks. Yes, that means I had to write my own colour picker (but, that’s my idea of a good time!) and some things took longer than just adding a package, but I can say that there is precious little wasted code inside this app. In fact, at the time of writing a single-architecture build of the app that has been readied for distribution still fits on a 3.5” 2HD floppy disk!

Pre-mortem

A full post-mortem will come after release.

The trickiest parts of development so far:

drawing pixelated circles of any width and height (all the classic graphics programming text books require the circle to have odd dimensions so that the coordinate of the centre pixel is an integer)
figuring out the intricacies of the document-based application model
trying to get the “New Document” button to appear on the file selector that appears at app launch (in fact this one still evades me for reasons I can’t figure out, get in touch if you can help!)
automating help book compilation (thanks Mario!)
performance bottlenecks with some aspects of SwiftUI (thanks WWDC Lab!)
surprise performance gains from using AppKit for better gestures
selections and marching ants
dealing with some bad early decisions (tech debt)

The most fun aspects so far:

designing and iterating on the UI
coming up with a name and brand
implementing palette management and trying new ideas
implementing a custom colour picker, twice
drawing the various tool and app icons
getting to a point where it feels done and every new feature is icing on the cake

One interesting thing about the app:

there is no settings window

Launching late-2025

I hope to launch the app this autumn, but until then: if you’re a pixel artist feel free to get in touch with your email address and I’ll send you a TestFlight invite!

Stapler: I remade a 32 year old classic Macintosh app

by Matt Sephton — Sat, 10 Aug 2024 21:00:00 +0000

The latest version of this app is now available as a free download on the Mac App Store.
More info on my apps website at: gingerbeardman.com/apps/stapler/

A couple of days ago I was reading on Hacker News about a feature in some Linux window managers where they allow collections of tabs from different apps.

This reminded me of BeOS, but at the same time it reminded me of an app from 1992 for classic Macintosh called Stapler, and how I’d talked about that and it’s one-time spiritual successor, LaunchList, in the past. These were both similar apps that allowed you to collect and launch all the apps, files, folders, documents, related to a specific task, thus saving time. Or as Ali Rantakari so succinctly put it in 2009: “Opening a Bunch of Stuff at Once on Your Mac”.

So over the past day or so I built my own take on this concept for modern macOS!

Whilst my app is inspired by both Stapler (right down to the name) and LaunchList, my app adds improvements and features of its own and is more of a hybrid of both. For example, Stapler didn’t have drag and drop and LaunchList didn’t have zero-click auto-launch. My goal was to keep it as simple as possible, but no simpler. To that end, there are no preferences or settings in the app.

Tell me more

The idea is you set up a Stapler Document per project containing related apps, files, folders, etc. Then you can open them all at once by launching the single document. Each document contains a list of aliases that can be managed, inspected, launched using the app. The key time-saver is that if you launch a Stapler Document directly, all the items in its list will automatically be launched. Cool!

Work: text editor, run current game, pixel art editor, bitmap font app, todo list
Play: Music app, Hacker News app, Twitter app, script to position windows
Movie: run Caffeine to keep your computer on, shortcut to put displays to sleep

It’s an odd way of thinking about working on a computer—it’s task-based rather than app-based or document-based. Indeed, some might say it’s an outdated way of approaching things. But I’m always banging the drum about there being so much good stuff that was prematurely left behind along with the memories of System 7 (though I still use that), BeOS, OS/2, Amiga Workbench, GEM and the many alternative desktops of Atari ST, etc. So I thought I’d see if I could walk the walk as well as talk the talk.

Details

It’s written in Swift and SwiftUI and weighs in at 640KB, about one third of which is a multitude of icon files at many different sizes and resolutions. By creating a Document-Based App you get a ton of functionality for free, such as document/tab/window management, undo/redo (though I still needed to watch for it and refresh the app window), and much more.

The editor is a native macOS window that’s kind of like list view in a file manager, or a spreadsheet, or a little folder…depending on your point of view. Plus some menu commands and keyboard equivalents. You can have multiple windows open at once, for example one window each for all your common tasks, giving you the ability to launch full tasks or parts of them with minimal effort.

The items in each list are macOS bookmarks (sometimes: security scoped bookmarks) which are a type of authorised/verified/secure alias (in fact, they’re still called aliases in the code) that have been around for about 10–15 years. They contain the path plus a bunch more info. As macOS becomes more locked-down the recommended way of accessing files is to retrieve these bookmarks through the normal layers of system permissions and security. Without the bookmarks, for example just using plain text paths, I would not be able to show the full images in Quick Look or easily launch the list items. A key benefit is that the bookmark will still resolve if the file is moved somewhere else on the same disk, or even to a different volume!

I store the items as JSON in the saved file, simply because I prefer it to XML (which is the main/default option). I wanted the files to still be human readable and editable to a degree.

The files are launched using the default app specified by that file, so it can be changed on a per-file basis. Individual images might open in an image editor, image viewer, app to run OCR, script to run OCR on it, etc.

Dealing with files was both cool and annoying, cool that you can get the bookmarks to files so easily, but annoying that you have to jump through so many hoops to work around the security and sandbox protections and end up having to do file requests in a long-winded way, and then there’s having to tweak plist entries to give the app just the right permissions. I’m using some features of SwiftUI that mean the app can’t run on anything before macOS 14 Sonoma. All-in-all I’d say modern macOS development is a bit of a mixed bag. Take it or leave it.

Bonus tip

Make sure to uncheck: System Settings > Desktop & Dock > Windows > Close windows when quitting an application

Then leave the windows of an app open as you quit it. When you next launch the app its windows will restore to their previous size and position. If you close the windows first, then the app will restore to having no windows open.

Thanks

My good friend Dave Roberts (Serendipity App Company) for brainstorming why it was so damned difficult to get the app to react differently when a document was opened from Finder. Rip it up and start again! To Dustin Mierau for kickstarting this trend of remaking forgotten old apps for modern macOS. And eternal thanks to Chris Patterson and Ali Rantakari for their apps.

Since launch

support added for macOS 12 and newer (was originally macOS 14 and newer)
new features added
omissions addressed
bug fixes
new icon on the way

Get Info: #swift