Hello, I’m encountering an issue with Universal Links in my iOS app. After some investigation, I found that the root cause seems to be that Apple’s request through there CDN server to access the .well-known/apple-app-site-association file is blocked by our firewall, which enforces geographic access restrictions as part of our security policy. Because of this restriction, Apple’s validation or link verification requests are being denied, and the Universal Links are not working as expected. I’d like to get some guidance from the community or Apple engineers on the following: 1. Does Apple provide an official list of IP ranges or domains that need to be allowed through the firewall for Universal Link validation? 2. Are there alternative methods to handle Universal Link verification in environments with geographic restrictions? 3. Would whitelisting specific Apple services or endpoints be a recommended or safe solution? Any input or recommendations would be greatly appreciated. Environment Details: • iOS app using Universal Links • Server protected by a firewall with regional restrictions • AASA file hosted correctly and accessible via browser Thanks in advance for your help and insights.

Hello, I’m building an iOS application that supports peer-to-peer file transfer. My goal is to use the WebRTC data channel only (no audio or video) to send files between users. I understand from Apple’s documentation that: • Apps are generally suspended in the background, and arbitrary sockets (like WebRTC) do not continue running. • Background file transfer is officially supported via URLSessionConfiguration.background, which the system manages reliably even if the app is suspended or terminated. • VoIP use cases require CallKit + audio/VoIP background modes, and CallKit must be used for legitimate calls (audio/video). What I want to confirm is: Is it supported for a WebRTC peer connection using only the data channel (no audio/video track, no CallKit call) to continue sending data when the app is in the background or locked? I considered using BGProcessingTask and BGAppRefreshTask, but as far as I can tell, those don’t allow maintaining long-lived sockets for active data transfer. Real-world developer discussions suggest that WebRTC connections are dropped when the app is backgrounded on iOS unless there’s at least one active audio track to keep the session alive. Can someone from Apple confirm if my understanding is correct—that data-only WebRTC connections will be killed in background unless they’re part of an active audio/video call with the appropriate entitlements? Thanks in advance!