The certificate management is the problem here. Let's say the server is running on 192.168.1.73, how do I get a certificate for that? On the next start of the app, the server might be running on 192.168.1.76, so I need another certificate for that. You see the problem? Also take into account that the entire infrastructure for solving that problem needs to run inside the iPad App, which needs to be accepted to the Apple store ...

It's still a much bigger hassle to implement HTTPS than just HTTP.

The biggest hassle would be that the embedded HTTPS server needs a trusted certificate, but certificates are only issued for hostnames, not IP addresses. So the embedded HTTPS server's certificate and LAN clients would need to know the hostname of the device running the app.

> https://1.1.1.1

That's correct, some CAs issue certificates for public IPs. You're never ever going to get a cert for a private IP, since these are not globally unique.

This isn't saying anything not already covered in the material I referenced in my comment—although it does say it less precisely, so I'd argue on those grounds that all things considered this comment need not have been posted...

(In any case, I'm totally mystified about why my own comment that includes that link and corrects the untrue statement about it not being possible possible to get certificates for IPs was deemed to offend someone's sensibilities. Surely the offense, if there is one, is in the comment that makes an outright, verifiably untrue claim?)

That’s interesting about the 1.1.1.1 certificate.

I wasn’t refuting jackewiehose‘s comment about HTTPS hassles. I was just sharing a specific example of a hassle.

Don't your libraries implement it?

Open doesn't imply it's easy.