“A Summary of the WWDC25 Group Lab”

[quote='817602021, Pavel, /thread/817602, /profile/Pavel'] On macOS, the socket path length is restricted to 104 characters [/quote] That’s not quite right. While sockaddr_un has a fairly short limit, a Unix domain socket address actually supports a path length up to 253 bytes, which is SOCK_MAXADDRLEN minus the two byte header containing sun_family and sun_len. However, sockaddr_un is defined such that sun_path is 104. So, if you’re happy to do some gnarly pointer play, you can use longer paths, long enough to allow them to live within an app group container. Oh, wait, you said not sandboxed. Well, in that case, you don’t need to put them in an app group container, but you can still take advantage of the long path support. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I want to share all the content of a CloudKit database at once between different iCloud accounts. For example, to manage products storage between users. Once the database has been shared or an invitation has been accepted, any additions/modifications/deletions to storage or products must be shared between all users without additional sharing. To be short after the first sharing, everything must be shared without additional new sharing. I think I can't do this in SwiftData (would be the best solution for me as all the current app is based on SwiftDaa) and that I need to use move to CoreData. Is that correct? Or does a mixed solution may be possible (ie .storage with SWiftData and sharing with CoreData)? It seems that “Zone Wide Sharing” could be the solution? But I can't find a sufficiently comprehensive example and I wasn't able to make something working. Ultimately, I realize that this is not a very common use case. With the ZoneWide Sharing does it means that we must do a affectedStores or assign(_:to:) to

Hi Richard, Thank you for the guidance. I have tested fetchAssetsWithBurstIdentifier:options: as you suggested and confirmed that I can locate the assets sharing the same burstIdentifier even when they are not appearing in the main Library. Here is the core of the issue I’m facing: While I can fetch these assets, there is no explicit property on PHAsset to determine if it currently resides in the Recently Deleted album. In our app's workflow, PHPhotoLibrary returns success = YES during the performChanges block. However, because the new burst is automatically grouped with an existing deleted set, the photo is immediately invisible to the user in the main Library. Our intended UX is to show a warning alert to the user if we detect that a matching burstIdentifier already exists in the Recently Deleted album. This prevents the confusion of a successful save that results in an invisible file. Question for clarification: Is there a recommended, officially supported way to identify if a PHAsset returned by

Of course the new beta would break the whole thing immediately 😅 Now all I get is : -[NEPIRChecker start:responseQueue:completionHandler:] - failed to register with PIR for Group site.kaylees.Wipr2 usecase site.kaylees.Wipr2.url.filtering even with no errors on the server side. My kingdom for a flag to ignore the PIR server completely and just “fail closed” on the bloom filter. Why do we even need to register with the server in order to enable a “fail closed” filter? I see that pirSkipRegistration flag in the logs, can we have it please? 😬 Or like a normal API with a JSON file like Content Blockers and regex and bundle ID filtering, but I guess that’s asking too much 😬