“A Summary of the WWDC25 Group Lab”

I have created a Feedback Assistant for this: https://feedbackassistant.apple.com/feedback/22266931 Prefect, thank you. Also created a Code-Level Support case, with the same title as with Feedback Assistant but it seems to be private. Yep. I've replied to that with a summary of the situation as well. Please inform if I may have missed anything. Everything looks good to me. At this point, I think you should ignore the issue and proceed with development. This warning won't have any effect on the certification process. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hi @Ziqiao Chen and everyone, Thank you for the follow-up. You were right to push for more precise testing — it led me to discover an issue with my original test setup and reach a much clearer understanding of the problem. == Correction: Original Test Setup == My initial frontmost test had a build configuration error: the test build still had an active HKWorkoutSession running in the background. This means the results I would have reported (~10 minutes before termination) did not reflect pure frontmost app state behavior. I've since corrected this and re-tested with precise instrumentation. == Hardware & Software == Apple Watch Series 8 (45mm) — not Series 4 watchOS 11.6.1 (latest stable) Build: Debug, standalone watch app Xcode debugger disconnected before all tests (to avoid priority elevation) == Methodology == I added a 30-second heartbeat timer that logs: Sequential counter and elapsed seconds Current heart rate value and time since last HR sample (hr_age_sec) App lifecycle transitions (ScenePhase ch

To submit an In-App Purchase for review, the In-App Purchase must have the Ready to Submit status. If the In-App Purchase doesn’t have this status, complete any missing information such as price or localization for the subscription group display name. For more information about submitting In-App Purchases, see Submit for review.

Yes actually! This one 7214 error 19:24:29.268275+0100 framework configureUseCaseGroup(withName:useCaseGroup:) threw an error: CipherML.CipherMLError.unsupportedNetworkURL(url: https://pir.kaylees.site/) or later configureGroupWithName:useCaseGroup:error: Request complete error:Error Domain=com.apple.CipherML Code=1400 Unable to configure use-case group: unsupported network URL: https://pir.kaylees.site/ UserInfo={NSLocalizedDescription=Unable to configure use-case group: unsupported network URL: https://pir.kaylees.site/, NSUnderlyingError=0x736c3de60 {Error Domain=CipherML.CipherMLError Code=12 unsupported network URL: https://pir.kaylees.site/ UserInfo={NSLocalizedDescription=unsupported network URL: https://pir.kaylees.site/}}} “unsupported”? As far as I can tell, the device makes no attempt to contact the server. This only happen with TestFlight builds on the latest beta. Every other combination seems to work fine. I would try to debug this but I think it’s private API, and it’s pretty

If you test this in the Shortcuts app, does your intent get invoked? If so, then your code is functioning, and that's how you should continue your testing. The system search schema is grouped under the App Intent Domains section of the documentation, which has the following note that's relevant to your testing: Siri’s personal context understanding, onscreen awareness, and in-app actions are in development and will be available with a future software update. — Ed Ford,  DTS Engineer

[quote='879950022, timboudreau, /thread/818192?answerId=879950022#879950022, /profile/timboudreau'] the industry has produced plenty of ways to run untrusted code in-process [/quote] Sure. And if the only issue were the host not being able to trust the guest, such techniques might be feasible. But in this case you have to worry about the guest not trusting the host. [quote='879950022, timboudreau, /thread/818192?answerId=879950022#879950022, /profile/timboudreau'] can using StoreKit in an AUv3 work at all? [/quote] There’s an obvious way to make this work: Have the user run the app. Which uses StoreKit to check for the purchase. And stores the state in an app group, or keychain access group [1]. Which the app extension checks. This requires that the user run the app at least once so that it can achieve, but that’s not particularly onerous. However, the real question is really about whether your app extension can call StoreKit. I don’t know for sure. I’m gonna research this and get back to yo

Update — Workaround found After further investigation I have found a workaround that resolves the inconsistent track switching behaviour described above. Observation I noticed that changing the order of EXT-X-MEDIA audio entries in the manifest produced different results. Specifically, when the DEFAULT=YES track is listed first, switching behaviour is unreliable. When the DEFAULT=YES track is placed last, switching back to the default language works correctly. Workaround Reorder the EXT-X-MEDIA audio entries so that the DEFAULT=YES rendition appears last in the manifest: #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=de,NAME=Deutsch,AUTOSELECT=YES,DEFAULT=NO,CHANNELS=2,URI=audio_DEU.m3u8 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=fr,NAME=Francais,AUTOSELECT=YES,DEFAULT=NO,CHANNELS=2,URI=audio_FRA.m3u8 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=en,NAME=English,AUTOSELECT=YES,DEFAULT=YES,CHANNELS=2,URI=audio_ENG.m3u8 In our case the manifest is gener

Hi @tfnyldrm, You wrote: One of our app is alreadey released, can we still do it to share the same Apple login? Any existing app the uses Sign in with Apple can be added to an app group to share the same user session of the primary app across all child apps. To learn more, see Configuring your environment for Sign in with Apple https://developer.apple.com/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple Cheers, Paris X Pinkney |  WWDR | DTS Engineer