let config = URLSessionConfiguration.ephemeral
config.waitsForConnectivity = true
let sesh = URLSession(configuration: config)
let url = URL(string: "https://google.com")!
sesh.dataTask(with: request) { (_, _, error) in
print(error)
}.resume()
If you do not set that flag, the requests fail immediately because LTE access isn't available instantly but only after the briefest of delays. Setting this flag to true makes the requests work. In my testing there even seems to be no appreciable difference in timing between enabling the waitsForConnectivity over LTE and making the same request without enabling waitsForConnectivity but conducted over WiFi, almost like the waiting period enabled by waitsForConnectivity in some scenarios is a next-turn-of-the-runloop kind of situation.
Update #1
I am unable to make any requests over LTE. When waitsForConnectivity is set to true, the requests just timeout according to the timeout properties of the session config. When waitsForConnectivity is false, the requests fail immediately. I'll update my question and answer when I have more information. I'm waiting on a response from an Apple TSI request which usually takes several days.
Update #2
Adding to the mystery, the same sample code runs fine over cellular on two other developers' hardware. I know that my hardware is good because Apple's apps fun fine over LTE on it (phone calls rolling down the highway with nothing but my watch in the car). So there's something really fishy going on. I've asked Apple DTS to look into this, and they can't reproduce the issue either. I'll be following up with them as soon as I can.
Update #3
Sometime in the intervening weeks after I last updated this post, cellular requests started working in my apps. I didn't change anything about my watch, no software updates, no resets, nothing. I didn't even recompile the code; the same build is still on my watch as previously. It just started working as expected, same as it did on other developers' devices.
The only thing strange I noticed is that I got three, back-to-back, identical SMS messages from AT&T notifying me that my Apple Watch is now linked to my iPhone number. Which is strange, because that linkage supposedly occurred the night I unboxed my phone, not two months later. I have no idea if this is related to my issue. All I know is that cellular requests are now working.
–
I had the same problem but was developing an App for the iPhone. This is what finally solved the problem. I set the configuration objects property:
config.allowsCellularAccess = true
This is very confusing, because the Apple documentation states that this property is set to true by default... but in my case it was not. Also, even though I am using "background tasks," and they are always meant to wait for connectivity, I also set waitsForConnectivity = true, too, just in case.
–
Just in case someone runs into this error but has everything set up correctly. I was running my project from xCode onto a real device but couldn't get past the internet connectivity issue.
In the code there was a check for __DEV__ to determine what API url to use.
I was building this for running not testing so i assumed it would make __DEV__ false. but it did not, so I had to change the code for that check and set it to a non-localized api url.
even if you are injecting your url, it might not grab the correct one based on if it thinks it is a DEV build or not.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
