I'm seeing a crash on AVSpeechSynthesizer as well - it *just* started yesterday, on January 20th. I didn't put out an app update recently and there haven't been any recent iOS updates, either, so it's unclear why this class would just randomly start crashing all of a sudden. I've filed my bug report as FB8977390. I'm attaching the relevant stack trace below. OP, is this the same crash you are seeing? Exception Type: EXCBADACCESS (SIGSEGV) Exception Subtype: KERNINVALIDADDRESS at 0x0000000143794089 VM Region Info: 0x143794089 is not in any region. Bytes after previous region: 295050 Bytes before following region: 442231 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL MALLOCLARGE 143700000-14374c000 [ 304K] rw-/rwx SM=PRV --> GAP OF 0xb4000 BYTES MALLOCSMALL 143800000-144000000 [ 8192K] rw-/rwx SM=PRV Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [21347] Triggered by Thread: 13 Thread 13 name: com.apple.TextToSpeech.SpeechThread Thread 13 Crashed: 0 TextToSpeech 0x00000001a7ca6e4c TTSCreateDecryptedDataFromEncryptedData + 168 1 TextToSpeech 0x00000001a7ca6e6c TTSCreateDecryptedDataFromEncryptedData + 200 2 TextToSpeechBundleSupport 0x00000001b0b5d674 -[TTSVocalizer loadResource:mimeType:resourceURL:supportsAccurateWordCallbacks:] + 424 3 TextToSpeechBundleSupport 0x00000001b0b5aa34 -[TTSSpeechServerInstance loadVoiceResource:voiceResource:] + 484 4 TextToSpeechBundleSupport 0x00000001b0b5a510 -[TTSSpeechServerInstance initializeSpeechEngine:] + 1852 5 TextToSpeechBundleSupport 0x00000001b0b5a794 -[TTSSpeechServerInstance initializeSpeech:] + 56 6 TextToSpeechBundleSupport 0x00000001b0b57c10 -[TTSSpeechServerInstance processCurrentRequest:] + 64 7 TextToSpeechBundleSupport 0x00000001b0b58e44 -[TTSSpeechServerInstance handleSpeechThread] + 1552 8 TextToSpeechBundleSupport 0x00000001b0b57bc0 SpeechThread + 48 9 libsystempthread.dylib 0x00000001d30e5b40 pthreadstart + 320 10 libsystempthread.dylib 0x00000001d30ee768 thread_start + 8

I believe it's not budgeted when you're in the foreground, though you could always space out the updates so it's only updating the complication on every, say, 10th update in the foreground.

Apple actually recommended using earliestBeginDate to schedule URLSessions in this year's WWDC videos on complications. I had had the same issues with just immediately launching URLSessions last year, so I was trying this new method to see if it worked any better. I'll test out the old method again to see if the performance is any better - and I'll check out the blog post you recommended as well.

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?

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.

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.

@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.

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.

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.

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

Filed as FB8182192.

Same issue here with intent-based widgets.

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

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 :)