Thank you. What do you think would be the difference to simply using .triangles?

Thanks, that's it. This is apparently the Objective-C documentation, while the Swift counterpart is empty.

Thanks, that could be it. But a link to some official documentation would be appreciated. The Swift documentation is empty: https://developer.apple.com/documentation/scenekit/scngeometryprimitivetype/polygon

You have an Apple logo beside your username. I understand that you are from Apple. If this is the case, I would invite you to file an enhancement request yourself, or discuss it with your colleagues directly. I think it is more efficient than asking external developers to file enhancement requests. If you don't have enough motivation to fix such things without someone pushing you from the outside, then I don't think someone who reads an anonymous enhancement request would be more motivated than you. After the little attention I got after filing literally thousands of enhancement requests, I have stopped completely because it is not worth my time.

We're talking about macOS 10.13, not macOS 13. Do you mean that Xcode 14 doesn't ship with the macOS 10.12 SDK and older? Then why does it still work in some cases?

Thanks, that makes sense.

Thanks. But none of these BSD Privilege Escalation methods work for apps on the App Store, right? Is the newer SMAppService suitable for the App Store?

Thanks. It seems that the exact same question was asked just a few hours ago: https://discussions.apple.com/thread/254321613?login=true

With Xcode 14.1, there is indeed a warning that only 10.13 and newer is supported. But it can still build a project even if the deployment target is 10.10. Until now I used the older Xcode 13 to upload my apps to App Store Connect, assuming that doing so with Xcode 14.1 would automatically raise the minimum supported macOS version shown on the App Store. But I just uploaded an app update with Xcode 14.1 and the app still shows macOS 10.10 and newer on the App Store.

That's the incredible thing: sender.pathItems.firstIndex(of: sender.clickedPathItem!) always returns nil, even if the clicked path item has the same address as the corresponding item in the path items array. Even sender.pathItems.firstIndex(where: { $0.description == sender.clickedPathItem!.description }) returns nil. And when executing that print statement more than once one after the other, each item always has a different address.

Of course I already submitted a feedback, but unfortunately I haven't been lucky with SceneKit feedbacks in the past.

Thanks for your suggestion. I tried it with the following modification, since otherwise the implicit animations would collide with my own: SCNTransaction.begin(); SCNTransaction.disableActions = true; SCNTransaction.animationDuration = 0; /* do the transform */; SCNTransaction.commit(); Although it mitigates the issue with my private project, the sample project still doesn't work as expected.

Thanks again. As I show in my answer below, subclassing doesn't work and didSet is only called once on initialization. Perhaps it's just a wrapper of some internal properties. Since I want to display a virtual path it's not easy to simply use URLs. The closest I got to only displaying the parts that I need is using pathControl.url = URL(fileURLWithPath: "asdf/asdf/asdf", relativeTo: URL(fileURLWithPath: "/")), but then Macintosh HD is always shown as the first item.

That was the first workaround I also thought of, but unfortunately each item represents a filename, so they may not be unique. But after your suggestion of setting the url I tried explicitly removing the first item from pathItems (the one for Macintosh HD) and it seems to work. The question then would be if there's a way to create a url only with the provided string components, because I'm not sure if blindly removing the first item is future-proof.

Thanks. Using an empty rule set and NEFilterActionFilterData is what I need. I had filed FB12039403. Since in the past the engineers asked me to close many bug reports and open a new one just to update the documentation, I now ask at the end of a bug report that if the documentation is wrong, to update it without the need of opening an additional report. I did that here as well.