McKinley aims to be a comprehensive tool for working with SF Symbols. However there are few things it cannot do (yet), and it’s important to be transparent here.
The SF Symbols app and APIs can accept a symbol SVG with content for three weights (in which the other six are interpolated), or alternatively for all nine weights.
McKinley only supports the three compulsory weights, and always assumes the others will be interpolated. This is by far the most common way SF Symbols are created, so we deemed it a reasonable tradeoff for simplicity.
SF Symbols works with three sizes of symbol. (These sizes are how the symbol is sized relative to the surrounding text. You can scale any of the ‘sizes’ to any physical size if you’re not interpolating with text, of course.)
It is possible within the SF Symbols format to supply different vectors for the different sizes. However, McKinley enforces the same vectors for all sizes. The ‘size’ control on McKinley’s toolbar only adjusts the sizing of the base/cap lines and the preview text next to your symbol on the canvas, so you can see how the same vectors will look at each of the sizes.
For the most part, the fact that McKinley objects have the same vector points across all weights (but the points can be in different places, and strokes can have different widths, etc), means that interpolation for the in-between weights works as expected.
However there are a few situations where it may not. The main ones are, use of clipping masks where the mask reveals a topologically different shape in different weights, or use of different fonts in the different weights where the font letter forms are topologically different.
McKinly’s preview panel will always show you what Apple’s renderer will do with your symbol. In addition, if McKinley cannot output interpolatable data from your document, it shows an exclamation mark in the bottom left corner of the canvas, giving you advance warning of what is going wrong.
This feature of SF Symbols lets you specify how to animate your symbol in or out such that it looks like it is being hand-drawn onto the screen. This can also be used with the ‘variable value’ symbols, e.g. for a thermometer with varying mercury level.
McKinley straight up does not support this at the moment. Unfortunately, we don’t have a way of editing the drawing metadata, nor of outputting it. This is planned for a future update.
When importing an existing Apple SF Symbol into McKinley, you have the option to “Infer converting paths back to strokes”.
As you no doubt know, all of Apple’s symbols are drawn as outlined shapes. If the checkbox is off, then an Apple symbol is imported into McKinley exactly as it is.
But it might be nice to be able to edit Apple symbols in a more idiomatic way, i.e. with stroked lines and shapes rather than just outlined paths. This checkbox enables a feature that attempts to derive which stroked lines/shapes Apple may have used to create their symbols.
It should be noted that this is not always possible, and McKinley always errs on the side of not doing an inference if it cannot do one that will accurately depict the symbol. So you may find for some symbols that this checkbox doesn’t produce the results you wanted.
One reason for this is that sometimes Apple tweak their symbols’ outlines, so they cannot perfectly match a collection of lines. Apple symbols that include arrow shapes often do this.
But sometimes it’s just too complex to infer how a certain shape might have been constructed from lines. McKinley’s inference is best with shapes made of straight lines (with a standard rounded endcap) or regular smooth curves. Again, if McKinley cannot infer a way to construct a shape out of lines, it will fall back to just including the original shape verbatim.
McKinley is not a ‘library’ based app. You make a new McKinley document for a symbol and each of its variants. To that end, you give the main symbol its own symbol name, and all the variants within the document have a name that is the symbol name with a suffix.
This was a design choice when building McKinley. My suggestion is that you commit the .mkc files (native McKinley format) into your repo as a source of truth.
Because McKinley works with vector data that SF Symbols rejects (such as stroke widths), only McKinley’s native .mkc format can preserve this data. When a McKinley file is exported to SF Symbol format, the strokes are all converted to outlines, as SF Symbols expects. Thus, if you import an SF Symbol format file back into McKinley, you will have lost some fidelity.
The solution is to keep your .mkc files around and work with those until export time.