Wow, I just posted a similar thread: https://forums.developer.apple.com/thread/127026I have no response at all since September 2019, when I started using the Feedback Assistant.

After posting this, I found another developer with the same issue: https://forums.developer.apple.com/message/398429

Awesome finding, thank you very much.Your eye for detail finally stopped pulling my hair out on Xcode 10.3 and 11.3.1 on latest macOS 10.15.3. 😉

I've sent an email to Quinn "the Eskimo" from Apple, with a request to respond here.

Just leave your Info.plist untouched, it should show value $(PRODUCT_NAME) for Bundle Name. In the Build Settings for your target, search for "Product Name". This is by default set to $(TARGET_NAME). Change this to the desired name including the space(s) and build again. Now the app name is shown including the space(s), even when exceeding 12 characters.

Thank you Quinn, I've filed a bug in Feedback Assistant, see: FB8779490

I can confirm that the issue is still present in iOS 14.0.1 (18A393).

Great news, the problem seems to be resolved in iOS 14.1 (18A8395). We did multiple tests and every time the app is launched after a re-install, the Local Network permission is shown in the app. Also the Local Network toggle is present in Settings App -> Privacy -> Local Network. Added bonus Finally it's possible to consistently reshow the Local Network permission - https://developer.apple.com/forums/thread/663839 in the app without uninstalling it first, by going to Settings App -> General -> Reset -> Reset Location & Privacy Thanks Apple for resolving this.

The issue is back in iOS 14.2. Apple, Apple, Apple. Shame on you.

Dear Apple, Every day we receive dozens of angry emails of paid app users. Our app can't communicate with their devices over the network, because Local Network access is not applied and the toggle is NOT present in the iOS Settings app. Please have the decency to respond in this forum and/or Feedback Assistant and resolve this asap. And improve your Source Code Management process, to ensure that resolved issues will be merged in every new release. Best regards, Martijn

This has NOT been resolved yet in latest iOS 14.3 beta 2 (18C5054c). Is everybody still ***** from your M1 launch party? Come on, fix this asap. We're loosing customers every day due this recurring bug.

We were granted the entitlement by email after 6 days. And just followed the instructions from Quinn - https://developer.apple.com/forums/thread/663271 for the New Process to use the entitlement. The steps in "Create a Provisioning Profile" refer to the documentation of adding a development profile. We created that, added our Test Devices and used the saved profile in Xcode 12.2. Since this is a development profile, we only changed "Signing (Debug)" in step 4 of "Configure Your Target" to manual signing. So far so good, we can now finally build and run on our devices, while receiving UDP data Questions Is this entitlement only required for debug on real test devices? Or does the app needs to be signed for App Store Release too? If so, can that be done with the same development profile, or should we follow Developer Account Help > Create an App Store provisioning profile - https://help.apple.com/developer-account/#/devbd904d1a5? Any help is appreciated from other developers, who successfully approved their App Store version with the multicast entitlement

@Matt Eaton thank you for your prompt response. We were a bit inspired by the remark from pascalrs : After adding it to our App ID in the developer portal and adding it to the entitlements.plist manually, Xcode was kind enough to automatically generate the new provisioning profile. So In Xcode Project we did select the project and the iOS target. At the Signing & Capabilities tab, we have the Signing (Debug) section, where we disabled Automatically manage signing and added the development provisioning profile according to the instructions from Quinn - https://developer.apple.com/forums/thread/663271. Below this is the section Signing (Release and Ad Hoc Distribution), which is still set to Automatically manage signing. The Xcode Managed Profile has a small info button. When clicking it, the second row showed that it was updated today. Scrolling down to the Entitlements section, shows that com.apple.developer.networking.multicast is added. In order to validate this, we archived the Build. We submitted it to App Store via Xcode. While using automatic signing, the overview showed that the entitlement was included. After deleting the app from an iPhone with iOS 14.2, we installed it from TestFlight. It works flawless with UDP discovery for DLNA devices: The system alert with Local Network access permission was shown at the correct timing. Accepting it would instantly report responding DLNA certified devices These devices could be controlled, similarly as compiled with Xcode 11 and running on iOS 13. The Local Network access toggle is shown in iOS System settings -> App Name Uninstalling the app and launching it, will trigger the system alert with Local Network access permission again. Based on this TestFlight observations, do you expect that a Distribution Provisioning Profile is required, or can we safely rely that the Xcode Managed Profile has been correctly updated automatically (automagically)?

We have the exact same problem. Using Auto-Fill to sign in the LoginVC works flawless on an iPhone SE 20202 with iOS 14.2. But using it to suggest a strong password on our ChangePasswordVC gives the same message in the Xcode Debug Console: [AutoFill] Cannot show Automatic Strong Passwords for app bundleID: com.domain.appname due to error: Cannot identify the calling app's process. Check teamID and bundleID in your app's application-identifier entitlement Running the same on an iPad Pro with iOS 13.7 works flawless. Questions: What has changed on iOS 14? What should we do to resolve this? Can this be related? The documentation of the Associated Domain File - https://developer.apple.com/documentation/safariservices/supporting_associated_domains shows a new section at the bottom about macOS 11 and iOS 14: Starting with macOS 11 and iOS 14, apps no longer send requests for apple-app-site-association files directly to your web server. Instead, they send these requests to an Apple-managed content delivery network (CDN) dedicated to associated domains.

Are we missing something? Support from Apple. As always. For the last months I've spent more hours per week in debugging Apple issue than developing apps, by: Pulling my hairs out while investigation the craziest behaviour. Reporting issues extensively to the no Feedback Assistent. Searching, reading and posting on the Developer forum.