[macOS 26 | Icon Composer] Allow providing an Icon using a `.car`-file

[nathanlesage]

Preflight Checklist

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

It is nice to see that Electron packager now supports Liquid Glass icons. However, the dependency on having XCode installed is a bit iffy. Especially for developing Electron applications, most of us don't really need those 12 GB, especially not if all we need is a small icon. Furthermore, the current setup prevents anyone from compiling the app for macOS 26 if we are using, say, GitHub Actions, or essentially any CI image that doesn't ship with XCode.

I took a look at the code, and found that what the new code essentially does is check for the presence of an .icon-folder in the icon property, and proceed to compile the icon down into an Asset catalog using actool which is where the dependency for XCode comes from.

However, usually, icons don't change. And if they do, I don't think its too much to ask users to re-compile the Icon composer file once more into such an asset catalog. But as long as the icon doesn't change, it should be usable within CIs, automated build pipelines, or without having XCode installed.

Proposed Solution

I propose to allow to provide a compiled asset catalog directly as an alternative to the .icon source.

This would slightly increase complexity (as we then have the alternatives .icns, .icon, and .car), but I believe that this would make the new design language more accessible to many more people.

Essentially, Electron packager should simply skip the actool compilation if there is a .car-file in the icon string array. If there is an .icon-file, it should compile that to .car using actool and use that one.

Alternatives Considered

I looked up the installed software on GitHub's runners, which I use, and they only ship with the command line tools, so there's actually no way of adding a Liquid Glass icon and continuing to use the CI for mac exports.

Additional Information

I'll be seeing to downloading XCode later today to get this compiled .car-catalog, and see if there's any downsides to that approach, although I can't see any right now.

[welcome]

👋 Thanks for opening your first issue here! If you have a question about using Electron Packager, read the support docs. If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. Development and issue triage is community-driven, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[nathanlesage]

Small update: I've now dabbled around a bit, and what I found is that, once the Assets.car file has been compiled manually, I can stuff that into packager's extraResource which ensures it is signed and moved to the correct file. Also, I've noticed in the feature PR that one has to provide an additional plist entry, CFBundleIconName. I have done so in my Info.plist file that is used to enhance the app's plist in packager's extendInfo property, but that unfortunately doesn't yield the correct result and the app falls back to the old ICNS file.

I'm not exactly sure what the issue is here, and I'm happy for any pointers.

[nathanlesage]

So, that took very long, but I figured it out. So, providing the car-file manually is actually easier than I thought, and simply requires a different workflow than by providing the .icon-file to the packager config.

Here's what works:

1. Manually generate the Assets.car-file on a computer with XCode installed. Note the filename of the icon file (e.g., MyAwesomeIcon.icon), because that is what actool will use to name the asset.
2. Provide the key CFBundleIconName to the PLIST file using the extendInfo property, using as value the icon filename (sans extension).
3. Provide the path to the Assets.car-file in the extraResource property.

Also, I think I found a few arguments that aren't really necessary. Here's the command I used, which worked flawlessly:

actool $ICON_PATH --compile $OUTPUT_PATH \
  --output-format human-readable-text --notices --warnings --errors \
  --output-partial-info-plist $PLIST_PATH \
  --app-icon Icon --include-all-app-icons \
  --enable-on-demand-resources NO \
  --development-region en \
  --target-device mac \
  --minimum-deployment-target 26.0 \
  --platform macosx

Where would this info be suited to provide to others?