“A Summary of the WWDC25 Group Lab”

It errors out almost immediately, but it's writing to the logs. Congratulations! Having been through this many times, I'm well aware of the mixed joy of FINALLY getting a driver to the point where it can log its own failure. I had been using automated signing, so I manually created and downloaded a profile, and received the same wildcard in it, even though we had requested and gotten approved for the vendor ID capability request with the specific vendor ID. My post here has all the background and the ultimate solution, but the summary is that you'll be using this for development builds: * ...and then resigning DEXT builds with the numeric value you were approved for once you're ready to distribute code. I wouldn't bother trying to sort out that process now, just keep in mind that you'll need to revisit this issue once you get closer to shipping. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

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

I'm wondering this too. In my case the URL is for a local file, and the image isn't being detected. Loading the image from a reference group - or using an ARKit approach combined with ARReferenceImage does however work.

Your questions are quite hard to read. See Quinn’s Top Ten DevForums Tips for advice on how to improve this going forward. Also, you asked questions about four very different technologies: User defaults, Core Data, the file system, and widgets. I have a good handle on the first and the third. I can offer some general advice about the second but, if you want more then you should start a follow-up thread in App & System Services > iCloud & Data with the Core Data tag. Similarly for the fourth, but with the App & System Services > Widgets & Live Activities subtopic. With that out of the way, let’s look at your questions. User defaults has a last-write-wins synchronisation policy, with the caveat that the definition of “last” is last change to hit the daemon that manages this stuff. The answers to your question fall out of that policy: [quote='817725021, gabrielsoria, /thread/817725, /profile/gabrielsoria'] If multiple processes (app + multiple widget instances) read and write the same share

Hi Richard, Thank you for the clear explanation and the suggested workaround. I understand now that there is no official API to fetch assets specifically from the Recently Deleted album, and that using UIImage to create a new asset would result in the loss of critical metadata. Regarding your question about our goals: Our intent was to provide a better UX by warning users before a save operation results in an invisible asset (due to the automatic grouping with deleted items). Since we cannot reliably detect this state via the current Photos Framework, we will evaluate whether to handle this by pre-processing the metadata or by filing an enhancement request through Feedback Assistant as you suggested. I appreciate your time and the technical insights provided throughout this discussion. Best regards, Jimmy

Hello jimmy520, By design, there is no API for fetching Recently Deleted assets. Is it necessary to support saving a burst photo with the same burstIdentifier as recently deleted assets? You may want to reconsider your goals. A potential workaround could be to use creationRequestForAssetFromImage: of PHAssetChangeRequest to create an entirely new PHAsset with the UIImage of the photo you're trying to save. However, please note that while this asset will be free of the burstIdentifier associated with the deleted burst photos group, it will also lack other metadata as well: Important A UIImage object does not contain all metadata associated with the image file it was originally loaded from (for example, Exif tags such as geographic location, camera model, and exposure parameters). To ensure such metadata is saved in the Photos library, instead use the creationRequestForAssetFromImageAtFileURL: method or the PHAssetCreationRequest class. To copy metadata from one file to another, see Image I/O. You can

@csdevfr Thank you for the recommendation. My initial message included a link to the report with the sysdiagnose. For context, here are my current setup: • TestFlight builds. • Production cards. • Apple certification stage - the step where you need to select a lab for certification. Our card provider insists that the encryption API is working as expected and that their SDK relies on the same implementation. Unfortunately, they haven’t been very responsive. I’m hoping to receive the nonces from Apple so we can confirm whether the issue is on their side and have clear evidence to ask them to thoroughly verify everything.

[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