SwiftUI List performance

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

The first image with time 9:35 shows a list of transactions sorted by date using List{}. The column headers are displaying in DARK mode with a black stripe, and header items have switched from black to white. The second image (9:39) changed to a ScrollView {}. The column headers did not change color, but scrolled out of the view. The header is showing that the text has changed from black to white while scrolling. The final image is a ScrollView with LazyVStack pinnedViews. Google suggested using .toolbarColorScheme(.light, for: .navigationBar) at the bottom of the ScrollView to prevent the header stuff from changing color. So my question is: Is this change in color for these views a bug or is this normal behavior with Liquid Glass?