Also experiencing this issue, but just disconnecting from VPN isn't a good solution for us as we need to be on it to access vital information for work. I submitted a feedback report (FB13194927) but it was marked as "Works as currently designed". This worked in Xcode 14, it doesn't work in Xcode 15. I don't see how Apple can put that on the VPN vendors. AnyConnect isn't the only one with the problem, we may be switching to FortiClient and but I've seen others complain of the same issue with that VPN client as well.

To follow up, we ended up focusing on moving our 2 non-ping CFSocket usages to the Network framework to get that rolled out before we started working on converting the ping code over to a dispatch source. The interesting thing so far is that fixing those 2 seems to have fixed the ping crash as well. It has been about a week now with the fixes being out in prod and we haven't seen the ping crash once so far. This leads me to believe that whatever broke it in iOS 16 only breaks it when there are multiple (concurrent?) usages of it throughout the app.

Are there any resources you can point me to for implementing a ping using Dispatch source? All of the stuff I can find online still uses CFSocket and most of it just straight up uses your SimplePing code. I don't know where I would even start so we may end up needing to go the TSI route (thank you for the information about that).

Okay, I submitted an enhancement request to provide a high-level ping API: FB11989640 AFAICT CFSocketInvalidate is fundamentally broken. I'm guessing from context (since you are saying that it should work and did not crash for you) that you mean "is NOT fundamentally broken"? The crash is not something that happens with every use of the API. I do not understand the rhyme or reason behind it. I have been able to reproduce it but not in any reliable or consistent way, I just run through the code that uses it over and over again and sometimes it will crash. To give you a better picture of the crash, this is an enterprise kiosk application running in stores for customers to use and is running on ~5600 iPads, of which ~2000 are on iOS 16. We are seeing over 200 crashes per day from this same CFSocket stack trace inside CFSocketInvalidate. It is crashing ONLY on the iOS 16 iPads. There have been 0 instances of this crash on the other iPads that are mostly on iOS 15 with a few on iOS 14 and iOS 13. The crashes are split between our 3 different usages of CFSockets. The one that is the focus of this post is the SimplePing usage. We also use CFSockets to do socket communication with a card reader device and we are transitioning this use case to use NWConnection instead. The final usage is inside of GCDAsyncSocket inside a logging library which gets used for some logging to Splunk, we have not identified how we will replace that one yet. I only list these other usages in case their presence somehow informs the issue but I will restate that this code with all 3 of these usages does not crash prior to iOS 16 and we have been using them years. I have attached a crash report from one of the crashes using SimplePing. crash_report.txt Also submitted a feedback report for this CFSocket crash: FB11989660

It seems this is possible now with Xcode 13 and later. See my other post about it here: https://developer.apple.com/forums/thread/717592?login=true&page=1#732509022 The docs for provisioning with managed capabilities have steps for setting it up, specifically under the "Editing an App ID with additional capabilities for Xcode & Xcode Cloud" section. Special thanks to eskimo for letting me know about this.

Awesome! I found a line on that same docs page (https://help.apple.com/developer-account/#/dev38c81d4cd) under the section "Editing an App ID with additional capabilities for Xcode & Xcode Cloud" that says "This enables automatic signing for features like CarPlay and Multicast Networking." 🎉🥳🎈🎊🎁 There should have been like a 1 minute WWDC session (I guess WWDC 21?) just titled "Automatic Signing for CarPlay". This should be shouted from the rooftops 😂 I want to go find every past post where it was said it wasn't possible and give them the good news.

This worked, thank you very much!

Following up on my previous comment. The feedback request resolution now says: "Potential fix identified - In Xcode 14". I haven't found the time to test it in the Xcode 14 beta yet but hopefully our problems with this will be over this fall!

I have this same issue with our Watch app schemes and have also submitted a feedback request (FB9832417) the resolution status has been updated to "Potential fix identified - For a future OS update" so hopefully we'll have a fix soon. Removing it from the repo doesn't work for us since it results in that scheme not showing up in the schemes drop-down. Using git update-index --skip-worktree doesn't work well on a large team since if everyone doesn't do it then it causes issues, and the docs for that command warn that it isn't meant for this type of use case. My latest workaround is to add a pre-commit hook that discards the changes to those scheme files before committing so that it doesn't show up in our pull requests at least. Still shows up in the local diff before committing which is annoying but it's the best i've been able to work out so far that doesn't depend on everyone aligning on the same behavior.

I've got the same issue. In Xcode 13 only, I get "Cannot find X in scope" errors for all the objective-c stuff that i'm using in Swift, but the project still builds and runs successfully.