Swift Package Debugging for Xcode Workspace

Our team uses the Package Manager extensively for an iOS project. We have added several local Swift Packages via Xcode that define binary targets accessible only via a VPN. When package resolution occurs while not connected to the VPN, the state of the package gets into a bad state as can be observed by inspecting SourcePackages/workspace-state.json and SourcePackages/artifacts. The artifacts are being placed in directories unrelated to the binary. Its like "randomly" selecting another local package to store the artifact. Reconnecting to the VPN doesn't resolve the issue. It often requires us to clear the package cache and derived data. This issue has become very disruptive to our daily workflows so we are really looking for a some type of fix or workaround.

I'll provide more details as I get I learn more but first wanted to see how I can seriously debug this. Through now, we can only reproduce this issue with an Xcode workspace, with local packages dragged into that workspace. I downloaded the swift-package-manager hoping I can somehow catch this issue in the debugger and step through the code. But is this actually possible to trigger the same resolution process that Xcode triggers for local packages in an Xcode workspace? How does Xcode manage these workspace packages and call into the swift package? As a reminder, with the local Swift packages in a workspace, these are not part of a Package.swift file but rather has is being managed on the Xcode side.

1 Like

I can't help, but since this is WWDC week, you could try one of the remote labs to talk to an Apple engineer. In your case probably one of the Xcode labs.

3 Likes

We have gotten one previous report of this issue, but I haven't been able to reproduce it myself, yet. Maybe the VPN bit was the missing information, though. So basically if the binary is initially fetched but fails, Xcode gets into this bad state?

There's a few moving parts around how an IDE like Xcode interacts with libSwiftPM, but local references are essentially provided as additional root packages via this API.

That's correct - the binary fetches successfully, but subsequently going off the VPN leads to a bad state.

Below is sample project that demonstrates the issue when including the Stripe xcframework in a local package -- see the READ_ME file. You can demonstrate the issue by going offline, without involving a VPN using the networksetup -setairportpower en0 off command from mac. Please let me know if any of this is unclear.

1 Like

Thanks for the detailed example, I will try to reproduce the issue with that and get back to you if I have any follow-up questions.

For anyone following the thread - Boris and I met via an Apple remote lab during WWDC to discuss further. There were some changes in Xcode 13 that we hoped may help.

The good news is I can confirm the issue does not occur with Xcode 13 but does for Xcode 12.5.

1 Like