A Summary of the WWDC25 Group Lab

Hi Apple team, I'm experiencing a persistent issue with writing to UserDefaults from a widget extension on iOS. Here's the situation: I've set up an App Group: group.test.blah The main app has the correct entitlement and can read/write from UserDefaults(suiteName:) using this group successfully. I can read the value written by the app from the widget (e.g., testFromApp: hiFromApp). The widget extension has the same App Group enabled under Signing & Capabilities. The provisioning profile reflects the App Group and the build installs successfully on a real device. The suite name is correct and matches across both targets. I’ve confirmed via FileManager.default.containerURL(...) that the app group container resolves properly. When I try to write from the widget extension like this let sharedDefaults = UserDefaults(suiteName: group.test.blah) sharedDefaults?.set(hiFromWidget, forKey: testFromWidget) ...I get this error in the console: Couldn't write values for keys

Hi, Our App relies on a keychain to store certificates and key-value pairs. However, when we upgraded from an older XCode 15.2 (1 year old) app version to a newer version XCode 16.2 (with identical keychain-groups entitlement), we found that the newer ipa cannot see the older keychain group anymore... We tried Testflight builds, but limited to only generating newer versions, we tried using the older App's code, cast as a newer App version, and then upgraded to the newer code (with an even newer app version!). Surprisingly we were able to see the older keychain group. So it seems that there's something different between the packaging/profile of the older (1 year) and newer (current) App versions that seems to cause the new version to not see the old keychainGroup... Any ideas?

Hello, I'm currently trying to upload a new version of an existing application. But each time I try to validate the archive of the application, I got the following error in Xcode (v16.2) : Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “37CG5MY799.com.example.app” value for the com.apple.application-identifier key in “com.example.app.pkg/Payload/app.app/Contents/MacOS/app” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. I suspect that there is a problem with the App ID Prefix (that is 37CG5MY799 for the app) when our team ID is E4R7RJ7LA3 but I cannot find a solution. I asked the Apple Developer Support for help and I have read the documentation they sent but it couldn't solve this problem so they redirected me to the forums. https://developer.apple.com/library/archive/qa/qa1879/_index.html https://developer.apple.com/lib

I'm working on a macOS app with a Safari web extension. I'm trying to share a SwiftData model between devices using CloudKit synchronization. I am able to get synchronization in the main app on the same device, CloudKit sync works correctly — changes appear in the CloudKit Dashboard under com.apple.coredata.cloudkit.zone. However, in the Safari App Extension, data is saved locally and persists across launches, but never syncs to CloudKit. I have followed the recommended practices for configuring the App Group and entitlements, but the issue persists. Questions: Is there an official limitation preventing Safari App Extensions from connecting to the CloudKit daemon (cloudd)? If not, what entitlements or configuration changes are required for a Safari App Extension to successfully sync with CloudKit? Is the xpc_error=159 from bootstrap_look_up() a known sandbox restriction for this extension type? Any guidance from Apple engineers or others who have successfully used CloudKit from a Safari App Extension

In WWDC25 session What’s new for the spatial web, the presenter showed creating an immersive environment for a web page by adding to the page's HEAD section My first attempt failed, and I am trying to track down why. Before I search all the potential failure paths, I wanted to ask the community, Is this feature available in the latest visionOS 26 beta? I haven't seen anyone talk about their use of the feature yet.

My team has a robust digital accessibility program and processes for WCAG conformance in our apps. Because of this, there are definitely accessibility defects that get caught and addressed in order of impact and business priority like any other bug. Obviously we want to aim for 100% accessibility for our users, but it's a continual work in progress as new enhancements or changes are released. I'm stuck on the appropriate measurement to indicate support. If we have 50 common tasks and the most central 10 tasks are solid but some supporting (but also common) tasks have a contrast fail or accessibleLabel missing, does that make the whole app not supporting the feature? If completing the task is the rubric there are a whole range of interpretations for that. In a complex app, I anticipate that a group like ours will have strong support for many of the Accessibility Nutrition Labels accessibility features across tasks and devices, but realistically never be 100% free of defects for a given Apple Accessibi

Hello, Can anyone tell me what this means? Or if it's normal? I'm seeing about 10% battery drain per day on sleep, and pmset -g log shows wakes nearly every minute. 2025-06-10 17:10:35 -0700 DarkWake DarkWake from Deep Idle [CDNP] : due to smc.70070000 wifibt SMC.OutboxNotEmpty/ Using BATT (Charge:94%) 5 secs 2025-06-10 17:10:43 -0700 DarkWake DarkWake from Deep Idle [CDNP] : due to smc.70070000 wifibt SMC.OutboxNotEmpty/ Using BATT (Charge:94%) 6 secs 2025-06-10 17:13:49 -0700 DarkWake DarkWake from Deep Idle [CDNP] : due to smc.70070000 wifibt SMC.OutboxNotEmpty/ Using BATT (Charge:94%) 8 secs 2025-06-10 17:14:01 -0700 DarkWake DarkWake from Deep Idle [CDNP] : due to smc.70070000 wifibt SMC.OutboxNotEmpty/ Using BATT (Charge:94%) 6 secs 2025-06-10 17:14:10 -0700 DarkWake DarkWake from Deep Idle [CDNP] : due to smc.70070000 wifibt SMC.OutboxNotEmpty/ Using BATT (Charge:94%) 6 secs 2025-06-10 17:15:01 -0700 DarkWake DarkWake from Deep Idle [CDNP] : due to smc.70070000 wifibt SMC.OutboxNotEmpty/ Using BATT (Ch