Adding a data point that should help narrow this down. I'm hitting the same nil-objects assertion described in this thread -[IBICAbstractPlatformAdapter selectCatalogIconComposerItemsFromCollection:...] on Xcode 26.5 (17F42), macOS 26.5 (25F71). Two findings from local testing: The crash is content-independent. I tested 13 .icon variants: bare {} icon.json with no Assets/, empty groups: [], single layer with no glass, sRGB instead of display-p3, watchOS removed, --platform macosx instead of iphoneos, etc. All 13 produced the identical backtrace. Standalone repro (no project required): mkdir /tmp/foo.icon && echo '{}' > /tmp/foo.icon/icon.json mkdir -p /tmp/out xcrun actool /tmp/foo.icon --compile /tmp/out --platform iphoneos --app-icon foo --output-partial-info-plist /tmp/p.plist --output-format human-readable-text The crash fires before actool parses the icon content. The mere presence of a .icon directory as input is enough. The regression was introduced after Xcode 26.4.1. I side-installed Xcode 26.4.1 (17E202) and ran the exact same actool invocation against the exact same .icon bundle. 26.4.1's actool processes the .icon cleanly — no nil-objects crash, downstream behavior is sensible (errors on missing PNG fallback assets, which is what one would expect for a deployment-target back-compat path). 26.5's actool crashes 100% of the time on any .icon input. So the regression lives between actool 17E202 (works) and 17F42 (crashes), inside AssetCatalogFoundation / IBPlatformTool. Public reproducer (Expo SDK 55 + an Icon Composer 1.5 .icon, README walks through the standalone repro and the bisect): https://github.com/olarcher/expo-actool-liquid-glass-bug I filed a fresh Feedback referencing FB20183399 with the bisect data, since that ID is private to its filer. Hopefully more reports + concrete bisect helps prioritization.