“Xcode”

Hi, To provide some context on how this view fits into the overall layout: the map is displayed inside an info box that can be swiped away. When no swipe gesture is in progress, the map should remain interactive and allow zoom gestures. While the info box is being swiped, interaction with the map should be disabled. The map always displays at least one marker. You can find a more complete code example and a screenshot here: import MapKit struct ContentView: View { @State private var offset = CGSize.zero let position = CLLocationCoordinate2D(latitude: 51.5074, longitude: -0.1278) let span = MKCoordinateSpan(latitudeDelta: 5.0, longitudeDelta: 5.0) var body: some View { ZStack { let drag = DragGesture() .onChanged { g in offset.width = g.translation.width offset.height = g.translation.height } .onEnded{ _ in withAnimation { offset = .zero } } VStack(spacing: 0){ Map(initialPosition: .region(MKCoordinateRegion(center: position, span: span)), interactionModes: [.zoom]){ Marker(London, coordinate: positio

The Prompt stream failed: Agent has been closed error can occur when your project is in a macOS privacy-protected directory like ~/Desktop, ~/Documents, or ~/Downloads. macOS should prompt you to grant Claude access to these locations, but if the prompt doesn't appear or was previously denied, the agent can fail with this error. Workaround: Move your project to a non-protected directory such as ~/src, then reopen it in Xcode.

We do not use CallKit. The call is handled entirely using a custom in-app call UI. This is a bad idea. It's going to significantly complicate your app’s audio logic and, most practically, it means that ANY other incoming call from ANY CallKit app will IMMEDIATELY interrupt your app’s audio. It's also going to allow a variety of other odd edge cases which will be similarly disruptive (for example, now playing activity can interrupt your calls). The PRIMARY reason CallKit was originally created was so the system could properly arbitrate and manage the audio of VoIP apps, preventing all those edge cases. However, the exact rules and thresholds for these violations are not clearly documented, so I’d like to ask a few questions to better understand the expected behavior. The basic policy rule is that your app is not required to report a call if it either: Is already on a call. Is in the foreground. However, in practice, both of those criteria are much harder to implement than they seem. The problem here is that yo

I Have the same issue. MacOS 26.3.1, Xcode 26.2, iOS 26.3.1 iPhone 17 Pro Max and WatchOS 26.3 Apple Watch S10.

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.