I've finally gotten around to submitting the bug report (FB16748087). Best regards, Emīls

This is still iOS, and this has been the case since, I believe, iOS 15. It is certainly the case on iOS 16, 17 and 18, as those are the devices we have tested this behavior recently.

Thank you for the timely response! I added an extra log call early in the constructor of our packet tunnel provider class, and saw no logs. We also tried a dummy implementation of a packet tunnel and also saw the same symptoms. We pontificated that it could be due to on-demand rules - if we disable those and try and update the app whilst our tunnel is connected we get the same results. That is not to say that we'd be happy to use a workaround that relies on not using on-demand rules. The issue number is FB16482585 and I've updated it with a sysdiagnosed that was collected with the appropriate VPN logging profile now. Not that we could do anything about the system not finding any route to the internet with includeAllNetworks set and the packet tunnel being shut down, but should a packet tunnel provider ever anticipate stopTunnel to be called with the appUpdate stop reason? Whilst on the topic of calls we've never seen in the wild, are there any circumstances we should be seeing a call to sleep? If the latter deserves a seperate thread, I'll make one :)

The legacy in-provider networking APIs did not work either, with the same symptoms.

This is happening on iOS. Further, it is not just that the app update fails to download, there is no network connectivity on the phone again. Cancelling the update, deleting the app or the VPN profile does not bring back connectivity.