Xcode 26 RC unable to compile asset catalogs on CI

Question

Created Sep ’25

Replies 5

Boosts 2

Participants 5

This started with Xcode 26 beta 7, however it has continued to occur with the release candidate. Whenever I try to compile our asset catalog + icon composer icon for our AppKit/SwiftUI-based macOS app, actool fails with the following exception:

*** Terminating app due to uncaught exception 'IBPlatformToolFailureException', reason: 'The tool closed the connection (AssetCatalogAgent-AssetRuntime)

Last command:
_ON_QUEUE_sendMessage:toChannelReturningError:during:

Backtrace of last command:
  0   -[IBAbstractPlatformToolProxy _ON_QUEUE_sendMessage:toChannelReturningError:during:] (in IDEInterfaceBuilderKit)
  1   __74-[IBAbstractPlatformToolProxy sendMessage:toChannelReturningError:during:]_block_invoke (in IDEInterfaceBuilderKit)
  2   _dispatch_client_callout (in libdispatch.dylib)
  3   _dispatch_lane_barrier_sync_invoke_and_complete (in libdispatch.dylib)
  4   DVTDispatchSync (in DVTFoundation)
  5   -[IBAbstractPlatformToolProxy sendMessage:toChannelReturningError:during:] (in IDEInterfaceBuilderKit)
  6   -[AssetCatalogRemoteAgentProxy compileItemsWithCatalogRelativeIdentifierPaths:tagSolutionSpace:andStickerPacksWithCatalogRelativeIdentifierPaths:options:] (in IDEInterfaceBuilderCocoaTouchIntegration)
  7   -[IBICLARToolCARCompiler compileCARItems:tagSolutionSpace:options:queue:completionHandler:] (in AssetCatalogCocoaTouchKit)
  8   -[IBICAbstractPlatformAdapter compileCARItems:tagSolutionSpace:options:queue:completionHandler:] (in AssetCatalogFoundation)
  9   __84-[IBICAbstractPlatformAdapter compileSelectedItems:options:queue:completionHandler:]_block_invoke (in AssetCatalogFoundation)
 10   __93-[IBICAbstractPlatformAdapter compileStandaloneCatalogItems:options:queue:completionHandler:]_block_invoke (in AssetCatalogFoundation)
 11   __DVT_CALLING_CLIENT_BLOCK__ (in DVTFoundation)
 12   __DVTDispatchAsync_block_invoke (in DVTFoundation)
 13   _dispatch_call_block_and_release (in libdispatch.dylib)
 14   _dispatch_client_callout (in libdispatch.dylib)
 15   _dispatch_main_queue_drain.cold.5 (in libdispatch.dylib)
 16   _dispatch_main_queue_drain (in libdispatch.dylib)
 17   _dispatch_main_queue_callback_4CF (in libdispatch.dylib)
 18   __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ (in CoreFoundation)
 19   __CFRunLoopRun (in CoreFoundation)
 20   CFRunLoopRunSpecific (in CoreFoundation)
 21   -[NSRunLoop(NSRunLoop) runMode:beforeDate:] (in Foundation)
 22   -[NSRunLoop(DVTNSRunLoopAdditions) dvt_spinRunLoopInMode:whileQueue:executesAsynchronously:] (in DVTFoundation)
 23   -[NSRunLoop(DVTNSRunLoopAdditions) dvt_spinRunLoopInMode:whileBlockExecutesConcurrently:] (in DVTFoundation)
 24   -[NSRunLoop(DVTNSRunLoopAdditions) dvt_spinRunLoopInMode:waitingForSemaphore:] (in DVTFoundation)
 25   -[IBCLIImageCatalogToolPersona compileCatalogCollection:withPlatformAdapter:arguments:outputDictionary:] (in ibtoold)
 26   -[IBCLIImageCatalogToolPersona invokeArguments:outputDictionary:] (in ibtoold)
 27   -[IBCLIImageCatalogToolPersona runSingleInvocation:outputtingToFileHandle:andVerifyingEnvironment:] (in ibtoold)
 28   IBCLIServerRunSingleInvocation (in ibtoold)
 29   __IBCLIServerRunSingleInvocationWithIODirectedAtPipesAndUnlinkOnSuccess_block_invoke_2 (in ibtoold)
 30   __IBCLIServerRunSingleInvocationWithIODirectedAtPipesAndUnlinkOnSuccess_block_invoke (in ibtoold)
 31   -[IBCLIErrorForwarder forwardErrorOutputToDescriptor:whileInvokingBlock:] (in ibtoold)
 32   IBCLIServerRunSingleInvocationWithIODirectedAtPipesAndUnlinkOnSuccess (in ibtoold)
 33   main (in ibtoold)
 34   start (in dyld)

I can't seem to get it to compile consistently — it works fine locally.

I would ❤️ a workaround, otherwise I'm not sure that we'll be able to ship an update to our app for macOS 26.

FB20183399

Boost

Answer 1

tonyarnold OP

Sep ’25

Accepted Answer

I ended up updating my CI nodes to run macOS 26 Tahoe, and this error doesn't occur anymore.

1

Answer 2

Bolsinga OP

Sep ’25

FWIW I am seeing this with my GitHub actions as well.

0

Answer 3

bks OP

Sep ’25

Updated to Tahoe, still seeing the same issue, only seems to happen on my CI machine, which makes me think this might be some kind of timeout or similar?

0

Answer 4

jabakobob OP

Oct ’25

I'm running into the same issue (Xcode 26.0.1 on macOS 15.7.1). I've added a retry logic to my build script. It now just retries on error 65. Of course each failed attempt takes a minute or two. This is very frustrating.

set +e
while true; do
  xcrun xcodebuild archive (...)
  case $? in
       0) break ;;
       65) echo "Received Status 65. Probably asset compiler bug. Trying again!" ;;
       *) exit $? ;;
  esac
done

It usually works after 3-5 attempts. But that's ridiculous!

0

Answer 5

silentsurfer OP

3d

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.

0