As you suggested, I tested it and was able to confirm the same results. The WebSocket specification states that All control frames MUST have a payload length of 125 bytes or less and MUST NOT be fragmented. https://datatracker.ietf.org/doc/html/rfc6455#section-5.5 Given this requirement, does this mean there is indeed a bug in the current Network framework WebSocket implementation? And could you also check whether this issue occurs with other opcodes besides ping/pong?

I ran the same test in the environment below, and the ClientHello packet still does not include early_data in this case either. Xcode 26.0 Beta 7 iPhone SE (2nd generation) running iOS 26.0 (23A55336a)

I found a post stating that TLS 1.3 on iOS or macOS did not support pre_shared_key. https://developer.apple.com/forums/thread/688508 The post is from August 2021—does this still hold true today?

I conducted a few experiments. First, I started a local server with OpenSSL as follows: openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 3 -nodes -subj "/CN=localhost" openssl s_server -accept 8443 -cert cert.pem -key key.pem -tls1_3 -www -num_tickets 2 -keylogfile keylog.txt -msg -state When I opened https://localhost:8443 in Google Chrome and captured the loopback interface with Wireshark, I saw ClientHello packets containing a pre_shared_key. However, when I ran the same experiment with Safari, there was no ClientHello packet containing a pre_shared_key at all. This led me to suspect that the network stack used by Safari may have stricter requirements for enabling TLS Session Resumption compared to Chrome, and that the same conditions might also apply to URLSession.