“A Summary of the WWDC25 Group Lab”

Thanks for bringing this to the forums. The com.apple.token keychain access group, aka kSecAttrAccessGroupToken, isn’t a normal keychain access group. Rather, it’s a special group that holds all of the credentials that the system finds in CryptoTokenKit (CTK) tokens. Given that, you can’t add credentials to this group directly. It is possible to create a persistent CTK token, that is, one that’s not tied to smart card hardware. If you do that then the credentials published by that token will be available to all apps that are set up to use token-based credentials. It’s not clear whether this approach will work for your ultimate goal: [quote='819445021, h-noto, /thread/819445, /profile/h-noto'] so that Microsoft Edge for iOS … can … use it for client certificate authentication [/quote] My advice is that you first prototype this with an actual smart card [1]. If you can get that working, it’d be worth exploring the virtual token option. Finally, if you’re curious how an app ca

I’m facing the same issue and haven’t been able to update the remote handle for outgoing calls. Initially, I start the call by setting the callee’s phone number as the value of the CXHandle. However, during the call, the caller can add more participants. At that point, I need to update the remote handle to store a call ID instead, so I can later retrieve it and initiate a group call from the device’s recent call logs. The problem is that updating the remote handle doesn’t seem to work, it keeps the initial value and does not reflect any changes. This issue only occurs for outgoing calls, incoming calls behave as expected. Is there any solution for this?

[quote='880623022, timboudreau, /thread/818192?answerId=880623022#880623022, /profile/timboudreau'] that would … probably run afoul of one or another App Store policy [/quote] I don’t work for App Review, and thus can’t give definitive answers about their policies. My only advice is that you peruse the App Review Guidelines. At a technical level, on macOS it is possible for an app extension to communicate with an app or launchd agent or daemon that you control, even in the presence of sandboxing. If you want the server side of this to be an app, the best option is for that app to listen on a Unix domain socket that’s located in an app group container. If you want it to be a launchd job, prefix the named XPC endpoint with an app group ID. Both of these are documented in App Groups Entitlement. For more on the XPC side of this, see the various links in XPC Resources. Specifically, XPC and App-to-App Communication has a bunch of backstory you’ll need. And please don’t use Mach messagin

Definitely a hell of an experience in the worse way. Apple Watch Series 4 iPhone 11 Mac Neo I had 0 issues developing/deploying to Pixel WearOS, but obstacles after obstacles, developing for and deploying to Apple WatchOS. After several days of working around each obstacle with the help of Gemini, I'm adding the summary of what I had to do so far to get to initial deployment in case this helps Apple/others with fix/workarounds: Here is the complete technical post-mortem for the development environment setup. This summarizes the specific hurdles cleared to get a Watch Series 4 (watchOS 10.6.2) communicating with your Mac via a No-SIM iPhone bridge. 🛠️ Environment Recovery Summary The Networking Layer The primary blocker was extreme network instability on the default 10.0.0.x gateway. The Symptom: ping tests showed 62% packet loss and 1,000ms+ latency. The Fix: Migrated all devices to a clean 192.168.86.x subnet. The Result: Achieved 0% packet loss and ~13ms latency, providing the stable pipe

I am seeing a similar issue, but only for my Mac Catalyst archive on XCode 26. My app is a SwiftUI application that embeds an Objective-C framework built from a separate Xcode project. The framework binary itself does have UUIDs, but when I inspect the .xcarchive, the corresponding framework dSYM is missing from the archive’s dSYMs folder. What is confusing is that this does not happen for the iOS build. I use the same framework target, and when I archive the iOS app and upload to TestFlight, I do not get the warning. The problem only appears when I archive the Mac Catalyst version. So in summary: • The embedded framework binary is present in the archive • The framework executable has valid UUIDs • The app archive’s dSYMs folder does not contain the matching dSYM for that embedded framework • This only happens for Mac Catalyst • The same setup works correctly for iOS Has anyone seen Catalyst archives skip generating or packaging dSYMs for embedded frameworks, even though the binary itself contains de

Thanks for the post, hope some RealityKit experts jump quickly on this thread. However I wanted to be the first to tell you: Welcome to RealityKit and Metal! Transitioning into 3D graphics and procedural generation is exciting. Here comes my simple disclaimer. I’m not an expert at RealityKit, however I got before the tips that made my simple tests extremely successful and I would like to share those with you, if you require more in detail I would open up this thread to any RealityKit expert that wants to jump in here. When you add hundreds or thousands of individual rocks, trees, and bushes as separate RealityKit Entity objects, you are overwhelming the CPU. Even if the meshes are simple, RealityKit has to calculate the transform, bounding box, and physics for every single entity, every single frame, and then send individual instructions to the GPU. To fill dense background spaces without killing performance, you need to shift the workload. So, instead of creating 1,000 separate Entity bushes, you should gene

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.