So I created test app and requests from it behave as expected. If the domain is set via matchDomains is gets "routed" to my VPN. But the Instagram example does not work like this. The app uses i.instagram.com and graph.instagram.com - but even if I try to add them to matchDomains it doesn't work. When matchDomains is [""] - then Instagram and other apps get "routed" to my VPN. I am using the NEProxySettings as part of the NEPacketTunnelNetworkSettings so I can set my local proxy server as the destination for connections. The reason for my matchDomains experiments is that I need to reduce battery consumption and since there are predefined domains that my VPN needs to handle (and can ignore the rest), I am trying to use this settings to use the tunnel only for connections when really necessary.

So I did more testing and so far what I found is that the matchDomains actually seems to work correctly, but not for instagram.com as I already mentioned. I really have no idea why this domain does not work, since I can see the connections in the debug console. From the apps I tried Twitter for example with twitter.com as match and it worked fine for website and app. I also tried subdomains like api.example.com and it works as expected. Is this possibly wort a TSI report? But I don't think there is anything else configuration-wise that I could try? Well, my usecase is a bit different and it is not intended as traditional VPN. It is closer to tools like Charles Proxy or Proxyman.

This is what I expected, actually. Although I will not comment on what I believe is happening here, I would urge you to consider what would make a network request through a proxy fail to reach the proxy I totally respect you don't wish to comment, but I think I perhaps did not describe the issue correctly, as the problem is not that the connection is failing, but rather it doesn't arrive at the tunnel at all. To summarize my observed behavior based on matchDomains settings: matchDomains = [""] Matches all connections - including Instagram app. - as expected matchDomains = ["twitter.com"] Matches Twitter website and app (specifically 3rd party client Tweetbot) - as expected. matchDomains = ["instagram.com"] Matches only Instagram website, not its app - this feels to me like an incorrect behavior. Since I am handling all Instagram connections in the tunnel when I match all domains.

@meaton filled the feedback: FB9414046. Honestly dont have much experience with this so if something is missing or needs clarification - I am happy to update the feedback. Thanks.

Thanks! This may be that you are trying to communicate with the device directly after association and that is why you are receiving these errors. If so, add a small delay in to allow for the IP and the association to setup correctly. I am attempting the connection only when the completionHandler gets called, which seems to be as soon as user is done with the system dialog? Meaning they either press "Join" or decline. Then I have 0.5 second delay before attempting to access data from the game console in this case. Unless the completionHandler is somehow called multiple times, I have no idea how accessing the device (or trying to) could lead to errors I am seeing? There is also this one: NEHotspotConfigurationErrorAlreadyAssociated which I would expect to get in cases where I am attempting to join the same network for second time, but I haven't got this one yet. Also, there have been some issue using the flag for joinOnce in iOS 15 Hmm this possibly be it, as I am indeed using this flag. The majority of devices that report the mentioned erros are various versions of iOS 15, but not all of them. Since disconnect should happen as soon as the game console stops providing network, I think I can safely remove this flag and see if there are any changes.

Thanks for the details! I had no idea regarding timing. Changed it to 3 seconds + removed the joinOnce flag. I am going to do phased release and will monitor Sentry regarding these issues.

It looks like the "conversion" to new buffer with the stride is causing issues. When I try saving the original pcmBuffer the callback returns I can hear the sound.

Finally (and unfortunately) managed to reproduce the issue. VPN stays in the "Connecting..." state indefinitely. It also does not help to try "re-starting" it in the settings. Even when I start tunnel from different app which works fine and attempt to start tunnel for my app, it again gets stuck at "Connecting" Here are the logs. The bottom three messages keep repeating over and over again. NESMVPNSession[Primary Tunnel:AppBlock Blocker:EC537A50-9463-4CAA-9A89-B67EE9316BDB:(null)]: status changed to connecting NESMVPNSession[Primary Tunnel:AppBlock Blocker:EC537A50-9463-4CAA-9A89-B67EE9316BDB:(null)]: got On Demand start message from pid 117 NESMVPNSession[Primary Tunnel:AppBlock Blocker:EC537A50-9463-4CAA-9A89-B67EE9316BDB:(null)]: Received a start command from rapportd[89] NESMVPNSession[Primary Tunnel:AppBlock Blocker:EC537A50-9463-4CAA-9A89-B67EE9316BDB:(null)]: Skip a start command from rapportd[89]: session in state connecting Sometimes when "Connecting..." internet does not work at all on the device, sometimes it does

Thanks. From the above issue, the only way to resolve it is by: Restarting the device Deleting the VPN and installing it again Re-install the entire app Switching to different VPN does not help, which suggests to me that there is some wrong state that persists?

Thanks both! That was it! Once I saw the error it did not occur to me to check how the interaction is set up. Also note for others trying this, you need to enable user interaction on the UIImageView otherwise the Live Text button does not work.

With the beta 2 of iOS 16 and Xcode 14, this now appears to work as expected.

Thanks @eskimo! We inspected the form yesterday but it looked to us as something from iOS 15, when Screen Time was strictly for parental control apps and could be used only in Parent/Guardian - Child setup. Whereas with iOS 16, Screen Time API can be used for individual devices.

So we got the entitlement for distribution but I still have the same problem: I tried removing the developer capability in Apple Developer portal and keeping just the Distribution one but did not help.

Thanks! In the end it looks like the issue was entitlement for one of the app's extensions. We tried various things and finally got it to upload.

Hmm you are right, I seem to remember this limitation but have no idea where I first spotted it and cannot find it now. So perhaps I misremember this requirement. These methods are also available on macOS - so I thought that having multiple VPN configs works there.