My understanding is that session resumption doesn’t get you any performance benefit when you’re using TLS 1.3 In the case of TLS 1.3, it is true that—except for early data—the number of RTTs does not decrease compared to a full handshake. However, when session resumption is used, the client does not need to receive the server certificate, which allows application data to be sent much more quickly. This becomes especially valuable in environments with unstable or low-bandwidth networks, where certificate size can have a significant impact on performance. By completely avoiding the transmission of the certificate through session resumption, these performance benefits are further amplified. By contrast, in the case of TLS 1.2 session resumption, as noted in this thread, Apple’s current implementation appears to allow a session ticket to be reused only once—even if the lifetime hint remains valid. In principle, TLS 1.2 itself permits multiple reuses of a session ticket, but under this limitation, the intended benefit of consistently avoiding certificate transmission cannot be fully realized. One point I would like clarification on is why sec_protocol_metadata_get_early_data_accepted exists. From my observations, when using TLS 1.3, session resumption appears not to work at all, which raises the question of why there is a need to confirm whether early data—which is inherently dependent on session resumption—was accepted. Additionally, I would greatly appreciate your guidance on how to either: Reuse a session ticket issued under TLS 1.2 multiple times, or Enable TLS 1.3 session resumption (where a NewSessionTicket is delivered each time).