I encountered the same issue. I had one machine where everything was working perfectly and another where it was completely broken — despite having nearly identical setups. After a lot of digging, I realized the key difference was device pairing. On the working machine, I only had simulators. On the broken one, I had both simulators and real iOS devices paired. It seems there's a bug in Xcode where having both types of devices present (real + simulator) causes it to choke when resolving run destinations. Workaround: Use either simulators or real devices You may need to uninstall all simulators if you're using a real device, or vice versa (I have not tried with only real devices). Sadly this workaround is unusable for us, so we had to downgrade anyway. Additional Note: On one machine, even unpairing the real devices wasn't enough. We had to manually delete the system receipt for the Command Line Tools executables package (com.apple.pkg.CLTools_Executables) located at: /Library/Apple/System/Library/Receipts/ Only after removing that was the issue fully resolved. To be honest the issue may be somewhere else entirely, but it hopefully gets fixed soonish.

Once in a while we get back to this thread and I would like to report that we are not able to reproduce this issue anymore (will update this post if things change). We use NEPacketTunnelProvider All our testing was done on macOS 14 Anyone else experienced improvements or are we just lucky in our testing so far?

We have identified this issue to be present in 3rd party library included in our implementation rendering this post invalid. This issue is resolved. Apologies.

Hey everyone. We have taken the advice and added logs from Quinn's post and we have submitted an issue in Feedback Assistant FB12354531 hopefully with everything needed. Normally we could see the init from start to finish would take less than a second. However in the scenario described in STRs below it would take several minutes (basically it would finish the init after unlocking the device for the first time), which lead to system never calling startTunnel. It is only reproducible on devices with passcode set and what is more interesting is that having a SIM with PIN set would prevent this issue as well. Maybe some kind of network reset was happening after entering the PIN. Steps to Reproduce: have a device with iOS 16.5 have a device with custom VPN (NEPacketTunnelProvider) device needs to have passcode set turn device OFF turn device ON wait for at least 2-3 minutes before first unlock (the wait is crucial because unlocking the device immediately does not cause the issue) unlock the device and see VPN stuck in connecting state error 2023-06-15 10:44:07.728569 +0200 DnsPlusTunnelExtension [DnsPlusTunnelExtension] first light - start of init error 2023-06-15 10:44:07.758136 +0200 DnsPlusTunnelExtension [DnsPlusTunnelExtension] End of init error 2023-06-15 10:44:07.765028 +0200 DnsPlusTunnelExtension [DnsPlusTunnelExtension] startTunnel called default 2023-06-15 10:48:21.506808 +0200 kernel memorystatus_set_process_is_freezable: disabling freeze for pid 234 [DnsPlusTunnelExtension] error 2023-06-15 10:48:21.564663 +0200 DnsPlusTunnelExtension [DnsPlusTunnelExtension] first light - start of init error 2023-06-15 10:50:40.616033 +0200 DnsPlusTunnelExtension [DnsPlusTunnelExtension] End of init <- device was unlocked at this time default 2023-06-15 10:52:05.028110 +0200 kernel memorystatus_set_process_is_freezable: disabling freeze for pid 363 [DnsPlusTunnelExtension] error 2023-06-15 10:52:05.053658 +0200 DnsPlusTunnelExtension [DnsPlusTunnelExtension] first light - start of init <- manually turning the VPN off error 2023-06-15 10:52:05.095438 +0200 DnsPlusTunnelExtension [DnsPlusTunnelExtension] End of init error 2023-06-15 10:52:05.107599 +0200 DnsPlusTunnelExtension [DnsPlusTunnelExtension] startTunnel called