SwiftUI List performance

While this isn't the answer I had been wishing for it does give me a lot of food for thought. Thanks The Eskimo for looking into it! [quote='874248022, DTS Engineer, /thread/814022?answerId=874248022#874248022'] When it rotates a file, the system calculates how fast it filled up. [/quote] So wrt this note, I understand it's more complicated than just rotating a single file, but still it sounds like everyone writing into the Unified Logging system can contribute to this. It strikes me at least one strategy (if not a preferable one), is to disable logging for all other processes/subsystems (even some of the native OS processes) that tend to be noisy too? Of course this is meant as a temporary and desperate measure, in theory it should raise our survival chance? And another thought, what if we disable persisting, but then have an external party help redirect our logs to be persisted? I first thought the xctrace record --template Logging might be a good candidate for this task but later found out the deferred, or

Hello Kevin, hello All I have tested your suggestions. Sadly to no avail. The location of the files is not crucial nor using a signed version of the app. I have also setup a new project on my macOS14 Mac with the same result. So it is not a macOS26 problem neither. That makes me wonder more and more. My AppStore app (bcAnalyze) that does use the related file feature with these files works well on any macOS with these files. The code I am using is older dating back ca. 10 years (originated in Obj-C days and is now Swift since ca. 4 years). The idea of adding a security scoped bookmark to the sidecar file is tempting, but wouldn't help since the original application producing the the sidecar file is more than 10 years old and users may have already millions of file pairs. There shouldn't be a difference between SwiftUi and AppKit as front-end, but I may also try this in the next days. Since my AppStore app works, I must oversee something little that has this big effect. I can't otherwise explain the ne

Welcome to the forum Warren85. It is hard to say with such limited information. You should read this to get tips on how to post on the forum: https://developer.apple.com/forums/thread/706527 This being said, please tell: Is it an iOS app (for iPhone / iPad) ? Is it SwiftUI ? Show the code of the app (ContentView if SwiftUI), we shall help you. Or at list the part where the initial content should show on simulator.

You would want to make sure that the AIDs are listed exactly as assigned to the exact same Bundle ID they are assigned to. You should check the contents of the provisioning profile you are using to build the app against the values in the entitlement file. You can check the provisioning file by either through Finder quicklook, or by opening it in Xcode.

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? Setting a large resource fork like mentioned in that Stackoverflow post causes the mentioned error Argument list too long. Using the Terminal command cat file > file/..namedfork/rsrc like suggested by the first answer in that post to set the file itself as a resource fork of itself works (listing the extended attributes with ls -l@ file shows com.apple.ResourceFork 34669586 for my 34 MB test file), but calling copyfile as in the code I posted in my first post still works, even when the destination is on a FAT volume connected via SMB. When calling fsetxattr as in the code below, I can only set a custom attribute named asdf, but when using com.apple.ResourceFork the function doesn't seem to do anything. let f =