I've got the following reply to the feedback I opened: Please close this feedback and file a new feedback that suggests making the FileManager APIs fast.. Nothing more. I've replied that it doesn't make sense to have getattrlistbulk and not the enums it uses, I hope they realize this.

Thanks for your reply. I already tried investigating with zombies turned on and even using Instruments, but they were of no help.

Maybe you just stress the system too much and that causes hectic behaviour for display. Not sure why you've chosen this particular exercise, but more than likely what you're witnessing is simply an artifact of the buffered IU updates being throttled while the system attempts to realize true state. I'm mainly doing this to make sure that under stress the app still behaves correctly, but no, it's not hectic behaviour for the display or an artifact of the buffered UI. Moving or resizing the window after this doesn't redraw the text view correctly (the text view resizes during the live window resize, but it still leaves the same space blank). It's something happening inside the text view that makes it think that the text should occupy less space. If this is some sort of durability spec on a given project, I'd log the results and see about negotiating something more representative of which the IDE may be better suited. I don't know what IDE you're talking about. Do you mean my project, or Xcode? I opened a bug report FB8745215.

I just noticed now that getattrlistbulk returns 0 for the size of files mounted via FTP. I used ATTR_FILE_DATALENGTH which workes fine for local files, but ATTR_FILE_TOTALSIZE, ATTR_FILE_ALLOCSIZE, ATTR_FILE_DATALENGTH, ATTR_FILE_DATAALLOCSIZE, ATTR_FILE_RSRCLENGTH, ATTR_FILE_RSRCALLOCSIZE, ATTR_FORK_TOTALSIZE, ATTR_FORK_ALLOCSIZE all return 0 for FTP files. Does anyone know how to get the size of those files?

It turns out that I had a small bug with reading the ATTR_CMN_CRTIME. The creation time is apparently not available for FTP files, which caused the following attribute, the size, to be read from the wrong memory offset.

When setting rate = 2 or pressing the L key while playing the video at normal speed, the video gets played fast forward. Either way rate is returned as being 0, even when doing rate = 2 in code.

I'm pressing L after pressing the play button in the AVPlayerView.

Thanks for your help, but I don't get what you mean with this: When a user scrubs, seeks, fast forwards, rewinds, uses trackpad or touch gestures or key bindings that would result in the AVPlayer changing times we may set the rate to 0 during the operation, but in most cases we will restore the rate thereafter. Who is "we"? Is it AVKit or I the developer who uses AVKit? If you really mean the latter, then why would we set the rate to 0? And how would we intercept all those operations, when AVPlayerView already does it? checking that the AVPlayer's rate is 0 or timeControlStatus == .paused should be sufficient for determining whether the video frame is not changing As I said, timeControlStatus == .paused is true even when the user plays fast forward or backward (by pressing L twice or J after pressing the play button) and even if during this time the pause button is shown and not the play button. I would have expected that whenever the pause button is shown timeControlStatus != .paused and rate != 0. In the end I really just want to know if the play or pause button is shown, so that I can react to changes in other views and seek to another frame only if the play button is shown and the user is not expecting the video to keep playing.

Unfortunately I don't have a solution. My workaround was to comment out the file coordinator line.

Thanks for your help, but cleaning the build folder didn't help. I already recreated the Archive several times, without success.

Thanks for sharing this workaround. I hope that we won't have to rely on this for too long.

Thanks for speaking to us. It's just frustrating when you don't hear anything for months about a feature that is as basic and important as an email notification.

Unfortunately no.

I've noticed this as well and filed a bug report to Apple exactly 6 months ago, still without answer. It is easily reproducible with this code:         let url = Bundle.main.url(forResource: "art.scnassets/texture.png", withExtension: nil)!         plane1.firstMaterial!.diffuse.contents = url.path         let node1 = SCNNode(geometry: plane1)         node1.position.x = -5         scene.rootNode.addChildNode(node1)         let plane2 = SCNPlane(width: 10, height: 10)         plane2.firstMaterial!.diffuse.contents = SKTexture(image: NSImage(byReferencing: url))         let node2 = SCNNode(geometry: plane2)         node2.position.x = 5         scene.rootNode.addChildNode(node2)

That's great to hear. Can anybody reply to see if I receive anything?