Aaand I've confirmed it: After restoring the VM to 15.1beta where FAF hasn't been launched under yet, then deleting all copies of FAF (which are easy to locate with my "Launch Services" app) and then installing the single new version that contains the new key, I finally see the new usage description. So my suspicion was probably correct: When prompting the user about the Local Network permission, it doesn't fetch the NSAllowsLocalNetworking value from the running app but from Launch Services, and in a way that doesn't ensure it's looking for the data from the latest or running version of the app, which it should. Which isn't really a new issue when I think about it - I believe I've noticed more than once in recent years where Finder or other services failed to register new information from the latest version of an app but instead use data from outdated versions that are still installed elsewhere. I wonder if this is even worth a bug report. It might be behaving "as designed".

Nevermind - I found a test project myself (my own SSDP Browser on github). There, indeed, setting the NSLocalNetworkUsageDescription does work. After verifying that, I checked my main app FindAnyFile again. Lo and behold! After changing the app's bundle ID, it suddenly worked! Now, the issue here seems to be: The app was already known to macOS BEFORE upgrading to Sequoia. When running it on the updated Sequoia for the first time, the prompt for Local Network appears, but it's showing the default and not my custom usage message. However, if I install and run the app for the first time on Sequoia (which I simulate by giving it a new bundle ID), it does show the custom message. So, I still believe that there's a bug in macOS 15.1, by which is doesn't show the app's NSLocalNetworkUsageDescription if it has been installed before, or possibly if there are also OLDER versions of the app around that do not contain the NSLocalNetworkUsageDescription, meaning that this information is cached somewhere else by macOS and is not updated with the LATEST app's information. Can you tell me where macOS gets the NSLocalNetworkUsageDescription text from? Apparently, it's not reading it directly from the running app's Info.plist but from somewhere else, e.g. the LS database? If it's that, I could dump that to check why it doesn't get updated - or maybe it's updated there but the macOS code looks for the first app instance in the LS database instead of looking for the latest. Something is clearly wrong there and I'd like to help figuring out what, so that I can provide a clear and reproducible bug report.

Actually, the cause might be that, since I'm using a NSSearchToolbarItem on macOS 11 and later, I need to invoke its beginSearchInteraction method instead of making its searchItem the first responder. While doing the latter used to work, this has apparently become unreliable in macOS 15. It's weird that it sometimes still works, though, making this tricky to notice and debug.

Thank you for double checking that it should work on macOS. yes, I showed the plist of the app that I had launched. Not localizing the text. App is signed with dev id and notarized. Do I need special entitlements for this to work? App is not sandboxed if that matters. Can you share the app that you verified to work so that I can compare?

Well, that's just the thing: That text is not displayed in my tests. Instead, it shows a generic msg. In both 15.0.1 and latest 15.1beta. Here's the prompt that appears and the Info.plist of that very app:

BTW, there's another issue with the new Local Network permission: There's no way to provide a "UsageDescription" for it, like for all the other ones, in Info.plist. (At least, Xcode 16.1b3 doesn't list any under the "Privacy - …" keys)

Adding to my last "Later" comment: No, sometimes, even new versions with the same Signing ID get added as unique entries. I can't make sense of when this happens and when not, but here's the result: And all 3 "Find Any File" items point to the same file and not, as expected, to the different versions that are all on the disk, at different paths.

Bundle ID and designated requirement are all the same. Path is not, as mentioned above. UUID is also different, as they're different builds. But that just confirms what I suspected: That the privacy permissions are separate for different versions of the same app. However, my concern was that even if that's done on purpose, then System Settings.app / Privacy / Local Network shouldn't show the SAME app version multiple times but should list separate apps, i.e. the different versions it has recorded so far. To illustrate: ... Here I was going to reproduce the issue and show you a screenshot of the Settings app showing multiple instances of the same app, each pointing to the same path. But now that I had re-installed Sequoia and run each app version, they do not multiply in the Local Network list any more as they did before. And the screenshots of this effect that I had done before in the VM are lost when I borked that system. Sigh. Alright, let's drop this for now. I'll get back to this thread should I encounter the problem again. Actually... I just read https://developer.apple.com/forums/thread/737416 which confirms that it's possible that multiple app instances are listed. So you know about this effect. Then let me get back to the issue with that: If you have multiple app instances listed under "Local Network", and if you right-click on them to Reveal them in Finder, you'll get the SAME app revealed each time. This means that the code that lists the multiple instances in the Settings pane does not keep them separate for the sake of indentifying them to the user, which is clearly a bug. Agreed? I'd write a bug report but since I fail to be able to reproduce this, I believe it wouldn't get even any attention. But if you do, could you do something about it, please? Later Ahh - it appears that app versions with the same Signing ID are listed as one instance. Only if the Signing ID is different, e.g. for MAS vs. Indie releases, it's listed multiple times.

To get started, look at the SRVResolver sample code. In case others run into this, let me add this warning about the SRVResolver code: In the function QueryRecordCallback, the code first makes some assertions before checking the errorCode. That's likely to cause problems because if you get an error (such as if a user doesn't give your app permission to use the network calls), the asserts may get triggered. To fix this, move the assert calls inside the code that checks for error == 0.

In case others run into this, let me add this warning about the SRVResolver code: In the function QueryRecordCallback, the code first makes some assertions before checking the errorCode. That's likely to cause problems because if you get an error (such as if a user doesn't give your app permission to use the network calls), the asserts may get triggered. To fix this, move the assert calls inside the code that checks for error == 0.

Thank you for looking into this, Quinn. (The VM I had used had no snapshot (stupid of me), so when I borked it, I had to ditch it and start over, installing a new system from scratch, and then installing Xcode and all the other tools again, which took me quite a while that I would have liked to avoid. Also, I'm glad to be using VMware on a Intel so that I can make snapshots, as the support on Silicon is still a bit ... lacking in this regard :) Ah, creating a new user - of course! I should have known that. Also, there's another related issue: In my testing with a fresh VM I noticed that when I download two versions of my app (release and beta, both signed with my dev ID and notarized, and then both downloaded from same server and thus quarantined), I found that macOS prompted me twice for the "Local Network" permission, i.e. one for each app version I launched. That's different from TCC permissions, where a single permission was always applicable to ALL versions of an app with the same signing ID. And even worse: Even though the System Settings then list the app twice, both use the same name even though I had named them differently, and right-click - Show in Finder shows the SAME app instead of the two separate apps that required to be acknowledge when they accessed the network. So, that appears to be another (minor) bug, though I don't know which would be the proper behavior: Require the permission only once for all apps with the same signing ID, or require them for each version but then list them also properly as individual instances with their own names and file system paths. Can you confirm this misbehavior?

After some more digging, I suspect that the information is stored in the various /Library/Preferences/com.apple.networkextension.….plist files. I tried to alter the file, but that led to the system refusing to boot (fortunately, this was done in a VM). I wonder if there are APIs to access/alter these files in a way that won't damage them.

Thanks for the warning. I still have an app that runs even on 10.11, so I build it with Xcode 13.4 (running on Monterey) and then use Xcode 14 or 15 to upload it to Apple.

That looks like decomposed (NFD) unicode form, where an ä is a combination of an a and the two dots, encoded in separate unicode chars. And somehow Xcode(?) is unable to compose them as they should be. Weird. You might be able to fix this by running the strings thru code that re-composes into NFC format, but I guess you have already fixed them all by hand.

Oh my. 8 Years later and I am now seeing the same issue: After making changes to the state of my window, I invoke [self invalidateRestorableState] from my view controller, and yet, when I quit the app soon after (e.g. within a few seconds), the encodeRestorableStateWithCoder handler is not called and then the app restores an older state at the next launch. This is bad.