I think this discussion often gets a little bit confused.
If you need to match the bit layout of a type defined in C, using the C header that defines it is by far the best way to do it: one source of truth, one set of rules interpreting it, done. Happily this works in Swift today (at least, it does if the header supports clang. But if it doesn’t, we’re not really talking about “C,” we’re talking about some vendor-specific tool, and getting that to support Swift is a separate problem).
If you don’t need to match a bit layout defined in C, but rather some documented format, then the new binary parsing library (GitHub - apple/swift-binary-parsing) is much closer to the direction that we mostly want to take than the old-school C approach of defining a type’s layout and yolo-casting some bytes, since it gives us an opportunity to make the operation safe and ensure that parsing does not proceed with broken invariants. This _also_ works in Swift today (but please file feature requests for things that could be easier).
Vendor-specific “C” tooling is a real weak spot, but not one that Swift can do much about other than become popular enough in low-level usage that vendors start providing support.