com.apple.developer.networking.multicast is granted but isn't found

Additional Info:
I just learned that the team ID submitted with the entitlement request was not the organization team (and doesn't match the App ID prefix). Maybe this makes a difference when being granted an entitlement?

The team ID was the issue. I replied to the email from Networking and asked for the team to be changed so that it matches the App ID prefix. The new entitlement is now showing up when I create a new profile.

1-Do you know if it is needed to add the com.apple.developer.networking.multicast entitlement to only receive UDP broadcast packets?

2-Do you know how long Apple takes to approve /reject to add the com.apple.developer.networking.multicast entitlement?

We fill this form a few days ago: https://developer.apple.com/contact/request/networking-multicast, but we didn't receive any email/notification yet.

We need to fix this issue as soon as possible, because we have to update our apps, to be compatible with iOS 14. These apps controls various IoT devices, and with iOS 14, we are not able to receive UDP packets (it works with iOS13.6 and with iOS14 running under simulator)

Quinn / Eskimo,

I'm not sure if other entitlements require manual code signing, but this specific one does not - or does not anymore. 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.

I'm not sure if other entitlements require manual code signing, but
this specific one does not

Yeah, I thought that might be the case. When I wrote up the new process I was being conservative, in that I didn’t have time to test automatic code signing and I absolutely knew that manual code signing would work. I’ll update the post at some point.

Thanks for confirming!

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

We were granted the entitlement by email after 6 days.
And just followed the instructions from Quinn 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

1. Is this entitlement only required for debug on real test devices?

2. Or does the app needs to be signed for App Store Release too?

3. If so, can that be done with the same development profile, or should we follow Developer Account Help > Create an App Store provisioning profile?

Any help is appreciated from other developers, who successfully approved their App Store version with the multicast entitlement

Regarding your questions, @Martijn; if you plan to release your application to the App Store then you will need to create a Distribution Provisioning Profile with the Multicast Entitlement using the process you described.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@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.

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)?

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)?

It does seem that this is working for you, and if you want to continue with this workflow, that is up to you. I feel compelled to mention that using a Distribution Profile is a standard App Store practice when submitting builds. Furthermore, creating a profile that contains an entitlement and is set to a particular release configuration has always been a technique that I have found easiest to manage when trying to sort out what profile goes where and for which app and configuration. For distribution purposes I always recommend doing the same because that way you do not have to hunt for the managed profile being used for a specific configuration.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com