When using HockeyApp or other custom over-the-air app distribution methods, we are experiencing that the download and installation does not finish when running an active packet tunnel. Only after disabling the VPN and pausing/resuming the download on the home screen, the upgrade succeeds.Could a similar scenario also happen when upgrading live apps from the app store, given that they are running a packet tunnel? Or are these fundamentally different processes?

I've been wondering what is the memory limit for network extensions. Specifically, I'm using the NEPacketTunnelProvider extension point.The various posts on this forum mention 5 MB and 6 MB for 32-bit and 64-bit respectively. However I find that (at least on iOS 10) the upper limit seems to be 15 MB. Is this the new memory limit for extensions?

Hi,Since the release of the 10.3.2 beta, our packet tunnel provider extension fails to connect.The behavior observed is that in the VPN settings in the Settings app, the VPN status will switch to "Connecting...", during which all connectivity is lost. The status does not change and the corresponding packet tunnel provider is never started. I can confirm that on iOS 10.3 this is working as promised, both with a configuration profile and using the classic NETunnelProviderManager. On 10.3.2, this behavior is consistently shown for my own app, but also for a handful of packet tunnel provider-based apps I've seen in the wild.The console logs at this time do not give any useful debugging information other than the following:Mar 31 15:22:29 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Received a start command from Preferences[992] Mar 31 15:22:29 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: status changed to connecting Mar 31 15:23:30 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Skip a start command from apsd[83]: session in state connecting Mar 31 15:23:33 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Skip a start command from routined[28]: session in state connecting Mar 31 15:23:34 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Skip a start command from geod[99]: session in state connecting Mar 31 15:24:20 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Skip a start command from timed[56]: session in state connecting Mar 31 15:24:34 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Skip a start command from routined[28]: session in state connecting Mar 31 15:25:13 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Skip a start command from apsd[83]: session in state connecting Mar 31 15:25:33 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Skip a start command from apsd[83]: session in state connecting Mar 31 15:25:34 iPhone nesessionmanager(NetworkExtension)[198] <Notice>: NESMVPNSession[MyApp]: Skip a start command from apsd[83]: session in state connecting Could this be related to the IKEv2 troubles observed on 10.3.2?

I cannot get Instruments to work. I'm trying to inspect allocations in my packet tunnel provider (NEPacketTunnelProvider). I've tried several methods: Attaching the debugger to the tunnel provider process and transferring the debug session to Instruments using the Memory Report panel Attaching the debugger to the tunnel provider process and handing over the session to Instruments using the Memory Report panel while choosing restart Profiling directly from instruments by selecting the running tunnel provider process Profiling directly from instruments by selecting the running tunnel provider process while attached to debugger in XCode Profile directly from XCode (command-I) running the packet tunnel scheme Neither of these options have resulted in successfully instrumenting the tunnel provider. This was not an issue in the past, and I remember that option 4 used to do the trick. Any advice, and are there people still able to achieve this?

I read in the latest release notes that custom User-Agents will no longer be sent to HTTPS proxies. How should we expect the user agents to be filled for these proxied requests? Would these be instead populated with the 'standard' user agent that URLSession would produce?