I see thanks. The word 'active' was confusing. I thought it meant just staying on the screen. So 'active' in this context means 'able to receive updates'. Right?

That's expected. The os is getting launched only for the notification that was tapped on. Beyond that you can use this API: https://developer.apple.com/documentation/usernotifications/unusernotificationcenter/getdeliverednotifications(completionhandler:) to query all delivered notifications and then process those. That said I recommend against processing delivered notifications. It's not the users's intent to interact with the rest. At best you should just log them. Like imagine if each notification caused a navigation to a certain part of your app. Do you want to process and navigate 5 notifications at once?!

A widget is a type of app extension. A widget can then be of a variation of types Since a widget is an app extension, then: No it can't have the same bundle id of the main app's. Meaning: if your app's bundle id is app.foo.bar, then your app extension's bundle id should be app.foo.bar.baz As mentioned above, you can't use identical bundle ids. Each target (app, app extension) requires their own bundle.

Once you get the special entitlement for hotspot helper and add that to your provisioning profile, do you still have to manually go in and change the entitlements of your app and set com.apple.developer.networking.HotspotHelper to true? I'm asking because if I don't do that then hotspot helper doesn't successfully register and the SPN feature won’t work. When I look into the macOS console I get: missing com.apple.developer.networking.HotspotHelper Basically are special entitlements different, so you have to go in and manually add the key into your entitlement?

I was having similar issues. The root cause of it was due to Apple's 'data protection class'. It's defaulted to NSFileProtectionCompleteUntilFirstUserAuthentication I was seeing this error for the longest time until I accidentally reproduced it. I only ran into this issue: after a reboot did NOT unlock device. app made some network call that needed to write into some directory Failed and got a 513 error. The fix is simple if you like the tradeoff: try data.write(to: tmpFileURL, options: [.noFileProtection]) Though that would allow the file to be accessed while locked and during boot time. I suppose if you've set the data protection class to NSFileProtectionCompleteUnlessOpen and the user locks their device after an action and that action of yours takes too much time then you'll get this error again.