I disagree with your assessment that this is kind of how HTTP cookies work. The RFC you link is for how a server needs to interpret a cookie sent to it not how a client should implement creation of one. I think others would likely agree that this is a wart and that setting secure to false would result in the correct behavior of not setting the secure attribute on the cookie. It also make coding something simple like .secure: environment().isSecure() into another if statement that every person coming after will question why it's done this way and then eventually figure it out. The only reason I agree that this likely needs to stay the same is it's a pretty big breaking change at this point and many apps are likely working by accident as setting .secure to anything other than true makes no sense. Anyway... wasted more hours than I would like to admit on this as I was also adding a new networking library as well as adding cookies to the app so I spent a lot of time debugging the new library when it was just this attribute messing things up.

I tried every single thing on this forum. Called apple support and even took it in to be serviced. The watch was a brick. I remembered that i had at one point enrolled in the apple beta years ago to get a new feature. after unenrolling from this and syncing the watch it worked the first time. To test if this was the issue i enabled it again and tried and i ran in the same ****** issue. Unenrolled and bam it worked. the apple beta causes this to happen for some watches it seems. no where on my phone did it show i was in the beta I had to go to https://beta.apple.com/sp/betaprogram sign in and then click the unenroll link. Amazing job apple. I had tried pairing with 5 different iphones on 3 different networks across 2 contents. Apple support was sure it was a router reboot that would do the trick lol.