SwiftUI List performance

Inside System : Library I have the folder AssetsV2 with large Folders. com_apple_MobileAssest_iOSSimulatorRuntime 85.83 GB and .com_apple_MobileAssest_xrOSSimulatorRuntime 56.23 GB. Also _appleTVOS.. 21.41 GB and _watchOS.. 18.87 GB. I've tried xcrun simctl runtime list and delete. After a computer restart xcrun reported Total Disk Images dropping from 267.9G to 106.8G BUT no change to Finder reported sizes. DaisyDisk showed 99G free and now 240G or 68G A lot of disk images appear in Disk Utility but eject doesn't work for most of them, maybe none. In Xcode I see a lot of simulators. I was able to delete many of them but no change to memory reported by the Finder. It looks like I've tried the suggestions above. I've run out of ideas.

Could you please use Feedback Assistant to report an issue for this problem; start the issue soon after reproducing the bug so it will hopefully capture performance information.

I am encoutering the same problem with a universal iOS simulator version (18.5) Because the old version (18.5) is missing from this XML, Xcode and mobileassetd seem to have lost track of it entirely. I managed to get Xcode to recognise it, but Xcode chooses to soft delete instead of ing the disk. Running scan-and-mount identifies the orphan simulator: > xcrun simctl runtime scan-and-mount > xcrun simctl runtime list == Disk Images == -- iOS -- iOS 26.2 (23C54) - E2B78652-EDF6-450D-BC2C-2F0B11B3AD95 (Ready) -- unknown -- - CE40DFD4-ACAC-4A6B-975A-51148DA604B0 (Verifying) Total Disk Images: 2 (7.8G) [Note: 1 image(s) are of unknown size] > xcrun simctl runtime list == Disk Images == -- iOS -- iOS 18.5 (22F77) - CE40DFD4-ACAC-4A6B-975A-51148DA604B0 (Ready) iOS 26.2 (23C54) - E2B78652-EDF6-450D-BC2C-2F0B11B3AD95 (Ready) Total Disk Images: 2 (7.8G) [Note: 1 image(s) are of unknown size] Then I tried to directly delete the simulator: > xcrun simctl runtime delete 22F77 > xcrun simc

Like the message said, NSKeyedUnarchiver will require a complete list of all possible types for better security in the future.

Thanks for the post, I think your understanding is great and this is very interesting how you use the API and how it behaves. Your observations touch on some subtle behaviors and design philosophies around file resource handling with (and related APIs) in the frameworks that I have been reading the documentation looking for those. However, most of the time I find it better to create a test project to see how it works. I am not an expert on that field, so we should involved someone from that team as it seems these caches are generally managed by the system to balance performance and resource usage, and not strictly tied to any particular run loop like the main or a background thread's run loop? I need to write some code as maybe creating instances or fetching their resource values on background threads is indeed recommended for performance reasons, especially for potentially blocking I/O operations. As you suggested, using with more control over caching might suit your needs if you require fi

Then when the user manually adds the app, it loads in as the app, not the service, so FDA is only given to the app. Is this a permissions problem that keeps it from being populated to FDA screen or is there something else keeping the system from tying the app to the service? Taking a look at your app, I realized that it's not really properly constructed. The expected pattern here is that there are two different executable components: (1) The containing app bundle. Generally speaking, this is a standard interactive application. Its role (along with whatever else it does) is to manage the SMAppService. (2) The target executable the Launchd.plist. This is specified in the plist as described here: -In the agents and daemons property lists, replace the Program key with the BundleProgram key and make the path relative to the bundle, such as Contents/Resources/mydaemon. Note that the Resources directory is an invalid recommendation (r.168792717). Per Placing content in a bundle and TN2206, Nested Code, I wo

Thanks Albert for replying. Is it an array where you use NSKeyedUnarchiver validateAllowedClass:forKey:? I have a lot of classes with SecureCoding, and I cannot find from the warning in the log where it comes from. What is surprising is that I have commented out all the NSNumber.self in any list of decoder.decodeObject(of:, key:) like if let format = decoder.decodeObject(of: [NSArray.self/*, NSNumber.self*/], forKey: formatKey) as? [[Int]] { And still get the log. *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSNumber' (0x204cdbeb8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{( 'NSArray' (0x204cd5598) [/System/Library/Frameworks/CoreFoundation.framework] )}'. This will be disallowed in the future. *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSNumber' (0x204cdbeb8) [/System/Library/Frameworks/Foundatio

Thanks for responding. I haven't yet been able to reproduce the issue in a small test project so either they made changes in a macOS update or there is some timing issue and/or way the NSURL is initialized in my real project teases the issue out. But I promise I got stale value for nonexistent NSURLIsHiddenKey until I started explicitly dumping it. In my real project the URL comes for -fileURLWithPath: (and initially created on a background thread). My real project is large and complex so when I have more time I'll have to see if I can isolate the issue in a small sample. Due the request by iOS and the server cache the user may see some discrepancies or additional nuances in how and caching behave, particularly regarding stale values. I'm on macOS. Explicit cache management is recommended, especially when dealing with URLs that may have changed state (e.g., deleted or modified), to ensure your application behaves predictably across different environments and runtime sessions. Also CFURL is documented to have

Hey Claude, always the most interesting questions. But in all honesty, I don’t know how are you getting to that. I need more context and the full scroll of warnings as right now it looks like warnings relate to security improvements in regarding unarchiving objects. Is that a TestFlight build? Can you provide here more information about the build and code causing this? Is it an array where you use NSKeyedUnarchiver validateAllowedClass:forKey:? Would be great to see the sydiagnose for these warnings aim to inform you about potential security risks when unarchiving data from untrusted sources? If your array contains objects and you've only added to the allowed classes list To resolve this warning, you should include all specific types contained within the archived data that are expected to be decoded. If your array indeed contains objects, update your allowed classes. Any chance you can produce a focused sample so we can take a look of the those warnings? Looking forward to see the focused simple proj

Hi there shimanopower, The difference in rotation angle is expected on iPhone 17 due to a different sensor rotation. Looks like your 2nd line in the first code block is not taking into consideration any video rotation already being applied in the AVCaptureConnection to your output. Here's some sample code: let videoRotationAngle = self.videoRotationAngle let videoConnectionVideoRotationAngle = self.videoOutputConnection!.videoRotationAngle // Subtract how much we should apply (videoRotationAngle) by how much is already applied (videoConnectionVideoRotationAngle) let rotationAngleToApply = videoRotationAngle - videoConnectionVideoRotationAngle var videoRotationTransform = CGAffineTransform(rotationAngle: rotationAngleToApply * .pi / 180.0) // Convert from degrees to radians To achieve best performance, set your video rotation angle on your video data output's connection to 0 — which will result in unrotated video from the source. But be aware that the source might come from a different sensor rotation