Happening for me as well when I use the date or reload at end policies. The only one that doesn't refresh constantly multiple times per second is the never policy.

You need to add the NSWidgetWantsLocation entry to your plist. This is mentioned in one of the talks about location this year.

Seems to be a bug, I'm see it and others have been reporting the same issue as well on here.

How do you add the intent to the bridging header? "ConfigurationIntent.h" can't be found and "ConfigurationIntent.intentdefinition" throws a bunch of errors. Hopefully @iceleaf or @zhangkk are still around to answer :)

I was able to get it working by switching Intent generation to Objective-C in my WidgetKit target. Hopefully this will get fixed shortly.

Same issue here with intent-based widgets.

Filed as FB8182192.

Is widgetURL working for anyone on beta 3? Widgets refuse to load on both simulator and device when I add widgetURL to a view.

Ah ha! I was having the same issue. My intent file's target membership was set to only the WidgetKit extension. When I added the parent app to the target memberships, it started working.

How often are the background URL session download tasks actually happening for you? I'm only getting one download every 1.5 hours, despite the docs and session videos saying we should expect up to 4 per hour.

@AndyJJ would you mind posting your networking code as well as your background refresh code? Just trying to see if there's something I'm missing here. It's working fine on one of my test watches, but taking up to an hour on my personal watch.

I thought I had finally gotten this working because my development watch was regularly updating every 20 minutes. But now that I've updated my personal watch to watchOS 7, I'm seeing the exact same behavior of it sometimes taking over an hour for a background URL session to return. And at least as of a beta or two ago, the simulator wasn't giving me background URL refreshes at all. I'll have to give that a try again. Would you be able to post your networking code as well as your background refresh code, by any chance? I'd like to compare against my own to see if there's something I'm missing here.

Specifically, when do you schedule the next URLSession task after the previous one is completed? Apple has previously posted guidance saying that URLSession penalizes apps for repeated launching and requires at least 10 minutes between tasks. Does that mean you have to wait 10+ minutes before you can even *schedule* the next URLSession? I started waiting until the next background app refresh to schedule the next URLSession task and saw some improvement, but that also introduces a big delay since sometimes the next background app refresh doesn't trigger for 15+ minutes. The sample code shown in one of this year's WWDC videos had the next URLSession getting scheduled right when the previous one completed, but other Apple docs and my testing seems to indicate that's not correct.

Specifically, when do you schedule the next URLSession task after the previous one is completed? Apple has previously posted guidance saying that URLSession penalizes apps for repeated launching and requires at least 10 minutes between tasks. Does that mean you have to wait 10+ minutes before you can even *schedule* the next URLSession? I started waiting until the next background app refresh to schedule the next URLSession task and saw some improvement, but that also introduces a big delay since sometimes the next background app refresh doesn't trigger for 15+ minutes. The sample code shown in one of this year's WWDC videos had the next URLSession getting scheduled right when the previous one completed, but other Apple docs and my testing seems to indicate that's not correct.

Do you use earliestBeginDate on the NSURLSession download task to schedule it for a future date? And if you end up scheduling multiple download tasks because one of the previous ones didn't complete, do you ever see multiple tasks completing at the same time at some point in the future? How do you handle those?