Swift 6

So, going through lots of details in no particular order: The entitlement com.apple.security.files.bookmarks.app-scope is not necessary and has no effect. Looking at our code, it's not that it’s unnecessary, it's actually that User selected read/write are both accepted as well. If you wanted to create a process that created bookmarks but didn't present open/save panels (for example, as a helper process), then you could use it. But what's confusing is this other, directly-related API where a security-scoped bookmark cannot be created under any circumstances because of the URL itself, some specific way the URL was initially created, and/or manipulated? So, the way to understand this is to invert the question, to Are there URLs which you're ALWAYS allowed to access?. The answer to that is yes. You can poke around to find other examples but they include directories like /Applications/, /Library/, and even /. Two notes on that: The right to access a given directory does NOT mean you have access to all of its subdi

I'm also seeing this problem with Swift Charts. This is with the latest Xcode 26 Beta 6 and iOS 26 Beta 8. This issue doesn't affect devices running iOS 18 and 17 from my testing. As such I've made this modifier which may help someone, hopefully I can remove it in the release seed but who knows! extension View { func CustomTapGesture(tapCount:Int = 1, perform action: @escaping () -> Void ) -> some View { modifier(TapGestureModifier(tapCount: tapCount, action: action)) } } struct TapGestureModifier: ViewModifier { var tapCount:Int = 1 var action: (() -> Void) func body(content: Content) -> some View { if #available(iOS 26.0, *) { content.simultaneousGesture(TapGesture(count: tapCount).onEnded { action() }) } else { content.onTapGesture(count: tapCount) { action() } } } } Which can be used like this: Text(Hello World) .CustomTapGesture(tapCount:2) { UIImpactFeedbackGenerator().impactOccurred() } To be clear, this doesn't work as well for iOS 26 users as the standard .onTapGesture b

[quote='855795022, EoinN, /thread/798211?answerId=855795022#855795022, /profile/EoinN'] My question is whether this behaviour was default or not for new Apps [/quote] As of Xcode 26.0b6 (17A5305f), creating a new project from the macOS > App template sets: Approachable Concurrency Default Actor Isolation to MainActor. However, there’s a wrinkle here. The language mode (Swift Language Version) still defaults to Swift 5. I expect that’ll change at some point, but AFAIK there’s been no official announcement about that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi, it's still not visible. I'm running Xcode beta 6. My app is an iPad OS app and I'm using RealityView. I can only see the Capture GPU Workload button. There's no way for me to debug my scene using the RealityKit debugger. Is it only available for VisionOS?

Hi @RamiroDiaz-Latch, You wrote: In most cases, our code snippet works as expected, and the result is .success. However, we are also encountering other results, such as .denied, .alreadyPresenting, and .cancelled or .notSupported, which cause the Wallet to appear for users. [...] As @EtienneVTS mentioned, the API is intended to be used while an approved app is in the foreground. However, this requirement is indeed documented below: Use this method only in apps that must stay in the foreground when operating near NFC or other RF readers. This method prevents the device from automatically displaying the Apple Pay passes when it detects a compatible reader. This suppression occurs only while the app is in the foreground. The system automatically reenables the Apple Pay interface when the app goes to the background. If the app resumes, the system automatically suppresses the Apple Pay interface again. requestAutomaticPassPresentationSuppression(responseHandler:‍) https://developer.apple.com/documentation/passkit/

I just caught this bug this morning with Xcode 26 beta 6. I promptly filed feedback with a sample project. FB19931677

[quote='855504022, erdeszbalazs, /thread/798187?answerId=855504022#855504022, /profile/erdeszbalazs'] but seem to have basically zero use in Swift as per above. [/quote] These are part of XPC’s low-level C API (using the terms from XPC Resources). You can call this from Swift, just like you can call malloc from Swift, but the NSXPCConnection and low-level Swift APIs are both nicer. [quote='855504022, erdeszbalazs, /thread/798187?answerId=855504022#855504022, /profile/erdeszbalazs'] Are they supposed to be an easier-to-use session based API? [/quote] The new session-based APIs were designed to provide a better model for XPC, one that’s more closely aligned with the reality of the underlying implementation. They were introduced around the same time as the low-level Swift API, and so that API only supports this model. The low-level C API has to support this model and the previous model for compatibility. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Supp

String Catalogs are not supported for .intentdefinition files. However, you can use them for Intents that are defined with Swift code using the AppIntents framework.