SwiftUI List performance

Thanks for the post, this is extremely interesting to me for metal, what version of macOS are you using in what computer that can’t find the slice? I think, the error message Unable to find intelgpu_kbl_gt2r0 slice or a compatible one strongly suggests that it is related to the performance of the app on your Mac running macOS 26.2. This is a specific slice or compilation target for Metal shaders. This file contains precompiled Metal shader code for various graphics hardware configurations. The error means the system couldn't find a version of a shader that's compatible with your specific Intel graphics processor in the precompiled resources? The error message you're seeing is a strong indicator of a graphics-related issue likely impacting performance on your Intel Mac. The specific version of macOS and the applications you are using will determine the scope of the impact and the appropriate troubleshooting steps. I’m not an expert in metal nor I know enough to figure it out. May I ask you to

Hi Michael, Thank you for your previous suggestion to use ViewAttachmentComponent for immersive controls. I've implemented it, However, I'm still facing two critical issues: Issue 1: Buttons in ViewAttachmentComponent Not Responding to Gaze + Pinch The buttons inside my ViewAttachmentComponent are visible and render correctly, but they do not respond to eye gaze + pinch gestures. This defeats the purpose of using visionOS's hands-free interaction model. My Implementation: ImmersiveView.swift (for panoramic images): struct ImmersiveView: View { @EnvironmentObject var model: AppModel @State private var menuEntity: Entity? @State private var isMenuVisible: Bool = true var body: some View { RealityView { content in // Invisible sphere for gesture detection let tapDetector = Entity() tapDetector.name = TapDetector tapDetector.components.set(CollisionComponent(shapes: [.generateSphere(radius: 900)])) tapDetector.components.set(InputTargetComponent()) content.add(tapDetector) // Create control menu using ViewAttachm

We're also getting the same error ... encountered an error (The test runner hung before establishing connection.) We tried nearly everything, including disabling the Thread Performance Checker in the test scheme shutting down all emulators via xcrun simctl shutdown all and erasing them xcrun simctl erase all force killing any potential hanging simulators beforehand clearing all Simulator logs and caches restarting the machine(s) But this still keeps popping up intermittently. We're using Xcode 26.2. Any tips on what we might want to try next? Thanks!

I got the exact same issue. No changes made on our side. It just stopped working. We actually perform notarization manually in our ci_post_xcodebuild.sh script. Maybe that is interfering. We actually don't use the artifact of the notarization step, but when we remove it the CI_DEVELOPER_ID_SIGNED_APP_PATH, which we need in the post build script, won’t be set...

We are facing the same issue while performing SCEP / CMS-based enrollment using OpenSSL. When OpenSSL is operated in FIPS mode (OpenSSL 3.x FIPS provider), CMS EnvelopedData using RSA recipients no longer supports RSAES-PKCS1-v1_5 key transport and instead generates RSAES-OAEP (corresponding to RSA_PKCS1_OAEP_PADDING in OpenSSL) for encrypting the content-encryption key. However, Apple’s MDM / Keychain CMS implementation on both iOS and macOS does not appear to support RSAES-OAEP and fails to import the encrypted PKCS#12 payload. Could you clarify whether there are plans to add support for RSAES-OAEP in CMS EnvelopedData for MDM / Keychain.

Hi @myasnik1998, Please see the following page for more information on requesting access to the Apple Pay In-App Provisioning Extensions: Apple Pay on the Web Demo: In-App Provisioning Extensions - Allow Listing and Entitlements https://applepaydemo.apple.com/in-app-provisioning-extensions#allowListing Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, I wanted to let you know that I made changes related to TLS so it matches the cipher suite Apple uses. I configured the access rules so nothing is being blocked, and I ran tests using PowerShell and OpenSSL—every result returns HTTP/1.1 200 OK. I also verified that the URL Apple says it will use to validate the file under /.well-known works correctly and it does display the contents of the file. However, when I try to verify the domain in Apple’s portal, I still get the same error: “Domain verification failed.” Could you please help us with an alternative solution or any additional verification steps we should perform? Thank you.

Thanks for all the details and the funny anecdote. I'll ask the user to run the cp command, but they told me they have some other work to do at the moment and need a break. In the meantime, since you said it's a SMB issue, is there a way I can reproduce the Result too large myself? Yes. To start with here: Setting a large resource fork like mentioned in that StackOverflow post causes the mentioned error Argument list too long. Was this on your SMB target or on your local (APFS) volume? If this is happening on the local volume, then I think the problem is that you're hitting the max transfer size limitation of fsetxattr. You need to break the transfer up into smaller individual segments, as copyfile does here. As a side note here, there's an open question here as to how the problem file originally got to the SMB server. On modern systems, we primarily use the resource fork to store compressed data (as I described above), but we also got out of our way to NOT export that configuration out of the system

@DTS Engineer Thanks for the response. I have filed a feedback report with the details discussed in this thread. Feedback ID: FB21848143 I really hope there is some initiative inside Apple to improve this area. Apart from the initial sync performance issues with large datasets, CKSyncEngine is an amazing API and makes ongoing synchronization much simpler and cleaner than rolling custom CloudKit logic. It would be great to see it scale better for first launch scenarios as well. Thanks again for taking the time to reply. I am not really sure whether marking file a feedback as the accepted answer makes sense here, since it does not actually help with the problem or provide any workaround. Over the years I have filed quite a few feedback reports and only one was ever addressed, and that was a UI bug. Because of that, I am honestly not very optimistic about this changing, especially since this is not something that directly shows up as a user-facing bug.

Thanks for the post, this is something I don’t think I have seen before unless I have a reference to some of the file. Definitely a head scratcher for me. Inviting other developers here to to provide there opinion of possible causes for this. One thought I have is that Xcode keeps a lot of build artifacts and project-related data in its derived data folder. This can often lead to stale or incorrect information being used by Interface Builder. Have you try to go to Product > Clean Build Folder (or Cmd+Shift+K). Do this for both projects/targets if they are in the same workspace. Even if your NIB files are separate, the custom classes (e.g., your AppDelegate subclasses, custom NSWindowControllers, or NSView subclasses) that are referenced in those NIBs might be accidentally included in the wrong target. If a class from App A is somehow included in App B's target (or vice-versa), Interface Builder for App B's NIB might try to instantiate or show properties from App A's version of that class? The Info.plist fo