Monday, September 7, 2026

McKinley 1.0

Amy Worrall (Mastodon):

McKinley is an all-in-one studio for drawing and annotating SF Symbols. It bundles vector tools with knowledge of the SF Symbols structure, so you can edit one set of objects across multiple weights, sizes and colours. Import SVG or start from scratch, live preview your work using Apple’s own renderer, and export directly to Xcode, so you never need touch the SF Symbols app again!

[…]

Gone are the days of converting your strokes and shapes to outlined paths before export. Keep everything how you drew it, and let McKinley handle the output.

[…]

Link your project’s asset catalog to your McKinley document. Then when you make a change, hit the Sync keyboard shortcut and it’s immediately populated with your latest version.

[…]

McKinley is a Mac-assed Mac app: a native AppKit UI, Quick Look previews and thumbnails for your documents, a full AppleScript dictionary for batch work, and the whole user guide offline in Help.

$60, no subscription. It’s been a while since I had to deal with custom SF Symbols, but I remember it being a major pain. I haven’t had the chance to try McKinley with a real project yet, but it looks very well done. I love seeing a new app ship with documentation and extensive AppleScript support, including sample scripts that you can install right from its script menu.

Mario Guzmán:

The icon isn’t just a symbol but a whole artistic creation on a canvas.

Look at how your tools are on panels that could be individually opened on their own auxiliary window. I can’t stand the single-window, everything buried into a single-sidebar design we get these days.

Amy Worrall:

SF Symbols rendering does a surprising amount behind your back: it interpolates nine weights from three masters, applies optical size adjustments, resolves hierarchical opacity ladders, and changes some of this between OS releases. Any preview I rendered myself might diverge from the real thing in ways nobody would notice until the symbol was in an app looking subtly wrong. (Obviously I aim to get my canvas rendering with the exact same nuance as Apple’s renderer, but programmers are fallible and the fewer ways things can diverge, the better.)

Apple provides no API for “here’s my SVG, render it as a symbol”. For a normal app using a custom SF Symbol, the symbol is compiled from an Asset Catalog in Xcode into a .car file (a compiled asset catalog) at build time. But there’s no ‘build time’ when I want to update a preview in McKinley.

My workaround involves compiling your symbol into a .car file at runtime, on every edit, by patching bytes into a template, then loading that temporary .car file into McKinley via NSBundle.

Previously:

Update (2026-09-08): John Gruber:

I mean just look at McKinley. It’s both beautiful and quite obviously a serious professional tool.

Update (2026-09-11): Amy Worrall:

Anyone used any great implementations of dockable palettes? (Adobe’s don’t count, I don’t think they’re great!)

I’m not going to go back to sidebars, but some kind of options/flexibility might work, if it doesn’t get in the way!

19 Comments RSS · Twitter · Mastodon


I think Amy's is one of those sleeper apps that's going to influence a lot of creators over the next few years. Including those at Apple.


Looks utterly native without looking outmoded and boring, that's a rare feat! 👏🏼


I do a bit of SVG work but not in SF symbols so do not seem to be the market for McKinley. I do however do printed work, including weird free mini-zines and am definitely the market for Octavo! Glad to be following the developer and getting to use one of her apps.


I recently had success using Claude to generate that template that normally the SF Symbols app uses. I had an SVG that I wanted as a custom symbol, and just asked it to find the actual symbols in an existing template and replace just those with the SVG, modifying the lines to have a progressively higher weights. It did a good job at it. I understand this is more than just import SVG -> export template, but 60$ sounds somewhat steep for something that can be achieved by using open source vector drawing tools and then throw at LLM to put them in and even adjust weights.


Hi Léo!

As a specialist tool it's not for everyone. There's a few cheaper options on the App Store if all you want to do is vary the line weights of an SVG, and I won't begrudge you choosing one of those instead of McKinley.

I made the choice to build an in-depth tool with high production values, and not participate in the race to the bottom. There's room for multiple options in the market!

Amy

P.S. i am running a 15% launch week discount at the moment, so the current price is $51 :)


Hi Amy, I really did not mean to disrespect you or your work. This new world is crazy, and we are navigating our way in it. I wish you good luck!


Don't worry, I didn't read it as disrespectful! I genuinely mean it that not everything is for everyone. And I'm trying to figure this out as well.

I guess I'll see over time whether I pitched things right :)

Amy


Wow, the software author is here in the comments! Congratulations, this looks great, I picked up the launch deal this afternoon, I appreciated the easy purchase via Apple Pay. I was very glad to see it runs on Sequoia, which I am still running. I couldn't find any information on your site as to what minimum system it supports. I would love to see a blog about what the development process for this app was, and the various choices and issues you encountered along the way. Best of luck with this new venture!


McKinley looks amazing. If it works as advertised (judging by the care that went into the production of the user guide, it probably does), this streamlines the creation of SF Symbols by orders of magnitude, effectively leaving the designer with the fun parts while eliminating the parade of tedious, repetitive steps.
I don't have an immediate use for it, but the next time I'm asked to draw more than a small handful of SF Symbols, this should be a no-brainer. $60 seems fair.


No one gets to claim their "Mac app" is "Mac Assed" if they're shipping a single window iPad screen, without tear-off palettes and the ability to have multiple open documents, and the UI broken up and splayed across multiple displays.

Amy's shown the better, more traditional paradigm is still perfectly viable, and frankly made people who've been loud about how *Maccy* their Mac apps are look a bit undeservedly self-regarding.

I would rather pay $60 for that, than $5 for an iPad app that does the same things. Hell, I paid the equivalent of today's USD$3.2k for Quark XPress a little over 30 years ago.


@Someone I generally agree with your Mac Assed take. But there's a lot of good Mac apps that aren't Catalyst crap or SwiftUI slop and use a single window paradigm or don't have tear off palettes.

Often, I need a control for a moment and then want it gone. Palettes are annoying for transient interaction since you need to manually close them and they obscure a lot on smaller screens.

How do you feel about Popovers versus Palettes, especially if the Popover cannot be torn off?


@Hammer It's like this - if an app has an inspector palette / sidebar, that should be able to be torn off. If that inspector has multiple vertically separated sections, those should be able to be broken out as separate palettes.

The issue isn't forcing people to have separate palettes and windows if they don't want them, it's that this was a solved problem 30 years ago; all apps could break out their palettes (even pop-out palettes that hid in the border meat of the window). But in the intervening time, some lazy, do-less-work frameworks have been created, which never bothered to implement the idea that an application would require separate windows, and the communication needs that would necessitate.

Personally, I put that down to Apple's enthusiastic embrace of Windows conventions, in an attempt to attract "switchers". It went so well (and the labour shortage from the iPhone project meant employing a lot of formerly Windows developers), that a UI / UX culture that has a lot more in common with the windows Single Window paradigm has become dominant amongst the Apple developer community.


...by "vertically separated" I mean vertically stacked on top of each other.


Good luck achieving that with SlopUI. Document window management is already so ridiculous and cumbersome already, with responder chain and menu management basically broken by default. Good luck adding panels.


@Someone — this is, I think, my greatest sadness with macOS — they hired people who don't understand multi-window work (either because they came from Windows, or, perhaps, because they grew up with iPhones and Android phones), and those people have ruined much of the interface. I mourn the titlebar — where am I supposed to grab a window to move it these days?


@Someone It was solved problem in that a bunch of popular apps did it, and it worked well, but Apple never provided framework support. And then popular apps from Apple and others brought the iOS style back to the Mac.


I'm surprised (and pleased) the developer was able to keep (most of) the window titles properly centered, successfully resisting Tahoe's left-aligned megalomania. I'm starting to suspect Dye secretly loved Windows, which would explain why he copied this and its bland hand cursors into Tahoe. Thankfully Golden Gate seems to fix the cursors, and I can only hope the title bar text is next!


I didn't do anything special for the centred titles, I just used window styles (tabbed toolbar Settings style, and NSPanel for palettes) that nobody at Apple has bothered to update to be left aligned :)


Thanks for the response, Amy! I hope your new app really succeeds and it finds many users.

Leave a Comment