I got a notice that the com.apple.developer.networking.multicast entitlement was granted for my app id, however, there doesn't appear to be a way to add it. Normally with an entitlement I would start by adding the Capability, but there doesn't appear to be one for multicast, either when setting up the identifier in 'Certificates, Identifiers & Profiles', or attempting to add the Capability in Xcode (12 beta 4). I tried just adding the key to my entitlements file: <key>com.apple.developer.networking.multicast</key> <true/> After adding this, automatic signing failed with an error: Provisioning profile "<name>" doesn't include the com.apple.developer.networking.multicast entitlement. I then tried to create a profile manually, but the "Additional Entitlements" here only showed the Network Extension entitlement that I also have for this app id. I created it anyway, and got the same error. Are there additional steps other than adding the key to the entitlements file to use this entitlement?

I have a VPN app that uses a tunnel to route traffic, and I'm finding that port 80 traffic cannot be routed when Private Relay is enabled. Oddly, it's just port 80 traffic. HTTP traffic over 8080 or other ports still work fine. Specifically, connecting the socket using the connect() function for a port 80 address always returns the same error "No route to host". According to the Packet Tunnel Provider documentation (https://developer.apple.com/documentation/networkextension/packet_tunnel_provider?language=objc): When a VPN configuration is active, connections use the VPN instead of iCloud Private Relay. Network Extension providers also don’t use iCloud Private Relay. This is not the behavior that we are seeing. As soon as I disable Private Relay on the device, the port 80 traffic flows correctly and there's no more errors. We already tried excluding the Private Relay servers from the tunnel, but that didn't have any impact on this issue. Is there anything else we could try to work around this? So far we've tested with iOS 15 beta versions through beta 4. Also tested on developer versions as well as public beta.

I have a VPN app that is very sensitive to networking changes and so I have to refresh things every time the interface changes (like WiFi to LTE, LTE to WiFi, WiFi to wired, etc). So I rely on NWPathMonitor to tell me about interface changes. Problem is, it's not so accurate all the time. When I test it on my devices, everything works perfectly. For example, I turn off WiFi on my device, it runs pathUpdateHandler block and I can read the new preferred interface (availableInterfaces.first on the NWPath object). The name of the interface changes from en0 to pdp_ip0. Or maybe there's no available interfaces now cause it doesn't have a data plan on the device. That's all good. I can have my VPN respond appropriately. But I have one end user (likely more out there) where the NWPath interfaces aren't changing in the pathUpdateHandler block. This user gave me their sysdiagnose logs where I had the VPN printing out the availableInterfaces so I could see for myself. Sure enough, as they join a WiFi network, the preferred interface is still pdp_ip0. isExpensive is still true, even though they are using WiFi now. Then, when they leave the range of the WiFi, the preferred interface stays pdp_ip0 and that's when the VPN breaks for this because it's not being treated like a network change. In the case of this user, they are joining a school wifi where they use their school login credentials to use the network. They are logging in each time successfully and using the WiFi. Also, the end user's device is on AT&T. These are two conditions I can't test myself. I can't have it respond to every pathUpdateHandler block run, because it runs quite a lot even when there's no network changes. When I tried this, it destabilized the VPN. So that's out. I just need a way to know when the network is changing and only have the VPN respond to the change at that time. So, my question-- is there a reliable way to know this?

I created my Device Activity Monitor extension, and then attempted to start monitoring using the code example from the video: let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 0, minute: 0), intervalEnd: DateComponents(hour: 23, minute: 59), repeats: true ) let center = DeviceActivityCenter() do { try center.startMonitoring(.daily, during: schedule) } catch { print(error) } The startMonitoring call always fails for me with the same error: [monitor] Failed to create UsageTrackingAgent proxy: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service on pid 0 named com.apple.UsageTrackingAgent was invalidated." UserInfo={NSDebugDescription=The connection to service on pid 0 named com.apple.UsageTrackingAgent was invalidated.} Setting up the extension is a very manual process, so I likely missed a step somewhere, but any ideas on what this error might be indicating?