The documentation in the header file for NSPathControlItem also states: "NSPathControlItem should not be subclassed." I tried doing so nonetheless, but sender.clickedPathItem as! MyPathControlItem fails with the error Could not cast value of type 'NSPathControlItem' (0x20ae78870) to 'MyPathControlItem' (0x1005c0688). So it seems like any custom subclass is replaced again with NSPathControlItem.

Find below my sample code that shows how it's impossible to associate any custom data with a path item. PathControl.pathItems.didSet is called only once when explicitly setting them in loadView(), and in the action selectPath(_:) the path items are not of my custom subclass PathControlItem but are again NSPathControlItem. They change their address on every click, and finding the clicked path item in the pathItems array always returns nil even if by comparing the logged addresses it appears to be there. class ViewController: NSViewController { override func loadView() { let pathControl = PathControl() pathControl.action = #selector(selectPath(_:)) pathControl.pathItems = ["a", "b", "c"].map({ title in let item = PathControlItem() item.title = title item.customData = title return item }) view = NSStackView(views: [pathControl]) } @IBAction func selectPath(_ sender: NSPathControl) { print("click", sender.clickedPathItem!.description, (sender.clickedPathItem as? PathControlItem)?.customData, sender.pathItems.description, sender.pathItems.firstIndex(of: sender.clickedPathItem!), sender.pathItems.firstIndex(where: { $0.description == sender.clickedPathItem!.description })) } } class PathControl: NSPathControl { override var pathItems: [NSPathControlItem] { didSet { print("didSet", pathItems) } } } class PathControlItem: NSPathControlItem { var customData = "" }

Could you post the URLs that you're using to see the respective App Stores?

Could it be that you sent the wrong link for Slovak? It seems to be the same for Finnish. Otherwise it really seems like something's not working. Have you double-checked that selecting the respective language in App Store Connect shows the expected text? If that works as expected, I would use the Contact link at the bottom of the App Store Connect website and explain the issue.

I still have to come up with a solution myself.

Did you just download the Ventura installer and ran it? Because as I wrote in the original post, I wasn't able to install Ventura either.

I don't know the direct solution to your issue, but I'm using appstoreconnect-swift-sdk on GitHub to interact with the API. I found it quite easy to upload images, but feel free to ask if you're having problems.

Yes, that's the entire code in the project.

Hi Quinn, thanks a lot for your help. I created an empty Xcode project with the "Command Line Tool" template, pasted your code, and ran the built executable in the Terminal. When passing the pids for all the trustd processes I see in Activity Monitor it always returns the expected path, /usr/libexec/trustd. But then I created an empty Xcode project with the "App" template and created a main.swift file again with your code, and when running the built App/Contents/MacOS/app in the Terminal, I get the same error that I mentioned before: Error Domain=NSOSStatusErrorDomain Code=100001 "EPERM: Operation not permitted". Do I need to add special entitlements in order to make it work?

Yes, they are both sandboxed. Sorry if that wasn't clear. Even with sudo I still get the same error Error Domain=NSOSStatusErrorDomain Code=100001 "EPERM: Operation not permitted". It's only the processes in /usr/libexec, all others seem to work and return some path. I also don't see any sandbox violation reports in the Console. Even just searching for com.apple.sandbox.reporting doesn't show any results. The instructions given in the link you posted say that I should post 3 different lines in the Console search field, but in the screenshot it looks like pasting the string type:error should appear as a token with the text error, while I still see type:error. So I searched for error and manually changed the search scope to "Message type", but again no results.

Thank you for your input. It sounds like you're saying that I can set up rules to specify what flows I get. But what I'm doing right now is specifying an empty set of rules NEFilterSettings(rules: [], defaultAction: .filterData) which allows my code to manually filter all flows, right? Why should I specify any custom NENetworkRule if I can manually inspect all flows anyway?

Thanks for your help. I've created FB13238546. I already have an App Group entitlement with value $(TeamIdentifierPrefix)org.domain.app for the main app and the extension. I cannot reproduce the crash myself, not with the App Store app and not in Xcode.

Thank you. I already filed FB12057582 in March 2023 but got no response for now. It would be great if you have any power over speeding that up. Since I'm planning on releasing this in an App Store app, I want to be sure that only process names that can be securely determined are displayed as such, while all the other ones, which currently include the mentioned ones (trustd etc.) will be shown with red text and a warning. It would be great if all legit processes could be displayed as such sooner or later (but preferably sooner). And thank you for predicting that a TSI probably won't change things here. It's always frustrating discarding a TSI that simply results in a mere confirmation that it's a bug and one will have to wait for it to be solved.

Thanks. So rules are more performant than custom filtering code and have no other practical advantage. Since I want to display all flows to the user of the app anyway, then there's no reason for me to use rules at all and simply get all the traffic.

Thanks again. You may find that this is a lot of networking flows that the user ends up having to acknowledge when the filter is first turned on. Do you mean that enabling the filter generates a lot of network flows? In any case, I would like to give the user the chance to inspect all flows, but they are initially all allowed by default, without need of user interaction.