“Xcode”

I have this problem with a private repo (which I have full access) on github.com too. Things I've tried (with Xcode not running) that did not help: deleting DerivedData deleting org.swift.swiftpm in both Library and Library/Caches deleting Xcode user defaults (com.apple.dt.Xcode) removing github items from Keychain Access restarted Mac after deleting above Each time I try to resolve packages it fails with SSH Key failed to verify. When I click on Edit Credentials it asks for my GitHub Personal Access token. I have an ssh key. It works everywhere except in Xcode - this also worked a month ago from within Xcode. This feels like it broke in Xcode RC2. The only thing that works is to run xcodebuild -resolvePackageDependencies in the terminal in my repo root. Which is a pain when you do a lot of branch switching or merging main into the branch. This is also how I know that the key works fine and I suspect it's a problem with Xcode itself.

Thanks for all that extra info. So, it’s definitely correlated with iOS 26.3. Which is strange, because I can’t think of any iOS 26.3 aligned change to local network privacy that would affect this. You could file a bug about this issue, but I’m not sure it’d get traction. As you noted in your first post, this whole process is a bit of a kludge, and it’s hard to argue that we should fix this (in contrast to FB12846267, which we definitely should fix, but haven’t yet). But if you do file a bug, please post your bug number, just for the record. At this point I think it might be worth considering different approaches. I zenned on that a bit today and I wasn’t able to come up with anything I’m truly happy with. One approach that I like is to have your UI test use some sort of IPC mechanism to the app, have the app connect to the accessory under test, and then proxy the UI test’s requests to that accessory. Unfortunately I couldn’t think of a good way to do that. It is possible to set up an IPC channel between apps

[quote='878529022, ski4funSonoma, /thread/817488?answerId=878529022#878529022, /profile/ski4funSonoma'] Including the sample code in the helper [/quote] Ah, I think you misunderstood that test. I was suggesting that you temporarily add that code to the app, with some sort of debug UI wired up to call it. That has two benefits: If it fails in the app context then there’s something weird going on. If it works in the app context, it should cause Xcode to embed libswiftCompatibilitySpan.dylib which might then ‘fix’ your helper tool. And if that second point is true, it confirms the nature of the problem and suggests a path to a workaround. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='878469022, Nickkk, /thread/817724?answerId=878469022#878469022, /profile/Nickkk'] Is the unmapped memory exception also the reason why the binary image address for my app is 0x0 - 0xffffffffffffffff? [/quote] Sadly, it’s not that simple. I created a small test app with this code: - (IBAction)testAction:(id)sender { #pragma unused(sender) NSLog(@-[AppDelegate testAction:]); void * p = (void *) 0x123456789ab; typedef void (*FunctionPtr)(void); FunctionPtr f = (FunctionPtr) p; f(); } and it produces a crash report like this: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x00000123456789ab Exception Codes: 0x0000000000000001, 0x00000123456789ab … Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x123456789ab ??? 1 xxom 0x10e301bf3 -[AppDelegate testAction:] + 83 2 AppKit 0x7ff81fa612ea -[NSApplication(NSResponder) sendAction:to:from:] + 444 … Thread 0 crashed with X86 Thread State (64-bit): … rip: 0x00000123456789ab rfl: 0x0000000000010

Resolved. Of course I did it to myself, but #Xcode could have warned me. Package dependencies either direct or indirect in my project are A <- B <- C <- D <- E <- App where x <- y means x is a dependency of y. I was writing tests for package C. To make test setup easier I called functions in package D and E, adding D and E as dependencies to C. Oops. Don't do that. Apparently adding C and C_C is how Xcode handles circular dependencies.

The find command returns nothing when the app is built with XCode 26.3 or XCode 26.2. Is there a build setting that ensures that libswiftCompatibilitySpan.dylib gets included? I've tried copying it in build phases, but that crashes the main app. I do have Always Embed Swift Standard Libraries set to yes in the main app. Including the sample code in the helper (NB: the helper tool doesn't have an app delegate - it's a command line tool) also doesn't resolve the crash. If it's helpful, here's the relevant piece of the crash log from the helper: Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @rpath/libswiftCompatibilitySpan.dylib Referenced from: <91AD8720-25FD-3ABB-B10A-6A7630E7BA48> /Users/USER/Library/Developer/Xcode/DerivedData/MyApp-hapnwyzmnoqmoybwzlybjoupeflc/Build/Products/Debug/MyApp.app/Contents/MacOS/com.micromat.TTDaemon Reason: tried: '/usr/lib/swift/libswiftCompatibilitySpan.dylib' (no such file, not in dyld cache), '/System/Volumes/P

Thanks. It works after developer account is added into Xcode project