11

Bug:

I'm consistently getting error code -1009 "The Internet connection appears to be offline." errors when making URLSession requests in an Apple Watch extension on an Apple Watch Series 3 when connected to the Internet only via LTE.

Steps to Reproduce:

  1. Install the app.
  2. Configure your device so that it's only on LTE.
  3. Verify your connection to LTE using iMessages, e.g.
  4. Launch the app.
  5. Initialize a URLSession using the .default or .ephemeral session configuration.
  6. Make a data task request for any known-good https URL.

Expected Behavior:

The request manages to reach the destination.

Observed Behavior:

The request fails immediately with error code -1009 "The Internet connection appears to be offline."

Code Sample:

let config = URLSessionConfiguration.ephemeral
let sesh = URLSession(configuration: config)
let url = URL(string: "https://google.com")!
sesh.dataTask(with: request) { (_, _, error) in
    print(error)
}.resume()
jaredsinclair
  • 12,687
  • 5
  • 35
  • 56
  • I am currently facing the same issue with our app. It happens to some users for a certain carrier. Seems requests fails immediately if trying to establish an LTE connection or when switching network type LTE to WIFI or WIFI to LTE. The worst thing is I cannot reproduce on my devices no matter how I try. – SleepNot Feb 09 '19 at 10:32

3 Answers3

9

NOPE: SEE UPDATE #3 BELOW: The crucial missing element: you must set the waitsForConnectivity flag on your session configuration to true.

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.

Bill Tür stands with Ukraine
  • 3,425
  • 30
  • 38
  • 48
jaredsinclair
  • 12,687
  • 5
  • 35
  • 56
  • I have a very similar problem to this. I assumed that *my app* wasn't working over cell, but it turns out no 3rd party apps are working over cell. I thought there was something funky with my carrier setup (as you mentioned) but I checked and they assure me it is fine. Then I asked Apple. They want me to unpair and repair so I'm trying that... – lewis Apr 20 '19 at 14:15
3

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.

Stephen Rauch
  • 47,830
  • 31
  • 106
  • 135
Andrew
  • 174
  • 1
  • 6
  • I experienced the same problem but it was found that I remembered that I turned off my developing app in the mobile cellular setting... So It had to be switched back to turn-on mode. So I never needed any code to implement, but only just app setting from the setting app. I wanted to share my experience as a reference. Thanks – Ryohei Jan 21 '19 at 08:29
0

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.

Jason G
  • 2,395
  • 2
  • 24
  • 34