Two of these you will only ever see when something is wrong — which is
exactly when the app used to say the least.
WHY THE VPN WILL NOT START. If you sideload a build signed with a free
Apple ID — what 3uTools, AltStore and Sideloadly produce by default — iOS
refuses to let it create a VPN configuration at all. No permission prompt
ever appears, and every attempt ended in the two words "permission
denied", which name neither a cause nor anything you can do. The app now
reads its own signature and says plainly that the build was signed
without the VPN entitlement, with the full explanation in Logs, ready to
paste into an issue. Only a paid Apple developer account can grant that
entitlement; TestFlight is the way around it.
⚠️ And when the entitlement IS present, the app deliberately does not
blame your signature. It points instead at the things that actually cause
this on a correctly signed build: a leftover "VK Turn Proxy" entry under
Settings › General › VPN & Device Management from an earlier install, a
device managed by an MDM profile, or a permission prompt answered with
"Don't Allow".
A TUNNEL THAT DIES NOW SAYS WHY. Until now, if the tunnel dropped after
it had started, the status simply changed to Disconnected and you were
told nothing — the reason is only ever available by asking iOS for it,
and the app never did. It does now, including when you open the app after
the tunnel had already died while it was closed.
A STALE CONFIGURATION IS RETRIED. If iOS reports that the VPN profile
changed underneath us, the app reloads it and tries once more instead of
handing you an error you could only answer by tapping Connect again.
Under the hood: the upload path stops allocating a fresh buffer for every
packet. Measured on device, that is about a third fewer garbage-collection
cycles per megabyte sent. You will not see it directly; it buys headroom
in an extension that iOS keeps on a tight memory budget.
Client only — the server side is unchanged, so srtp-build306 remains
current.