Hi Andy, Regarding using SwiftUI for your app and the complications, maybe you missed something? In the WWDC'20 as you know there are videos demoing how to create complications using SwiftUI. Maybe that's only for >= WatchOS 7.. If your WatchOS app creates and writes to any files, the default is to have complete file protection, meaning those files will NOT be accessible for reading to your app if the screen is locked (regardless of whether it is on the charger or not). So if your app is eventually started by WatchOS in the background, accessing any of those files will fail and throw an exception. The only files you can access when the screen is locked and your app is running in the background are either files you explicitly created with no file protection or the file(s) which WatchOS downloaded for you in the temp area via the background refresh download task. When using background refresh either on WatchOS or iOS there's a tradeoff between usability and security. You most likely don't have to worry about that if the nature of your data doesn't require strong security, and from what you've shared, it looks like your app is fine. My issues seem to stem from wanting to make a highly secure WatchOS app, but complications require security to be more lax than the default. I may have to change my app architecture and utilize complication push notifications instead of background refresh. We'll see.

Hi Andy, Very happy for you! So your first issue was because you were using SwiftUI, instead of a Storyboard? I'm glad you got it working. If you reboot your watch, does your app get started in the background and allowed to finish processing in the background? Mine updates my complications well but only if I started the app, still has issues when launched by WatchOS. If the watch was on the charger and locked when my app was woken up, I'd get a bunch of permission denied errors. This was due to various configuration files which I used that had the default complete file protection on, so my app couldn't access them if launched while the watch was locked. It still doesn't work in the most extreme case when on the charger, as I now get "Operation not permitted" in the  urlSession(_ session: , task: , didCompleteWithError error: ) method when trying to initiate the download. Finally I noticed a lot of issues because of various data I had stored in the keychain accessible only if the user set a passcode and the device had to be unlocked when the app was launched. If you use the keychain you may want to review your code. I test the app on 2 watches simultaneously, one running WatchOS 7 and the other running WatchOS 6.2.8. I don't know if it's because of WatchOS 7 or because that watch is my regular Apple Watch, as opposed to the other one which is just for testing, but my WatchOS 7 watch schedules tasks in a much more timely fashion.

I believe that BAR stands for Background Application Refresh. Therefore the snippet you posted from WWDC is for scheduling one. I'm also pretty certain that you need to at least add background session type set to "None" to your app's signing and capabilities and that is what the error in the console is complaining about. I have mine set to process remote notifications but it doesn't have to be set to anything, especially if you don't need to use an extended runtime session. Also the session type has a choice for "None" which represents a generic background refresh session that you want to create. Your app doesn't have to have an extended background runtime session, it just needs to declare that it uses a background refresh of a generic type ("None") Why not give it a try? The worst that will happen is nothing

Hi Andy, In your WatchOS app extension's Signing and Capabilities section do you have a "Background Modes" section? I do. Additionally I have session type set to "None" and for Modes I have "Remote Notification" checked. I believe that is all you need. What on earth is "BAR"? The issue is that for me, background processing occurs only if the user has started my app and it now is in the application dock. If the app is dead, although it gets started by WatchOS at the desired time, it cannot process the data file until the user brings it to the foreground. I just want to know if that is the intended functionality or if I'm missing something.