iOS14 Multicast entitlement fails in TestFlight, works otherwise

We have followed the guide to obtaining and enabling multicast entitlement for our app as detailed on this forum post.
The multicast entitlement:
Code Block
   <key>com.apple.developer.networking.multicast</key>
  <true/>

is in the provisioning profile. It's in the entitlements file. It's in the App ID capabilities. Target Build Settings references the .plist containing the entitlement. There are no build warnings about entitlements. There are no warnings on upload to AppStoreConnect.

The app receives UDP OK on-device when building from Xcode.
It doesn't receive UDP when installing the same build from TestFlight.

Any suggestions where to look next are most welcome.

We are out of ideas apart from starting a long series of low level tests to isolate the issue, but don't really have the time to debug the App Store Connect provisioning system.

Summary: We have pre iOS 14 devices working fine alongside an iOS 14 device that works fine until TestFlight. With all the multicast enablement steps followed.


First things first, I recommend that you retest on iOS 14.2rc. That release contains a number of important local network privacy fixes.

If that doesn’t help, post back and I’ll proceed from there.

Share and Enjoy

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

Good suggestion eskimo , just updated from iOS 14.1 to iOS 14.2 (on iPhone 6S) and still no UDP reception.
(Warning , you also need a 10GB download of Xcode 12.2 RC to deploy to iOS 14.2 )
We tried uninstalling and re-installing via TestFlight - still nothing.

We left it for a few hours, then opened the app again and were prompted with a pop up :

"xxxxx would like to find/connect to local devices on your network"

We clicked OK and now it does receive the UDP packets.

So - the question is should it have displayed that pop up earlier and if so how can we make it appear on first install ?
One Stackoverflow says this is a Bonjour request, but this app does not use Bonjour. So should I add this entitlement to ensure the pop up appears sooner ?

Another Stackoverflow post suggests to move minimum build target to 12.0 which is what we have, so maybe we should increment this more ?

Any more suggestions welcome.

how can we make it appear on first install ?

That’s FAQ-8 in the Local Network Privacy FAQ.

the question is should it have displayed that pop up earlier

Are you only receiving UDP broadcast packets? That is, you’re not sending any packets to the local network? If so, on 14.2 I’d expect to see the local network privacy alert triggered when the device receives the broadcast and attempts to delivere it to your app.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Thanks again eskimo for the link, see Triggering the Local Network Privacy Alert.

We added the UDP write functions which are in Swift, and this is an Objective C app, so had to go through the motions of creating a Swift bridging header to import into ObjC - see link. Also wrapping the function calls in a class with @objc modifiers.

The Network Permissions request [i] now pops up immediately which is a big improvement. It still takes about a minute for the UDP to start being received after that, provided you unload and re-open the app. But it seems to start reliably enough now.

Side note: I get a device black screen when running the app in debug mode on iOS 14.2 with Xcode 12.2 RC.

[i] Here's the exact text of the pop-up to maybe help people find this post:
App Name would like to find and connect to devices on your local network. This app will be able to discover and connect to devices on the networks you use.

this is an Objective C app

The Triggering the Local Network Privacy Alert post has a link to another post which contains Objective-C code.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
iOS14 Multicast entitlement fails in TestFlight, works otherwise
 
 
Q