Swift 6

Thank you, it is nice to know these Swift-based CSR APIs are coming in macOS 26.0. However, I'm still wondering what these two functions are: xpc_session_set_peer_code_signing_requirement xpc_listener_set_peer_code_signing_requirement Because they are new in macOS 14.4, but seem to have basically zero use in Swift as per above. xpc_listener_t and xpc_session_t seem to be completely new objects from macOS 13.0, however the xpc C API - the convention they seem to follow - is way older. The two objects mentioned however gained a full set of new functions in macOS 13.0 and 14.0. E.g.: xpc_listener_create is a macOS 14.0+ function xpc_session_create_mach_service is a macOS 13.0+ function How am I supposed to treat these compared to the old C API using xpc_connection_create_mach_service + either XPC_CONNECTION_MACH_SERVICE_PRIVILEGED or XPC_CONNECTION_MACH_SERVICE_LISTENER? Are they supposed to be an easier-to-use session based API?

Lemme see if I have this straight: You want to use the new Swift XPC API for app-to-daemon XPC communication. You want the daemon to validate the code signature of the client. Is that right? If so, the source of your confusion is that currently shipping systems have no support for this. Fortunately, that seems to have changed in macOS 26 (currently in beta). See Validating Signature Of XPC Process. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi Ziqiao, I've tried with iOS 26 Beta 7 and since Beta 8 (landed tonight) on device (because my Xcode is stuck on iOS Beta 6, don't know why) and the problem is solved. I can now query CollectionItem with predicate that contains inherited properties. Now I have only got problems with accesses to the children property in List. When i got the following hierarchy and the SwiftUI view List access to the Item.children property I got another kind of crash. Category: Work (parent: none) Category: Tech (parent: Work) Thread 1: Fatal error: Never access a full future backing data - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0x9872c0007ba42159 ))) with Optional(7639D151-5D48-46AC-AB2A-7F0F50919AC5) But I guess it's a different kind of problem now.

update Xcode 26 Beta 6 Fixed it Simulators may fail to boot during the first build after upgrading macOS; rebuilding after a short wait typically resolves the issue. (152328794)

You can follow the Swift concurrency rules to run multiple Foundation Models sessions / tasks concurrently. The framework doesn't impose any extra rules for concurrency. Note that the inference tasks will eventually run on the neural engine serially though. Best, —— Ziqiao Chen  Worldwide Developer Relations.

The behavior should be that only the fragments that fall in the view port + estimated overdraw region are re-drawn, and that should be true for all system versions. Thanks for creating the demo project for me. I've tried your project with my Xcode 26 Beta 6 + iOS 26 Beta 7 + iPhone 16 Plus, and don't see that the system re-draws all the paragraph. Here is what I do: a. Use the following print instead to better observe the fragments that are re-drawn: print(draw called in (rangeInElement)) b. Add more paragraphs to textContents so the content is longer. With that, here is what I see: Launch the app. Xcode shows the following log, indicating that only the first fragment is drawn. draw called in 0...1531 (Happens one time) Scroll a bit. Xcode shows the following log, indicating that only the first and second fragments are drawn: draw called in 0...1531 draw called in 1532...3237 ... (Repeats many times.) Scroll down to the bottom, clear the log, and then scroll a bit. Xcode shows the following log, indi

I did some of investigation of this issue because I ran into the same problem when trying to convert an old project from groups to folders. I discovered what is happening is that Xcode 16 changes the model's current version to the last one alphabetically. I was able to reproduce it this way: Create a brand new, folder-based, Xcode project. Add an xcdatamodeld with one entity. Add a new model version and name it a. Make it current. Quit Xcode. Relaunch Xcode. Expected result: The a model version should still be current. Actual result: The original model version is current. I was able to reproduce with Xcode 16.2 and 16.4. It appears to be fixed in Xcode 26 beta 6. Based on these steps, one workaround appears to be to name the model versions alphabetically. Another workaround is to keep the xcdatamodeld file in a group, not a folder. And of course if you can switch to Xcode 26, then you don't need to workarounds above.