Icons turns one image into a whole macOS app icon set

Why an icon set is more work than it looks

The problem the project names is mundane and real. Making a macOS application look professional means producing a family of images, not one file, and the README states that Icons is an application for macOS which enables you to create standardized app icons in PNG format with no graphic skills needed. You drag and drop your desired image into the application and it creates a full icon set, including the installer and uninstaller icon, as well as an animated version of the uninstaller icon. The description in the repository puts it in a business context rather than a hobbyist one, since it is for your company's internal app store. The point of the tool is not that it makes pretty icons, it is that it makes complete ones. A designer gives you one square image, and every other artefact in the set has to be derived consistently, and doing that by hand for every application is the tedious part. The repository description makes the promise plainly: Icons for macOS is the easiest way to create customized app icons in PNG format for your company's internal app store, no graphic skills needed.

Banners are the feature aimed at Mac administrators

The second half of the README addresses a different user, and it is the more interesting half technically. For Mac administrators working in multiple environments, such as development, test and production, the Icons app helps you keep track of your app versions by giving the option to add banners to the icons. A banner is a strip on the icon that says which environment a given copy belongs to, and when the same application is installed three times on a machine or handed to three teams, the icon is the only place the difference is visible. That is a real problem in a managed fleet, where the visual distinction is often the only thing separating a test build from a production one, and it is a problem that asset pipelines tend to solve badly. The feature list also names a custom delete badge for the uninstall icon, which is the same idea applied to the artwork a user sees when they drag an application to the trash. So the tool has two audiences with two reasons to use it, which is worth knowing before you decide whether it is the right size for your problem.

The feature list, including the automation escape hatch

The features section is a bulleted list and several items carry more design information than they appear to. There is a Finder extension, which is what makes the drag and drop work without leaving the desktop, since the drop target is the file system itself rather than an application window. There is a highly customizable banner, and easy drag and drop function. There are install and animated uninstall icons, and a custom delete badge for the uninstall icon. There is Image Playground integration to create icons from scratch, which is a macOS system tool, so the tool can start from nothing rather than from an existing asset. The one that matters for a packaging pipeline is the last: a command line for automation. Without it the tool is a desktop application you use by hand, one icon set at a time, and with it the icon generation becomes a step in a script. The final line of the feature list is the platform constraint, that it runs on macOS 13 and newer, which sets the floor for every deployment and is worth checking before you wire it into a build server.

The output: three PNGs you can point a package at

The example section shows what the tool produces, and the naming is the useful part. The first image is install.png, the second is uninstall.png and the third is uninstall_animated.png, and the README says all images are saved in PNG format. Those three names map directly onto how a macOS installer package is assembled, where the icon shown on the disk image or the installer application and the icon shown in the trash are separate assets, and an animated variant is a different file format again, since a still PNG cannot animate. The fact that the tool emits an animated uninstall icon at all is the detail that distinguishes it from a simple resizer, because that asset is the one most people forget until a user complains that the trash icon does not match the application. The repository listing shows a source/ directory holding the code, a LICENSES/ directory for the third party licence texts, a REUSE.toml file for the REUSE metadata, and a readme_images/ directory with the example and banner artwork. There is no separate assets or icons directory at the top level, which is consistent with a project that generates its output rather than shipping a library of templates.

Installing it means the wiki, and the project is as-is

The README does not contain installation commands, and it says where to find them instead. To learn about the Icons features, take a look at the wiki, and the pages linked from the README are Installation, Uninstallation, Using Icons and a FAQ. The top level listing does not show a build system or a package manifest, so this is a distributed application rather than something you build from the repository, which is consistent with the primary language being Objective-C and the audience being administrators on a Mac. Two things in the closing sections deserve attention. The support statement is unambiguous: this project is as-is with no support, no changes being made, and you are welcome to make changes to improve it but the maintainers are not available for questions or support of any kind. If you plan to depend on this in a shipping pipeline, you are depending on an artifact that will not receive fixes, which is a different proposition from depending on a maintained project. The licensing is clearer. Copyright is held by SAP SE or an SAP affiliate company and the Icons contributors, the project carries an Apache-2.0 LICENSE file, and detailed information about third party components and their licensing is published through the REUSE tool, with a REUSE status badge in the README. Security issues have their own reporting policy page.

How it compares to doing the resizing yourself

The alternatives split into three, and the differences are about what you are willing to write. A script that resizes one image into the required set is the smallest option, and it is a few dozen lines in any language with an image library, which gets you the sizes but not the installer and uninstaller variants, not the animated file, and not the version banners, so you would be reimplementing the parts that are the reason the tool exists. A design tool gives you the full set with the most control, and the cost is a designer in the loop for every application, which does not scale to a catalogue of internal tools. A managed icon service or an icon set you buy once covers the static artwork but not the environment banners, and it leaves the animated uninstaller asset unsolved. The approach this project takes is different again, in that it treats the icon as a build artefact rather than a design artefact, with the image as the only input and everything else derived, which is what makes the command line path possible. The trade is that the output is standardised, so your applications look consistent with each other rather than distinctive, and the set of designs it produces is what the tool ships rather than something you can art direct freely.

Editorial conclusion

Icons suits a Mac administrator or developer who ships internal tools and needs a consistent, versioned icon set for every application they package, because it turns a single image into the full set including the installer and uninstaller artwork in one step. It is the wrong tool if you only need one application icon, since a designer and a resizing script will do, and it is the wrong tool on anything older than macOS 13, which the feature list names as the minimum. Before you build it into your packaging pipeline, read the wiki pages for installation and uninstallation, and check the licence terms, since the project is published under Apache-2.0 with REUSE metadata listing the third party components, and the support statement is that it is provided as-is with no support and no further changes.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. SAP/macOS-icon-generator on GitHub