> There could easily be an additional connectivity check that is http-based (that was blocked by the captive portal) before proceeding onto a standard TLS handshake.
Yes, I mentioned that in my comment.
> As 'klodolph mentions, there's a lot of layers of verification for software updates.
I realize that, but my point is that apps that mix HTTP and HTTPS connections have a tendency to provide strange and confusing feedback to the user in situations like this. Some operations work, some don't. Apple News for example will load text but no images on unauthorized captive networks like the one I was using. An app that I worked on had the same problem (API calls went over HTTPS, but CDN-served content did not), and it was always confusing to users when secure connections went through but non-secure did not (or vice-versa). From what I've seen, it's a much better experience and much easier for the user to understand if all connections are treated the same. Having a mixture can lead to confusing situations where some things fail and some don't, and it's very hard for a non-technical person to know why. It just seems broken to them.
For example: think about the experience I had. The device appeared to be online, even downloaded the system update just fine, but then suddenly the Settings app complained that I was not online, even though many network functions (such as email) were still working just fine. A natural response might be to say that captive networks are the problem, but I promise that non-technical users will not see it that way. They will not blame the network. They will blame the app. In their minds, they are either online or not, and if only certain things fail, those things must be the problem.
Captive networks suck, but they are a reality of the world we live in and are not going away. Writing apps such that they always treat connections in the same manner will be far more understandable for users in the long run.