feat: support Icon Composer files as icon input for macOS

[MarshallOfSound]

Validated locally but impossible to test in CI as it requires Xcode@26 beta.

This adds support for the new Icon Composer icon format in macOS 26 which is required in order to get liquid glass icons. Command for actool was reverse engineered by intercepting xcode's internal build commands and identifying the magic incantation to build icon files correctly.

In order to support both macOS >= 26 and macOS < 26 you must provide icon: ['old.icns', 'new.icon'] as your config, pretty simple tho.

Note for anyone trying this, it requires Xcode@26 but 26b3 is currently busted, you have to use 26b2 or 26b1

[dsanders11]

Since this is something new that apps are going to need to do to get the Liquid Glass icons in macOS 26, we should try to make this new functionality higher visibility so folks can easily find it.

Should we add it to docs/faq.md? And maybe plan a blog post for more visibility.

[MarshallOfSound]

@dsanders11 Worth noting that so far I've only gotten this working with super specific versions of Xcode 26 beta and only on macOS 26 itself.

[malept]

Does the CLI work as expected with specifying both old and new macOS icons?

To me, the API change to allow an array feels kinda bad - this might be an impetus to update icon to instead take either a string or a typed object:

export type IconOptions {
  darwin?: string
  // Open to new name, largely a placeholder
  darwinLiquidGlass?: string
  win32?: string
}

export interface Options {
  // ...
  icon?: string | IconOptions
  // ...
}

The advantage to adding an object instead is that it should be automatically parsed by yargs-parser correctly.

[MarshallOfSound]

Does the CLI work as expected with specifying both old and new macOS icons?

Haven't tested the CLI but assuming it converts multiple incantations to an array of strings it will work just fine. I also thing we don't need the array if we're ok requiring people to do path/to/foo and having foo.icns and foo.icon.

I agree an object is a good end state here, but I think that requires some more careful thought, i.e. darwinLiquidGlass is not good naming, the .icon format is more generic than just lg support

[malept]

I agree an object is a good end state here, but I think that requires some more careful thought, i.e. darwinLiquidGlass is not good naming, the .icon format is more generic than just lg support

Yeah, I figured as much but I have no context for what the key should be named, so I deliberately annotated it as a placeholder in the comment.

[continuous-auth]

🎉 This PR is included in version 18.4.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀