As noted in posts such as these, the App Offload feature in iOS11 is a bit of mystery:https://forums.developer.apple.com/message/260739#260739https://forums.developer.apple.com/message/299354#299354In addition to not completely/definitely understanding what gets maintained when an App is Offloaded, I've also been unable to find any suggestion as what consistitues an "unused" App. For example, would receving (and displaying) remote notifications, or using Location Services on the device count as "usage" that would prevent an App from being offloaded? Or does the App need to enter the foreground before it's considered to have been used?We have an App which is primarily intended to notify users of significant events. These events have a location component, which may be based on current location (using Location Services on the device) or subscribed locations/topics. As a result, the expected usage pattern is tied largely to notifications and location changes, and could leave the App idle for relatively long periods. In this circumstance, should we expect a high(er) likelihood of the App being offloaded when the device is low on space?It would be ideal if there were some specifics on this behaviour, but I'd welcome any antecdotal observations as well.

We are experiencing issues with our push notification implementation. We are seeing sporadic cases where we do not receive a response for a message, but eventually encounter a "Stream forcefully closed" error. Hoping someone has run into this, and might be able to suggest how to diagnose and address. This sounds similar to the problem posted about here: https://developer.apple.com/forums/thread/103186. However, unlike in that case where it sounds like failures were consistent, in our case the application will send messages fine for hours or days before encountering the issue. We've experienced this issue 3 times in 2 different environments in the past 5 days (between Oct 1 and 5, 2020). Our application is written in Python and runs on CentOS 7. We use a library for communication with APNS (https://github.com/Pr0Ger/PyAPNs2). Here's a snippet of logs from our push notification application. 2020-10-04 05:29:50 pusher.apns2worker.emit logger:144 - APNs unkonwn error Traceback (most recent call last): File "/home/mobile-live2/alertpush-apns/env-2.6/lib/python2.7/site-packages/alertpush/apnsworker.py", line 207, in push priority=NotificationPriority.Immediate) File "/home/mobile-live2/alertpush-apns/env-2.6/lib/python2.7/site-packages/apns2/client.py", line 172, in sendnotificationbatch result = self.getnotificationresult(pendingstream.streamid) File "/home/mobile-live2/alertpush-apns/env-2.6/lib/python2.7/site-packages/apns2/client.py", line 116, in getnotificationresult with self.connection.getresponse(streamid) as response: File "/home/mobile-live2/alertpush-apns/env-2.6/lib/python2.7/site-packages/hyper/http20/connection.py", line 312, in getresponse return HTTP20Response(stream.getheaders(), stream) File "/home/mobile-live2/alertpush-apns/env-2.6/lib/python2.7/site-packages/hyper/http20/stream.py", line 230, in getheaders self.recvcb(streamid=self.streamid) File "/home/mobile-live2/alertpush-apns/env-2.6/lib/python2.7/site-packages/hyper/http20/connection.py", line 768, in recvcb self.getstream(streamid) File "/home/mobile-live2/alertpush-apns/env-2.6/lib/python2.7/site-packages/hyper/http20/connection.py", line 289, in getstream raise StreamResetError("Stream forcefully closed") StreamResetError: Stream forcefully closed  Any insights would be greatly appreciated!

Over the past few hours we've been seeing errors when attempting to connect to the APNS Sandbox push service using the HTTP/2 provider API. We've confirmed out push certificate is valid and for the correct topic/app ID. I've tried following the troubleshooting steps here: https://developer.apple.com/library/archive/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG31 When I test out the TLS/SSL handshake with OpenSSL, I get a handshake failure error: 139925350537104:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 289 bytes --- Our root certificate appears to be valid, and so far production APNS doesn't appear to be affected, as we're still seeing those push notifications sent successfully. Has anyone else encountered this? I'm wondering if this is a problem on our end or some issue with the APNS Sandbox service?

We've observed a steady decline in the number of responses to APNS requests coming back with the "Unregistered" reason. Since about the beginning of 2022, we've noticed that "Unregistered" responses have dropped off altogether for the oldest device tokens recorded in our backend. Going by the APNS response status, it would appear we're still successfully sending messages to these very old device tokens, but this seems counter intuitive. We would expect the opposite, that over time those oldest device tokens would be the ones most likely to no longer be active (i.e. app uninstalled, devices no longer in use, etc.). Many of these devices tokens were recorded years ago, so we find it hard to believe that none of them would be inactive now. Does APNS stop providing meaningful response status for device tokens at some point? For example, if the device is no longer reachable (not working, never powered on or connected, etc.), would a request to send a message to that device still have a "Success" response? And if so, is there any way to determine if those device tokens are truly inactive or not?