I've created a bug FB11481970 (for some reason link does not include last zero, mb another bug :) )

I've tried both options for NEPacketTunnelProvider with the same result, but my target option is a per-app VPN.

It appears not only one that missed, but along with pci-transport: https://developer.apple.com/forums/thread/707850 What is going on? Why these two are missed from UI?

The mechanism is just a background daemon that checks if there is any update present on some server, and if it is, installs it from the .pkg in silent mode. The pkg places the new SomeOtherBundle.app in the temporary folder first, like "update" subfolder on the same level with an old SomeOtherBundle.app, then in the post-install script it calls rm on old SomeOtherBundle.app and perform a mv of a new SomeOtherBundle.app to the target location from "update" subfolder. What is the cycling of per-App VPN? If it means to turn off and on, then I would say it does not help: the update happens only while per-app vpn is in deactivated state, and after the update completed I turn it on (activate). The possibly important notice on how I turn it on and off: I'm adding the rule for ServiceApplication.app on a first start of my per-app VPN, then activating the tunnel; when it comes to turning the tunnel off, I just deactivating it, without removing the apprule for ServiceApplication.app - so when I activate it again later, the rule for ServiceApplication.app will be already there. This seems to be ok for me, because the API for Apprule uses only stable parameters: bundle id and designated requirement, however I could be wrong here. If the cycling means the removing of an Apprule for ServiceApplication.app and adding it again, or the removing and readding the whole tunnel configuration - I have not tried this yet. Generally, it will require my per-app VPN app to monitor the state of some other bundles on the filesystem, which is possible to implement, however I hoped that system will do it for me, as I have an API interface with just a bundle id and signature parameter.

Well, I do deactivate it and activate it again, however I don't get what I should reconfigure. The NEAppRule, which I indeed referenced, contains two fields: signingIdentifier (which is bundle id) and designated requirement. You are saying, I'm still have the "signature information" for the old app that was removed, but neither the bundle id nor the designated requirement has been changed, as this is the same bundle, with the same bundle id, the same certificate used to sign it, just the new version. Maybe I got something wrong about it: I'm checking the designated requirement of the bundle using the codesign -d -r- <code-path> command. The output for every single version of ServiceApplication.app is always the same, it looks like this: identifier "com.bundle.id" and anchor apple generic and certificate number[some.numbers] /* exists */ and certificate leaf[numbers.more.numbers] /* exists */ and certificate leaf[subject.OU] = teamId This stays the same for all versions, just as bundle id, and I don't see how any part of this could or should change with the update to new app version. Am I using the wrong designated requirement? Why is this even work, if it is not the correct DR to use?