Activity

1. Selepe89

   added

   bugSomething isn't workingSomething isn't working

   on Oct 10, 2026
2. Selepe89 commented on Oct 10, 2026

   

   Selepe89

   on Oct 10, 2026

   Author

   More actions

   Additional investigation after filing

   I've continued troubleshooting and want to add findings that may help narrow this down.

   Environment recap

   • xtool: 1.20.1 (also tested on 1.21.0 — same failure)
   • Host: WSL2 Ubuntu, x86_64
   • Swift: 6.4
   • SDK flavor: normal
   • SDK version: epoch=2,darwinTools=1.1.0,oam=1.3.0
   • Xcode source: Xcode_27.1_Release_Candidate.xip
   • Device: iPhone detected successfully via xtool devices (USB passthrough works)

   Steps already attempted

   1. Full clean SDK re-install after downgrading to 1.20.1:

   Result: SDK installs successfully, epoch changed from 3 to 2, xtool sdk status reports OK.

   2. swift sdk list shows darwin correctly.

   3. Inspected ~/.swiftpm/swift-sdks/darwin.artifactbundle/toolset/bin/:

   • Contains: dsymutil, ld64.lld, llvm-lib, orig/
   • No actool binary present

   4. Inspected the SDK's Xcode.app path:

   • ~/.swiftpm/swift-sdks/darwin.artifactbundle/Xcode.app/Contents/Developer/usr/bin/actool exists but is a Mach-O 64-bit arm64 executable — cannot run on x86_64 Linux (Exec format error).

   5. Built AssetKit from source (github.com/xtool-org/AssetKit):

   • Produces only libAssetKit.a (static library)
   • No executableTarget in Package.swift
   • So users cannot work around this by building AssetKit themselves.

   6. Tried TMPDIR=~/xtool-tmp and mkdir -p ~/xtool-tmp before build:

   • Same failure.

   Observed behavior

   xtool dev build reaches the compile stage (planning/constructing completes) then repeatedly tries to launch:
   home/selepe/sellhive2025/ios/App/CapApp-SPM/xtool/.xtool-tmp/actool --version --output-format xml1

   text

   And fails with:
   .xtool-tmp/actool is not an executable file

   text

   The .xtool-tmp/ directory contains only Package.swift and Sources/ — actool is never generated there.

   Conclusion so far

   xtool is expected to generate a Linux-native actool wrapper (backed by AssetKit) into .xtool-tmp/ during xtool dev build, but that step is not happening in this environment. The Darwin SDK toolset does not include a Linux actool binary, and AssetKit upstream provides no CLI target to substitute.

   This appears to be a bug in the SDK layout / toolchain assembly step for WSL2 x86_64, not a project or user configuration issue.

   Requested

   • Confirm whether actool generation is expected from the SDK install or from xtool dev build itself.
   • If it must be produced at build time, any logs or debug env var we can enable to see why the generation step is skipped.
   • Whether a Linux actool shim is available as a separate binary we can place into toolset/bin/ as a workaround.

   Thanks — happy to run any diagnostics you need.
3. kvapca commented on Oct 10, 2026

   

   kvapca

   on Oct 10, 2026

   More actions

   I had the same bug. I discovered that actool is used for Assets.xcassets folder. The workaround is to temporary remove it.
4. Selepe89 commented on Oct 11, 2026

   

   Selepe89

   on Oct 11, 2026

   Author

   More actions

   3. I had the same bug. I discovered that actool is used for Assets.xcassets folder. The workaround is to temporary remove it.

   Thanks @kvapca — this confirms what I found.

   Confirming the actool / Assets.xcassets link

   I traced it the same way: the .xtool-tmp/actool invocation only fires when the build walks Assets.xcassets. Moving the catalog out of the way lets the build skip it entirely. Good workaround for getting further, but it means no app icon, no splash, no named image sets in the final bundle.

   What I tried (in order)

   Environment:

   • Host: WSL2 Ubuntu 26.04 x86_64
   • Swift 6.4.0 (swiftly-managed)
   • xtool: first 1.21.0 AppImage, then downgraded to 1.20.1 AppImage (both reproduce the bug)
   • SDK: re-installed from Xcode_27.1_Release_Candidate.xip, both with xtool sdk install and xtool sdk build + xtool sdk install ~/new-sdk-out/darwin.xtoolsdk
   • SDK status after clean re-install: epoch=2,darwinTools=1.1.0,oam=1.3.0

   Attempts to fix the actool error:

   1. Confirmed no actool is present in toolset/bin/ — only dsymutil, ld64.lld, llvm-lib.
   2. Confirmed the Xcode.app copy at Xcode.app/Contents/Developer/usr/bin/actool is a Mach-O arm64 binary (can't run on x86_64 Linux).
   3. Built the upstream xtool-org/AssetKit from source — produces only libAssetKit.a, no CLI executable, so no drop-in workaround.
   4. Built the actool from joshuaswarren/omarchy-apple-dev tools/darwin-tools (AssetKit-based, real Linux x86_64 executable). Verified it runs and prints valid --version XML.
   5. Copied that actool into toolset/bin/ and into .xtool-tmp/actool. Build then wiped .xtool-tmp/ at start and reported "actool is not an executable file" — .xtool-tmp/ gets cleaned every run, so a manual drop-in doesn't survive.
   6. Switched to a patched xtool built from joshuaswarren/xtool at SHA f0a1f90 (the fork the omarchy installer uses). With that binary, .xtool-tmp/actool no longer gets deleted before it's used. actool problem solved.

   Now blocked on XCFrameworks

   With the patched xtool, the build gets past actool and fails on every binary dependency:
5. Selepe89 commented on Oct 11, 2026

   

   Selepe89

   on Oct 11, 2026

   Author

   More actions

   The directories exist under .build/artifacts/ and contain real bundles (Info.plist, ios-arm64/, _CodeSignature). SwiftPM still reports "There is no XCFramework found."

   I tried _SWIFTPM_EXPERIMENTAL_LINUX_XCFRAMEWORK=1 as an env var — no change. My understanding is SwiftPM expects the equivalent as a CLI flag (--experimental-xcframeworks-on-linux) that xtool does not pass through.

   Questions

   1. Is the XCFramework flag plumbed through xtool in a way I missed? If not, is there a config key in xtool.yml or an env var that forwards arbitrary flags to SwiftPM?
   2. For the .xtool-tmp wipe: is the expected behavior that xtool regenerates the tool wrapper after cleanup? On my system it cleans the directory but only re-creates Package.swift and Sources/ — no actool. Is that the piece that should be produced by the SDK install, or generated at build time from the toolset?
   3. Does the fork at joshuaswarren/xtool@f0a1f90 include the XCFramework flag pass-through, or is that still upstream-only?

   Project: Capacitor 8 iOS app (Capacitor core + Cordova + 17 Capacitor plugins including Firebase, Facebook SDK, Google Sign-In, Sentry — all binary XCFrameworks).

   Happy to run any diagnostics you want.

   3. I had the same bug. I discovered that actool is used for Assets.xcassets folder. The workaround is to temporary remove it.

   The directories exist under .build/artifacts/ and contain real bundles (Info.plist, ios-arm64/, _CodeSignature). SwiftPM still reports "There is no XCFramework found."

   I tried _SWIFTPM_EXPERIMENTAL_LINUX_XCFRAMEWORK=1 as an env var — no change. My understanding is SwiftPM expects the equivalent as a CLI flag (--experimental-xcframeworks-on-linux) that xtool does not pass through.

   Questions

   1. Is the XCFramework flag plumbed through xtool in a way I missed? If not, is there a config key in xtool.yml or an env var that forwards arbitrary flags to SwiftPM?
   2. For the .xtool-tmp wipe: is the expected behavior that xtool regenerates the tool wrapper after cleanup? On my system it cleans the directory but only re-creates Package.swift and Sources/ — no actool. Is that the piece that should be produced by the SDK install, or generated at build time from the toolset?
   3. Does the fork at joshuaswarren/xtool@f0a1f90 include the XCFramework flag pass-through, or is that still upstream-only?

   Project: Capacitor 8 iOS app (Capacitor core + Cordova + 17 Capacitor plugins including Firebase, Facebook SDK, Google Sign-In, Sentry — all binary XCFrameworks).

   Happy to run any diagnostics you want.
6. dajiaohuang commented on Oct 15, 2026

   

   dajiaohuang

   on Oct 15, 2026

   More actions

   I traced the current Linux build path at b50173f against the reported SwiftPM-resource case. Planner includes target resources in the plan and Packer copies the resulting SwiftPM bundle, but I found no actool invocation/wrapper or .xcassets handling in the current sources; the SDK selection also does not package an Xcode actool binary. The report and follow-up indicate that SwiftPM Assets.xcassets is the trigger, while the docs currently say SwiftPM resources “just work.”

   Could you clarify whether .xcassets inside SwiftPM target resources is intended to be supported on Linux, or is deliberately unsupported pending a separate asset-catalog pipeline? This affects whether the minimal compatible correction belongs in the build path or in the resource-support documentation. I saw that #325 adds a distinct assetCatalogs: path and explicitly says it does not address this report.
7. Selepe89 commented on Oct 15, 2026

   

   Selepe89

   on Oct 15, 2026

   Author

   More actions

   Thanks all — closing the loop on my side.

   The actool issue was only the first wall. For a Capacitor 8 app the real blocker is that SwiftPM on Linux won't resolve the binary XCFrameworks the plugins ship (Capacitor, Cordova, Firebase, Sentry, etc.), even with the patched fork — so a full local build isn't viable for Capacitor projects right now.

   What works for me instead:

   • Build an unsigned .ipa on a cloud Mac (Codemagic, xcodebuild with CODE_SIGNING_ALLOWED=NO)
   • Sign + install from WSL with xtool install
   • For the AFCClient muxError on WSL, the iTunes/Apple Devices port-forward workaround from xtool dev stuck on Connecting step #19 (USBMUXD_SOCKET_ADDRESS → host:27015) fixed it; usbipd did not.

   Happy to leave this open for the .xcassets-in-SwiftPM question @dajiaohuang raised.