iOS 14 Local Network Privacy

Question

Created Sep ’20

Replies 10

Boosts 0

Views 7.4k

Participants 5

Hi,

We develop an app that sends multicast requests on the local network in order to look for our proprietary hardware (using sockets) and I understand that it now requires the Multicast Networking entitlement (for which I've applied and received no response from Apple yet).

However, I'm concerned about the app currently in production on the App Store, and how it behaves on various versions of iOS. Especially, it seems our app (built with Xcode 11) is still able to send multicast requests even if run on an iOS 14 device. However the app built with Xcode 12 systematically fails to send requests on the local network (through CFSocketSendData) on the same iOS 14 device, the local network access being properly granted by the user.

Hence my questions: Is the Multicast Networking entitlement only required for apps built since iOS 14 is available (so with Xcode 12)? If so, how long do we have before an update is required with the proper entitlement? Or have I missed something?!

Thanks for your time.

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’20

Especially, it seems our app (built with Xcode 11) is still able to
send multicast requests even if run on an iOS 14 device. However the
app built with Xcode 12 systematically fails to send requests on the
local network (through CFSocketSendData) on the same iOS 14 device,
the local network access being properly granted by the user.

A change in behaviour based on the linked SDK is not uncommon. I believe there’s a combination of two things in play here:

Your Xcode 12 build must include NSLocalNetworkUsageDescription in its Info.plist.
Both builds can access multicast because the system does not currently require the com.apple.developer.networking.multicast for BSD Sockets clients (which includes CFSocketSendData).

As to when this second point will change, I have no info to share on that topic (r. 68279716).

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

0

Answer 2

patatrouf OP

Sep ’20

Thanks Quinn for your quick response.

Actually I do define NSLocalNetworkUsageDescription in Info.plist as our app also uses the GoogleCast SDK. The LNA system popup is properly displayed with our message the first time the app (or GCK) accesses the local network.

So if the system does not require the multicast entitlement yet, there would be no reason for the app built with xcode 12 to fail to use BSD sockets, whereas the very same code built with xcode 11.6 works fine (which I've just confirmed with my MBP still using xcode 11.6).

If the change of behaviour you mentioned is confirmed, do you think this is a bug? If so, shall I file a bug to Apple? And do you think there's a chance for it to be fixed in the future?

Finally, as my problem could have a totally different cause, do you have any hints to share to help me debug the CFSocketSendData call returning an error?

Thanks again.

0

Answer 3

DTS Engineer OP

Apple

Sep ’20

If the change of behaviour you mentioned is confirmed, do you think
this is a bug?

Honestly, I’m not sure. I’ve been playing around with various local network privacy scenarios on iOS 14. Using BSD Sockets for multicast has been quite reliable for me, and I’m using Xcode 12 exclusively. However, it’s not uncommon for folks to run in trouble here, partly because the BSD Sockets multicast APIs is littered with gotchas.

At this point I think it’d be best for you to open a DTS tech support incident so I can dig into your specific case.

Finally, as my problem could have a totally different cause, do you
have any hints to share to help me debug the CFSocketSendData call
returning an error?

CFSocketSendData returns a value of CFSocketError. If its value is kCFSocketError then it’s likely that the real error will be in errno.

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

0

Answer 4

patatrouf OP

Sep ’20

Hi Quinn and thanks again for your time.

I opened a DTS incident, here is the follow-up : 747881523.

Meanwhile, I checked the errno and it's equal to 65 (<No Route to host> I presume) right after the call to CFSocketSendData fails. It seems the route to the UPnP host:port (239.255.255.250:1900) cannot be established.

Finally, I also observed that I don't reproduce the issue when building the app with xcode 12 and running it on an iPhone 6+ with iOS 12.4.8. So far, the issue only occurs with the most common configuration: xcode 12 and a device on iOS 14.

0

Answer 5

doive OP

Nov ’20

Hi Patatrouf - did you find a resolution to your problem?

I'm in the same situation. I'm working on an app that uses SSDP to detect UPnP drives on a users' local network. We recently released an update that was built with Xcode 12 which is now slow to find devices, if it finds them at all (complaints seem to be solely via iOS 14 devices). We've added the appropriate bonjour services and privacy requests to our info.plist, which I believe should be enough for things to continue to work as they did before.

Having compared the app that was built with Xcode 11 and the most recent code that we're building with Xcode 12, I'm hard pushed to see what has changed.

Thanks.

0

Answer 6

patatrouf OP

Nov ’20

Hi Doive,

We've indeed investigated furthermore with Quinn through the DTS incident ; he has reproduced the issue and filed a radar for the engineering team. It seems it's a difference of libraries used by Xcode 12 and previous versions of Xcode that brings this regression.

What we've observed using Xcode 12 is that the first message you send to a newly created CFSocket always fails, even if the user has already authorised the app to access the local network. The very same code works fine when built with Xcode 11.

As it was the case for my app, I made two workarounds ("ceinture et bretelles" as we say in France):

I reuse the same CFSocket as much as possible. Your app will have to be aware of network state changes and of switches between background and foreground in order to destroy / create the CFSocket, otherwise it will fail to send messages.
If a send fails, I always try it again once

Quinn also confirmed me that, for the time being, CFSockets can still send multicast requests even if you have not (requested, obtained and) included the Multicast entitlement to your app. But, as it's considered a bug, we have to be prepared for a later iOS 14 update where this entitlement becomes required even when using CFSockets.

Hope it helps,
Aurélien.

1

Answer 7

DTS Engineer OP

Apple

Nov ’20

Oh, one other thing: Many of the nastier local network privacy problems are resolved in 14.2. If you’re still having problems in this space, make sure to re-test on that release.

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

1

Answer 8

patatrouf OP

Nov ’20

Quinn, I gave it a try with the test app I made back then and, unfortunately, the first message send still fails for every newly created socket. App build with Xcode 12.2 and run on iOS 14.2.

Here is the test app by the way: https://github.com/acostarz/cfsocket_first_message

Regards,
Aurélien.

0

Answer 9

AlexanderYatsenko OP

Nov ’20

I need to connect to server in local network(http without s), the permission appear, I tap allow. But when I try to send request to local server it fails with timeout. I've already added NSLocalNetworkUsageDescription in plist file. What should I do to make it work?

0

Answer 10

squarefrog OP

Dec ’20

Has there been any movement with this? I've just encountered this bug while increasing my deployment target from iOS 11 to iOS 12. I also use SSDP in order to search for UPnP devices on the network.

0