Custom icons for shortcuts alternatives: what you can drop

Making a custom shortcut icon takes longer than it looks. Find a square picture, clean up the background, export it at several sizes, assemble the bundle, attach it. An hour goes by. Then the result turns out to be the third tile from the left in the Dock, which your hand was already finding without looking.

That is the case for treating icon work as optional. Not always, but more often than people assume. The substitutes below produce the same outcome with a fraction of the steps, and the last section covers the cases where nothing substitutes and the artwork has to be made.

Name the job before making the picture

Nearly every request to make an icon is really one of three jobs, and they need different tools.

The first is telling things apart in a row of tiles. The second is having a single place to click that opens something. The third is not confusing two similar things with each other.

Telling things apart does not need good artwork, it needs difference. A tile that is a slightly different shade of blue from its neighbor fails, while a tile with one symbol on it succeeds, regardless of how the two were produced.

Having a place to click does not need artwork at all. Position carries this. Once a tile has held the same spot for a week, the hand goes there without the eyes checking what is on it.

Only the third job, avoiding mix-ups, rewards detail in the picture, and only when the two things are genuinely similar. Two accounts on the same service is the classic case, because both pick up identical artwork automatically and no amount of care in choosing the image helps when the image is the same on both.

Deciding which job is in front of you takes a minute and frequently removes the entire image pipeline from the plan.

Color, symbol, or emoji, with no image file

Finder can change how a folder looks without any picture being involved. Apple's documentation describes the range.

You can customize how folder icons look with colors, symbols, or emoji, or choose a custom icon for any file or folder using your own pictures, icons downloaded from the web, or the icon from another file or folder. Source: support.apple.com

The appeal is that there is no sourcing step. Pick a color, add a symbol, done in seconds. Resolution never comes up, because system symbols are drawn to stay crisp at whatever size they render.

There is a boundary. The same page notes that while the Home folder can be customized, the folders that ship with macOS cannot, naming Applications, Library, System, and Users. For folders you created yourself, which is what most daily work lives in, that limit rarely bites.

Tags do similar work from a different angle. A colored tag lets the Finder sidebar filter by color, which shortens the act of finding rather than changing the look of the thing being found. When the goal is telling things apart, that is the same result reached more cheaply. Worth trying before opening an image editor.

Let the site hand over its own artwork

For websites, the browser routes supply artwork automatically, which deletes both the sourcing step and the resizing step.

Apple's web app feature captures the site's artwork at the moment the app is created, and the app then holds that icon as its own setting. From the same documentation, a web app can carry any name or icon you want, and the settings window exposes the icon directly so a different image can be chosen later. The practical shape is: create it now, adjust only if the result bothers you. Most of the time it does not.

Chromium browsers take the artwork from what the site publishes, and keep taking it. Chrome's help explains that when a web app wants to update its name or icon, a notification appears and the update can be accepted, ignored, or the app removed. Ignoring holds the current look, at the cost of a prompt each time the service changes its branding.

The difference matters when picking. Borrowed artwork that the service can update is fine for a service whose branding you do not care about. Artwork pinned at creation is better when the look needs to stay still. Neither requires making anything.

If you open by typing, nothing is looking at the icon

How a thing gets opened changes how much the icon is worth.

For anyone who opens apps by typing a few letters into a search field, the artwork is close to irrelevant. Two or three characters narrow the list, then Return. In that workflow the thing worth tuning is the name, not the picture. Short names whose first characters do not collide with anything else cut keystrokes immediately. If a production and a staging copy of the same service both exist, putting the distinguishing word at the front matters, because a suffix does nothing until the whole name has been typed.

For anyone who opens from the Dock, position does the work. Keep the order stable and the hand learns it. Elaborate artwork adds very little on top of a stable position, while reordering the Dock undoes a week of muscle memory no matter how good the pictures are.

For anyone cycling with the app switcher, names appear alongside icons. Similar artwork is survivable when names are clear. Again the fix, when there is a mix-up problem, is usually in the name field.

None of this argues that icons are worthless. It argues that in two of the three common ways of opening things, the icon is not what is being used, so time spent on it does not come back.

Things other than artwork that mark a window

Artwork is not the only signal available. The window itself carries several, and none of them require an image.

Apple's web app feature includes a setting for whether the title bar takes its color from the website. With that on, a row of open windows can be told apart by the strip along the top, before the icon enters into it. Switching from one to another produces a visible color change, which registers faster than reading a tile.

Unread counts are another. The same documentation describes a red badge on the Dock icon showing the number of unread notifications for a web app, with one important detail attached: the notification permission has to be answered inside the web app rather than in the browser for the badge to appear. Two tiles carrying identical artwork are still distinguishable when one of them is wearing a number.

Window size and placement do quiet work here too. A window that always opens at the same size in the same spot gets recognized by position before anything on it is read. On a Mac where work is split across separate spaces, fixing which space a thing opens on removes most mix-ups on its own, with no visual change at all.

Each of these costs a setting rather than an image. Checking them before opening an editor tends to shorten the list of things that genuinely need artwork.

What each goal actually costs

Goal	Cheapest route	Step you can drop
Spot a folder in a list	Color plus a symbol	Sourcing and exporting an image
Open a site in one click	Add it through a browser	Making artwork at all
Open by typing	Fix the name's first characters	Everything icon related
Separate two similar tiles	Put a symbol on one	High resolution export
Keep a look for years	Artwork stored inside the app	Repeated reattaching

Only the bottom row justifies the long route. Everything above it reaches the same outcome with less work, and the saving compounds with volume: one item is a minute either way, while ten items is the difference between a few minutes and an afternoon.

The thing you never have to find

There is one substitute that removes the problem instead of solving it: having the thing already open.

Apple's documentation points out that a web app can be added as a login item so that it opens automatically at login. For a destination visited every working hour, that changes the question. Nothing has to be located in a Dock or typed into a search field, because the window is already there from the moment the machine is ready. The icon's job shrinks to appearing in the app switcher, where the name is doing most of the identification anyway.

This suits a small number of things and suits them very well. Two or three destinations opened constantly are good candidates. Ten is not, because ten windows open at login is its own kind of clutter and the hunting problem simply moves from the Dock into the switcher.

The honest framing is that decorating a launcher is worth effort in proportion to how often the launcher gets used. For the handful of things that are open all day, the launcher is used once. Spending an hour on artwork for something clicked once a day, at startup, is the clearest case of effort going somewhere it will not be seen.

Where nothing substitutes

Three situations require making the artwork, and recognizing them early avoids both wasted effort and a bad result.

The first is the same service open under two accounts. Automatic artwork gives both tiles the same picture, so they are indistinguishable in the Dock and in the switcher. One of them has to be changed by hand.

The second is an internal tool. Company dashboards, admin panels, and client systems frequently publish no artwork whatsoever, sometimes not even a favicon. There is nothing to borrow, so something has to be supplied.

The third is anything that must not revert. Artwork attached to an item as metadata goes away when the item is replaced by an update, which makes it a bad fit for anything on a release schedule. Artwork stored inside the app does not have that problem, and reaching that state is worth the extra steps for things opened daily.

Outside those three, dropping the image work costs nothing measurable.

Checking what is already covered

Tools that turn websites into standalone Mac apps accumulate a registry of which services people actually split out, stored as name, URL, and artwork together. Where a service is already in such a registry, both the sourcing and the sizing steps disappear for that service. The supported services list is the fastest way to check how many of your daily destinations are already covered.

For anything not on such a list, an internal timesheet system being the usual example, artwork gets specified by hand. What can be set per app, including the name and window behavior alongside the icon, is laid out in the features overview, and the steps themselves are in the guide.

What to change first

List the sites you open every day, and write next to each one whether the goal is spotting it, opening it, or not confusing it with something else. Assign image work only to the third kind, and to anything that must survive updates. For the rest, a color, a borrowed icon, or a better name finishes the job in under a minute, and if the list turns out to be long, Kagemusha is one of the tools built to handle the whole set at once.