We confirmed that we do have unique build UUIDs for all distributed apps. Our app is distributed through the Mac App Store. We changed our app name recently. Could that have caused this issue? Could this issue be introduced if a customer used the App Store and Test Flight to update to different versions of our app? It's still not clear to me why turning on all Local Network switches for the app (however many there are) doesn't fix the app's Local Network permission issue. Any thoughts why?

It's a Mac app built using Mac Catalyst based on our iOS app code. Customer complaints are only for our Mac app, not our iOS app. It seems like (our guess) macOS uses some set of app data (e.g. app name, location, entitlements, etc) to determine if macOS should create a new entry in the Settings > Privacy & Security > Local Network list. Could some difference between a prior version of our app and our latest version of our app be causing the multiple entries in the Local Network list? Why would our app not actually have Local Network access even though all of the switches are turned on? Any thoughts?

Some of our macOS app customers are reporting this same issue for our app. The fixes listed in this forum and others that I have found are much too technical for our customers. Will updating to a specific macOS release and uninstalling/reinstalling our app fix this issue? Are there work-arounds or fixes that we can implement in our App Store app code? Are there user-friendly work-arounds or fixes that our customers can perform on their own?