Thank you for your response. Here is the AASA file URL as requested: https://pre-api.tcc-ltd.sa/.well-known/apple-app-site-association To clarify, I fully understand that using Developer Mode allows us to bypass the Apple CDN and test Universal Links internally, and in that scenario everything works correctly within our target country environment. However, the issue arises when the app is distributed via the App Store. In production, Apple CDN servers located outside our target country attempt to fetch the AASA file, and since our firewall is configured to allow access only from within the target country, those external requests are blocked. This results in Universal Links not functioning for end users, even though they are located inside the allowed region. Our goal is to ensure that Universal Links work for real users in our target country without relaxing our geographic firewall policy for external IPs. Could you please advise if there are any recommended approaches or best practices for supporting Universal Links in scenarios where regional access restrictions are mandatory? Thank you for your continued guidance. Best regards, Raguraman Asokan

Hi Albert, Thank you for your quick and detailed response — I really appreciate your time and clarification. I completely understand from your explanation (and Tech Note TN3155) that Apple’s IP ranges are dynamic and that blocking traffic regionally can cause issues with Universal Links. However, our app is intentionally available only in a specific country, and we’ve already enforced this restriction through App Store country availability settings as per our business requirements. In addition, our cybersecurity team does not allow opening our domain to regions outside of the targeted country for compliance and data-protection reasons. Given these constraints, I’d like to know if there are any alternative approaches or recommendations Apple could suggest for Universal Link validation in such restricted environments. Thank you again for your support and guidance. Best regards, Raguraman Asokan

Thanks Quinn for the clarification. That helps frame the limits much more clearly. I have a related follow-up: I understand from this thread and the docs on UIApplication.beginBackgroundTask(expirationHandler:) that an app can request a short grace period (typically ~30 seconds) to finish up work before suspension. In the context of a WebRTC peer connection (data channel only), would it be technically feasible to use such a background task to allow chunk of data to finish sending during that grace period before the app is suspended? Or does the suspension model terminate low-level networking immediately regardless? Kind note:- Here only the user has started the Upload/Download when the app is in foreground state. Also, apart from URLSession background sessions (which I know are supported for uploads/downloads even while suspended), are there any other alternatives for performing reliable background networking when the app is not running in the foreground (for example, via BGProcessingTask or other higher-level APIs), or is URLSession background the only supported mechanism? Thanks again for the detailed explanation!