Post not yet marked as solved
I'm seeing the same thing for the Modular Duo face now on the Series 7.
Post not yet marked as solved
Same issue here. I did just notice that one of my alternate icons had an extra pixel in height, so I'm going to see if that fixes the warnings on next submission, but I wouldn't be surprised if that was just a coincidence.
Post not yet marked as solved
The Xcode release notes say that this issue was fixed in beta 3. It definitely was not - just tried building on the just-released beta 5 and am still seeing the same thing with 3,500 warnings in my project.
The same thing was happening to me on beta 3. The time-sensitive tag wasn't getting applied to my notifications until I restarted my phone. Spent over an hour trying different things to get it to work 🤦♂️
Post not yet marked as solved
I have a major app update scheduled to go live on January 28th, will the OTA update be pushed out before then? Or should I resubmit with the workaround to ensure there are no crashes on launch day?
Post not yet marked as solved
After removing the speech synthesizer's delegate, I haven't been able to reproduce. So that seems to be the workaround for now, if your app doesn't rely on the functionality in the delegate. (It breaks an animation for me, but I'd rather lose that than have the app crash all the time.)
I agree that it must be something with a certificate expiring (or at least something along those lines) - that would explain why it randomly cropped up out of nowhere.
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
