Input required on choice of HTTPS server stack on Apple Platforms for programmatic integration

We have a requirement to create a production quality application that also acts as HTTPS server for certain communication.

  1. The preference is for the server to support HTTP/1.1, HTTP/2 and HTTP/3 communication asynchronously, though not mandatory to support all the HTTP versions. Wanted to get the guidance, on which stack should be used, that is most reliable and that gives the maximum long term compatibility, sustainability and reliability.
  2. What is the recommended 'in-built' or 'available by default' stack on Apple Platform ?
    • For HTTPS on HTTP/1.1 with synchronous mode operations ?
    • For HTTPS on HTTP/1.1 with asynchronous mode operations ?
    • For HTTPS on HTTP/2 with synchronous mode operations ?
    • For HTTPS on HTTP/2 with asynchronous mode operations ?
    • For HTTPS on HTTP/3 with asynchronous mode operations ?
    • For HTTPS on HTTP/1.1 + HTTP/2 with synchronous mode operations ?
    • For HTTPS on HTTP/1.1 + HTTP/2 with asynchronous mode operations ?
    • For HTTPS on HTTP/1.1 + HTTP/2 + HTTP/3 with asynchronous mode operations ?
  3. What the generally recommended server stack that a typical application uses whether 'in-built' or 'available by default on Apple ' or 'not-available by default on Apple' stack.
  4. From the available stacks , we tried to evaluate the below stacks:
    • https://opensource.apple.com/projects/swiftnio/ : We understand that while it’s not preinstalled as part of Apple's OSes, it is an official Swift package supported by Apple and can easily be added to your project. At the moment it supports HTTP/1.1 and HTTP/2. The link https://github.com/apple/swift-nio/issues/1730says that HTTP/3 will get added in the future.
    • Is there any other HTTPS stack (built-in or third-party) that is recommended to the used on Apple's platform ? Our application is expected to be working on macOS, iOS, iPadOS, tvOS and watchOS.
    • We understand that macOS also includes Apache HTTPD server. As our application is not primarily a Web Server (and also supports other protocols both in client and server mode), it looks integrating HTTPS directly into the application using a lightweight HTTP library with SSL/TLS support is a better option, in place of Apache HTTPD.
  5. From the document we know that swift-nio uses BoringSSL (swift-nio-ssl) which is prepackaged along with the swift-nio library, and it does not use the default Secure Transport. What is the reason being not using Secure Transport ? Now does it become the responsibility of the application using swift-nio to take care of updating BoringSSL with the patches.
Answered by DTS Engineer in 825441022

There’s lots of questions here. I’m gonna start out with some factoids, which should answer many of them. If I missed anything, let me know.

No Apple platform includes a public HTTP server API )-: [1] There’s a bunch of infrastructure that you can assemble into an HTTP server, but nothing that serves HTTP out of the box.

There are lots of third-party HTTP server libraries for Apple platforms. I’ve not use them myself, so I don’t have a concrete recommendation. However, if I needed one then the one I’d look at first is SwiftNIO.

SwiftNIO supports SwiftNIO Transport Services, which lets you use Network framework for the underlying transport. That is the path to choose if you’re targeting Apple platforms, because Network framework comes with a lot of ‘smarts’, including comprehensive Happy Eyeballs support and integration with the default TLS stack.

Secure Transport is not Apple’s default TLS implementation. Network framework has its own TLS implementation [2]. Secure Transport is a deprecated API that exists for compatibility purposes [3].

I have a bunch of other networking advice in TN3151 Choosing the right networking API.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Normally I’d suggest filing an enhancement request for one, but in this case it’s safe to assume that everyone involved knows that there’s demand for this, it’s just a matter of priorities.

[2] It’s also based on BoringSSL, but that’s purely an implementation detail. It’s not exposed as an API. The only way to access it is via Network framework or things layered on top of that.

Still, it’s good to know that this implementation exists because you will see BoringSSL symbols in the debugger and log entries in the system log.

Oh, and this built-in BoringSSL is related to, but not the same as, the open source BoringSSL used by SwiftNIO on non-Apple platforms (or on Apple platforms if you don’t engage SwiftNIO Transport Services).

[3] For both third-party developers and older Apple APIs. Most notably, CFSocketStream relies on it.

There’s lots of questions here. I’m gonna start out with some factoids, which should answer many of them. If I missed anything, let me know.

No Apple platform includes a public HTTP server API )-: [1] There’s a bunch of infrastructure that you can assemble into an HTTP server, but nothing that serves HTTP out of the box.

There are lots of third-party HTTP server libraries for Apple platforms. I’ve not use them myself, so I don’t have a concrete recommendation. However, if I needed one then the one I’d look at first is SwiftNIO.

SwiftNIO supports SwiftNIO Transport Services, which lets you use Network framework for the underlying transport. That is the path to choose if you’re targeting Apple platforms, because Network framework comes with a lot of ‘smarts’, including comprehensive Happy Eyeballs support and integration with the default TLS stack.

Secure Transport is not Apple’s default TLS implementation. Network framework has its own TLS implementation [2]. Secure Transport is a deprecated API that exists for compatibility purposes [3].

I have a bunch of other networking advice in TN3151 Choosing the right networking API.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Normally I’d suggest filing an enhancement request for one, but in this case it’s safe to assume that everyone involved knows that there’s demand for this, it’s just a matter of priorities.

[2] It’s also based on BoringSSL, but that’s purely an implementation detail. It’s not exposed as an API. The only way to access it is via Network framework or things layered on top of that.

Still, it’s good to know that this implementation exists because you will see BoringSSL symbols in the debugger and log entries in the system log.

Oh, and this built-in BoringSSL is related to, but not the same as, the open source BoringSSL used by SwiftNIO on non-Apple platforms (or on Apple platforms if you don’t engage SwiftNIO Transport Services).

[3] For both third-party developers and older Apple APIs. Most notably, CFSocketStream relies on it.

Input required on choice of HTTPS server stack on Apple Platforms for programmatic integration
 
 
Q