Increased Wi-Fi login/reconnection timeouts after iOS 27 upgrade; partial improvement on 27.2

App & System Services Networking
MartianSu OP
Created
Replies 1
Boosts 0
Views 32
Participants 2

Hello Apple networking team and fellow developers,

Summary

We are investigating increased Wi-Fi login and reconnection timeouts after users upgrade to iOS 27. Some players report repeated reconnection failures during battles, preventing completion and potentially losing Star Hunt points. The root cause is not confirmed.

1. Wi-Fi timeout rates by OS version
+------------+------------------------+--------------+
| OS version | Timeouts / online hour | Dates (2026) |
+------------+------------------------+--------------+
| iOS 26.x   | 0.086                  | Oct 8-21     |
| iOS 27.0   | 1.779                  | Oct 8-21     |
| iOS 27.0.1 | 1.737                  | Oct 8-21     |
| iOS 27.2   | 1.437                  | Oct 26-28    |
+------------+------------------------+--------------+

The 27.2 observation cutoff is October 28, 14:15 UTC+8.

The earlier iPhone comparison showed approximately 20 times as many Wi-Fi login/reconnection timeout records per online hour on 27.0/27.0.1 as on 26.x.

Comparison limit: The 27.2 row uses a different population and observation window. It is not a direct before/after upgrade comparison.

2. Paired comparison: 27.0.1 → 27.2

We separately compared 51 paired iPhone account/device samples: the same account and device, game package version 1.9.1, and 24 hours before and after the first observed 27.2 event. Each side required at least 30 minutes of Wi-Fi online time. These samples first reported 27.2 on or after October 26.

+------------------------+----------------+-------------+
| Metric                 | Before: 27.0.1 | After: 27.2 |
+------------------------+----------------+-------------+
| Wi-Fi online hours     | 96.69          | 91.05       |
| Timeout records        | 142            | 45          |
| Timeouts / online hour | 1.47           | 0.49        |
| Samples with timeouts  | 17 / 51        | 6 / 51      |
+------------------------+----------------+-------------+

This small paired sample suggests an initial improvement of approximately 66%, but failures remain.

Measurement limits: Both tables count application-level timeout records, including repeated retries, rather than independent disconnections. The 27.2 sample and observation period are limited. Our OS-version telemetry does not distinguish beta/RC builds from final builds sharing the same version string.

3. Other observations
  • Earlier cohort comparisons did not show a comparable increase over 4G/5G.
  • Wi-Fi-only iPad models are also affected, so switching to the device's own cellular connection cannot explain all cases.
  • Ordinary request errors did not increase to the same extent as login/reconnection timeouts. Connection recovery is an investigation lead, not a confirmed cause.
  • Our iOS HTTP requests use NSURLSession. Current application telemetry does not retain enough native NSError details to identify whether DNS, TCP, TLS, or another stage is responsible.
4. Questions for Apple
  1. Are there known iOS/iPadOS 27 changes or regressions involving Wi-Fi connection recovery or NSURLSession that could fit this pattern?
  2. Are there relevant fixes in 27.2, or specific OS builds we should compare?
  3. Which diagnostics should we collect from affected physical devices (for example, a CFNetwork diagnostic profile, sysdiagnose, or URLSessionTaskMetrics), and how should we submit them privately?

We are looking for a systematic way to isolate the cause rather than assuming all cases share one OS bug. Any guidance would be appreciated.

Replies  1
Boosts 0
Views  32
Participants  2
DTS Engineer OP
Apple

Here on the forums I often see folks reporting Wi-Fi problems, to the point where I have a standard answer for them: Filing a Wi-Fi Bug Report. However, your situation is different, in that you’re investigating this from the top down (network requests are failing) rather than the bottom up (Wi-Fi is failing). So while the contents of that post might be interesting to you, it’s not the full answer.

Which brings me to this:

Written by MartianSu in 853795021

Which diagnostics should we collect from affected physical devices (for example, a CFNetwork diagnostic profile, sysdiagnose, or URLSessionTaskMetrics), and how should we submit them privately?

That last part is easy: If you’d like Apple to look at this officially, you should file a bug in Feedback Assistant. It will let you attach diagnostics. And if you file a bug, please post your bug number, just for the record.

In terms of the diagnostics to collect, what I generally recommend is:

  1. Install the CFNetwork, Network Diagnostics, and Wi-Fi debug profiles
  2. Reproduce the problem, noting down the time you saw it.
  3. Immediately after that, trigger a sysdiagnose log.

However, that assumes that you can reproduce the problem, which is the tricky part. You’re dealing with a statistical issue, where you’re seeing more failures and it’s not necessarily obvious whether a specific failure is part of the wider issue or just the sort of random failure that made up your iOS 26 baseline.

Are you seeing these sorts of problems in your own internal testing. My experience when dealing with reports like this is that folks who are able to collect telemetry like this usually have their own internal test setup, with an array of iOS devices running tests regularly. Is that the case here? And do these show the issue?

Finally, I want to speak to this:

Written by MartianSu in 853795021

Current application telemetry does not retain enough native NSError details to identify whether DNS, TCP, TLS, or another stage is responsible.

OK. It would make sense for you to fix that. I also recommend that you retain more of the URLSessionTaskMetrics. That can give you good insight into where things are going wrong.

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