Hello Apple Developer Community,
I’m developing an iOS application and investigating an unusual, persistent HTTPS connectivity issue. I would appreciate guidance from developers experienced with URLSession, CFNetwork, and iOS networking.
Environment
- Main app: React Native / Expo SDK 57.
- Independent diagnostic app: native Swift using URLSession with a long-lived ephemeral session.
- Backend: Node.js/Fastify behind Nginx on a Linux VPS.
- Affected device: physical iPhone 15 Pro running iOS 27.0.1.
- Comparison device: physical iPhone 11 running iOS 18.7.8.
- HTTPS API using a publicly trusted TLS certificate.
Observed behavior
The iPhone 11 generally communicates reliably with the API when its VPN is disabled. The iPhone 15 Pro experiences intermittent connectivity failures over both Wi-Fi and cellular LTE.
Successful requests often complete within 100–300 ms. Failed requests receive no HTTP response and terminate with a timeout after approximately 15 seconds.
The issue affects authentication, conversation retrieval, and message sending. It is not limited to chat functionality.
What we have tested
- Replaced Expo Fetch with React Native Fetch. The issue persisted.
- Built a completely independent native Swift diagnostic app using URLSession. The same issue reproduced.
- Added X-Request-ID tracing to both Nginx and Fastify.
- During one native diagnostic run of 20 sequential GET requests, the first seven returned HTTP 401 in approximately 149–200 ms (likely due to an expired access token). The following 13 ended with URLSession error -1001, without any HTTP response.
- The request IDs for these 13 timed-out requests were absent from the checked Nginx and Fastify logs.
- A separate manual POST /auth/login also timed out with URLSession error -1001 after 15.6 seconds.
- NWPathMonitor continued to report satisfied over the cellular interface. URLSessionTaskMetrics for failed requests showed a transaction but lacked DNS, TCP, TLS, and response timing data.
- The server remained running and successfully handled other requests.
We have not yet captured TCP packets during an actual failed request. Therefore, we cannot determine whether the failure occurs during DNS resolution, TCP connection establishment, TLS negotiation, or another stage.
Questions
- What could cause URLSession to intermittently time out on one physical iPhone while another device can reach the same HTTPS endpoint?
- How should we interpret URLSessionTaskMetrics containing a transaction but no DNS/TCP/TLS timing information?
- Which additional iOS diagnostics would best identify the stage where the request stalls?
- Are there known differences in CFNetwork connection handling, DNS resolution, IPv6, or network configuration that would be worth investigating?
I’m specifically looking for a systematic way to isolate the root cause rather than rewriting the application.
Thank you for your help.
- Affected device: physical iPhone 15 Pro running iOS 27.0.1.
- Comparison device: physical iPhone 11 running iOS 18.7.8.
Your post’s title suggested an iPhone 11 versus iPhone 15 difference, but this could just as easily be an iOS 18 versus iOS 27 difference. Indeed, the latter is more likely IMO.
I recommend that you tease these apart, ideally by running your tests on a range of phones with iOS 27. If they all fail then you know that iOS 27 is the key factor.
As to what’s causing this, it’s hard to say. For problems like this I generally recommend that you install the CFNetwork debug profile and then look through the system log for telltale signs of the failure. However, I wouldn’t go too far down that path until you’ve established the scope of the issue. If this is hardware specific, then the path forward is very different from the one you’d follow if it’s tied to the OS.
I have lot of info about how to use the system log in Your Friend the System Log.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
