Thank you for the earlier clarification about Mach out-of-line data. I would like to clarify one remaining point for a macOS 13+ application. Our security contract requires rejecting a complete incoming transport message larger than 327,680 bytes, before any unbounded allocation proportional to its size. Does Apple provide a documented API or receiver pattern to enforce this limit on the entire XPC message, including multiple or nested values, before materialization or proportional allocation? I understand that xpc_data_get_length provides the length of an individual XPC_TYPE_DATA value, but that does not appear to establish a bound on the complete XPC message. If this guarantee is not available through public XPC APIs, could you confirm that and indicate what allocation and connection-termination guarantees a receiver can rely on? Thank you for your help.

Thank you, Quinn! That's very helpful. Just to clarify one security-critical point: does the out-of-line behavior and bounded receiver memory footprint apply specifically to individual XPC data values, or can it also be relied upon for an entire incoming XPC message containing multiple data values or nested containers? Our requirement is a strict 327,680-byte limit on the complete incoming transport request, with no allocation proportional to an unbounded sender-controlled payload before rejection. Would you recommend treating xpc_data_get_length as sufficient only when the protocol enforces a single data value in a fixed message structure? Thanks again!