Skip to content

Conversation

@Eitot
Copy link
Contributor

@Eitot Eitot commented Jan 11, 2026

No description provided.

@barijaona
Copy link
Member

Thanks for this.

Unfortunately, 38dd321 has no effect: as soon as there is a .icon bundle, it takes over any .iconset left.
So you get the macOS Big Sur icon style on all system versions.

@barijaona
Copy link
Member

I noticed that the asset catalog and the application produced by Xcode through processing of the .icon file are respectively 1 Mbytes heavier than the ones we introduced in 709e440 which were post-processed via icns creator and ImageOptim…

The disk image weights 9.1 Mb instead of 7.9 Mb…

Not convinced the Apple way of doing things is worth it on this.

@Eitot
Copy link
Contributor Author

Eitot commented Jan 23, 2026

The problem with using Asset Catalog instead of Icon Composer is that it won't support a dark-mode icon or tinted icon in macOS 26. Based on the discussion here, it doesn't seem to be possible to have the old-style icon when using Icon Composer (there was a workaround in Xcode 26.0, but that has since been patched out by Apple).

38dd321 is only for backward compatibility with Xcode 16 (which doesn't know about .icon files), Xcode 26 ignores it.

Another thing I found out about: AppIcon.icns is actually not what macOS uses to show the app icon, it uses the Asset Catalog since macOS 10.13. The AppIcon.icns file is only there for other apps to use.

@barijaona
Copy link
Member

38dd321 is only for backward compatibility with Xcode 16 (which doesn't know about .icon files), Xcode 26 ignores it.

That leads to builds based on Xcode 16 and Xcode 26 presenting different icon looks… Keeping in Asset Catalog what is currently in master branch would make more sense.

@barijaona
Copy link
Member

The problem with using Asset Catalog instead of Icon Composer is that it won't support a dark-mode icon or tinted icon in macOS 26.

Personally, as far as Apple's default setting for icons and widgets style remains "default", I can live with that.

I agree with the prevailing opinion that the design of macOS Tahoe was hastily developed to divert attention from Apple Intelligence's delays.

I believe we should ignore the “new features” as much as possible and reassess the situation when macOS 27 is available. Hopefully, Alan Dye's departure from Apple will have had an effect by then.

We've already released our icon from the “jail of hell,” so we can leave it at that.

@TAKeanice
Copy link
Contributor

@barijaona which features exactly do you want to ignore? Regardless of how finalized the design is, I don't believe that dark mode or tinted icons are going away, and these options should be provided.

@Eitot
Copy link
Contributor Author

Eitot commented Jan 24, 2026

I don't think that saving 1 MB is enough to give up on dark/tinted icon support. I agree that it is unfortunate, but it is not severe enough for me.

Side node: The biggest contributors to Vienna's bundle size are the bundled Swift dylibs for macOS 10.13–10.14.3 (~11 MB), which aren't used by macOS 10.14.4+.

@barijaona
Copy link
Member

Thé missing feature is the dark icon which current version of Tahoe is unable to display correctly.

I will explore the possibilities of actool, because I expect macOS to use the vectoriel version of the icon for Tahoe, and the current (optimized) PNGs for older systems.

But currently we always get the PNGs as the system's starting point.

barijaona and others added 2 commits January 27, 2026 19:50
The `AppIcon.icon` bundle is the same as the one used for PR ViennaRSS#2009

As of Xcode 26 / Icon Composer, the `.icon` bundle is sufficient basis
to get the vectorial renderings used for Liquid Glass, and also the
bitmap files needed by former versions of macOS.
However, we also maintain the `AppIcon.appiconset` bundle resource which
is needed by Xcode 16 for building and running some of our Github tests.
@barijaona
Copy link
Member

I don't like how Apple is forcing on us a non optimized solution but…

@barijaona barijaona merged commit ffeedd3 into ViennaRSS:master Jan 28, 2026
2 checks passed
@Eitot Eitot deleted the feature/app-icon branch January 28, 2026 13:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants