libquic crashes

App & System Services Networking
blaketucker_ OP
Created 8h
Replies 2
Boosts 0
Views 89
Participants 3
This post is from the WWDC26 Networking Q&A.

Hello,

I filed feedback 22592307 around crashes my team and I are seeing in libquic now that we have adopted HTTP/3 for a large portion of our network usage. During the state of the union it was stated that libquic has been fully re-written in Swift by the WebKit team. Is that swift version the new implementation of libquic in iOS 27? If not, what will be the best way to adopt it without leaving the URLSession ecosystem?

Answered by Engineer in 891716022

Thanks for the question!

Regarding your feedback 22592307, that's a crash that we are actively tracking in libquic. We appreciate your highlighting that.

For the QUIC implementation in Swift, as you heard announced in the State of the Union, this is part of an effort around Network.framework to move more of its implementation into Swift and make it available as part of the Swift ecosystem. You can check that out and get involved on GitHub here.

However, this Swift-based implementation of the QUIC protocol is not yet available to use as part of URLSession or Network.framework directly. The Swift QUIC version is something that's being shared with the community as it is being developed for use on both clients and servers.

For now:

  • If and when you see crashes, please file feedback reports with details (sysdiagnoses where possible are appreciated)
  • For people enthusiastic about Swift QUIC, please engage with us on GitHub and in the new Swift Networking Workgroup!
Replies  2
Boosts  0
Views  89
Participants  3
divyaravi11992 OP
8h

This is a great catch — worth clarifying the distinction.

The Swift rewrite mentioned in the State of the Union refers to the QUIC transport layer used internally by the system networking stack, not necessarily a drop-in replacement for the existing libquic that's been crash-prone for HTTP/3 adopters. These can be the same underlying implementation or a parallel new stack depending on how the migration is staged — worth confirming explicitly with the Networking team here since the messaging wasn't fully clear.

For your immediate crash issue: if you've already filed feedback with a reproducible case, the most actionable workaround while this gets sorted is to scope HTTP/3 usage via URLSessionConfiguration — you can disable HTTP/3 negotiation per-session with assumesHTTP3Capable = false on specific session configs while keeping it enabled elsewhere, which lets you isolate the crashing code paths without abandoning HTTP/3 entirely.

If the new Swift QUIC implementation is opt-in via a new URLSession flag in iOS 27, that would be the cleanest migration path — but I haven't seen that documented yet either. Following this thread for the answer.

— Divya Ravi, Senior iOS Engineer

Engineer OP
Apple
8h
Accepted Answer

Thanks for the question!

Regarding your feedback 22592307, that's a crash that we are actively tracking in libquic. We appreciate your highlighting that.

For the QUIC implementation in Swift, as you heard announced in the State of the Union, this is part of an effort around Network.framework to move more of its implementation into Swift and make it available as part of the Swift ecosystem. You can check that out and get involved on GitHub here.

However, this Swift-based implementation of the QUIC protocol is not yet available to use as part of URLSession or Network.framework directly. The Swift QUIC version is something that's being shared with the community as it is being developed for use on both clients and servers.

For now:

  • If and when you see crashes, please file feedback reports with details (sysdiagnoses where possible are appreciated)
  • For people enthusiastic about Swift QUIC, please engage with us on GitHub and in the new Swift Networking Workgroup!
libquic crashes
First post date Last post date
 
 
Q