A Summary of the WWDC25 Group Lab

The best path forward here is for the sysex itself to manage the credential. It’s effectively a launchd daemon and thus can [1] use the System keychain. There’s a couple of ways you could spin this: Have the app download your configuration [2] and then pass it to the sysex via XPC. Have the app use XPC to instruct the sysex to download and save the configuration. In both cases it’s the sysex accessing the System keychain, which avoids all the various issues you’ve bumped in to. [quote='798513021, pawanquantum, /thread/798513, /profile/pawanquantum'] we're unsure if XPC is suitable for sensitive data like private keys during tunnel creation [/quote] XPC should be fine here. See XPC Resources for a lot of links to docs and so on. Some things to note: In the app, set the privileged flag [3] so that the system only looks for the named XPC endpoint in the global namespace. See this post for an explanation of that. In the sysex, declare the named endpoint via NEMachServiceName. In both the app and the sysex, claim

Hi @umertap, You wrote: [...] Is this the expected behavior for the apple-developer-merchantid-domain-association file? Should the browser download the file silently, or is there another step required, such as displaying the content on the webpage for verification purposes? I've consulted some resources and they indicate that the file download is the correct behavior. However, I'd appreciate confirmation from the community to ensure I'm implementing the verification process correctly. Yes, the file download is the expected behavior. Please see the technote below for the configuration process and more information about validating your merchant domains for Apple Pay: TN3173: Troubleshooting issues with your Apple Pay merchant identifier configuration https://developer.apple.com/documentation/technotes/tn3173-troubleshooting-issues-with-your-apple-pay-merchant-id-configuration#Domain-verification-issues Then, you wrote: [...] Summary is how do we know if apple has verified it? Use the Apple Developer we

Hello, Check out TabletopKit and SharePlay to see if they meet your needs. Synchronizing group gameplay with TabletopKit is related sample code.

Ah, that's frustrating. It would be helpful if you could file a feedback with a CPU sample of AssetCatalogSimulatorAgent You can get a CPU sample either from activity monitor, or by running this in the terminal just before building. sample AssetCatalogSimulatorAgent 120 -wait Does the performance of the build change if you remove all of the groups and layers from the icon?

As @mungbeans mentioned, not all extensions can write to an App Group container. A keyboard extension with no full access is an example of that kind. The other possibility is you intentionally create your model container with readonly mode by using init(_:schema:isStoredInMemoryOnly:allowsSave:groupContainer:cloudKitDatabase:) with allowsSave being set to false. It doesn't look like the case though, based on your description. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Nice to know that the original issue goes away in the latest Beta. Regarding the crash triggered by the access to Item.children, if you can provide a runnable code snippet to demo the issue, I'll take another look. You have mentioned a few classes with inheritance, and so I think it is probably worth mentioning that over-using inheritance may impact your app's performance negatively. Concretely, with today's default store (DefaultStore), all the types in an inheritance hierarchy are persisted with one single table in SQLite. If your inheritance hierarchy has many classes, the table (columns and data) can be quite big, which can slow down the performance of fetching and inserting data. That being said, when adopting SwiftData inheritance, you might examine if that is a right use case. This WWDC25 session(starting from around 4:25) covers this topic a bit. You can take a look, if haven't yet. Best, —— Ziqiao Chen  Worldwide Developer Relations.

This is a problem because if I have a group of tasks to complete on one BGContinuedProcessingTask, the interface won't update gradually as the tasks are completed, but only in steps as each task completes and until the first one does it shows a spinning circle. Is this intended? Or could it be a bug? I think this is a case of neither and both. That is, I don't think what you’re seeing is a design choice, and not due to any accident or mistake. However, I also think it's very possible that this is something that could be tweaked and improved on. Two broad points I'd make here: First off, any time you feel like something isn't working the way you want/expect, it's always worth filing a bug on, particularly when you're dealing with a new API. I won't promise that anything will change— like any large-scale engineering organization, properly prioritizing work is a very complicated task and that sometimes means that things don't change or get fixed when they should. However, any change that happens ALWAYS

Hello, I'm posting in this thread rather than starting a new one so all the information is consolidated... I also have some doubts about BGContinuedProcessingTask... My main problem is with the Progress object. I've observed that if I add children Progress objects to the object provided by the task, the popup that shows up with the task on the device doesn't update the progress interface until the Progress object has completed at least one unit. It doesn't seem to be using the fractionCompleted property and instead it seems to use the number of completed units. This is a problem because if I have a group of tasks to complete on one BGContinuedProcessingTask, the interface won't update gradually as the tasks are completed, but only in steps as each task completes and until the first one does it shows a spinning circle. Is this intended? or could it be a bug? Also, as the original poster said, the actual BGContinuedProcessingTask object is not sendable, so when I start an async Task there's no way to p