I have eventually "trapped" the contents of the NSString that was converted to a NSURL which causes a crash in a real customer site I show it below...( For our customer privacy I've hidden our server replacing it with xxxxxx.xxxxx.xx below but they are just lowercase alphabetical characters) If I run this myself now then I don't get a crash!!! SO for some reason this just occurred in the real customer at that time!! Anybody got any ideas? I am running this on Thread 2 in case that is a factor? NSString *dave = @"https://xxxxxxxx.xxxxx.xx/test/gate/b8e23d6e5dcfb0d5025fcc928f55ac1d5ae6ed03/settings"; NSURL *url = [NSURL URLWithString:dave]; <--- Crashes here

Same here Cannot compile my code anymore Sandbox: rsync(37768) deny(1) file-write-create /Users...../Build/Debug-iphoneos/MyApp.app/Frameworks/InputBarAccessoryView.framework/.Info.plist.nd7plo

I also see this.. In the device logfile I see the following 10:33:40.041163+0100 callservicesd Exceeded ringing duration of 60 seconds; disconnecting call with identifier I have seen it on a device running iOS16.1.1 and another device running iOS16.4.1 So this looks like an intentional action by Callkit... This makes a VoIP App very limited in PBX Call queuing situations where calls might be ringing for long durations. Is there some way to avoid it. I cannot find anything

I get the same warning in XCode14 Beta 5 in my objective C main() when it calls UIApplicationMain(argc, argv, nil, nil); (See below) I use a WKWebView to allow user to login. For me it seems to happen if I display a WkWebView when I start my Aop. If I run and don't need to display the WkWebView (Ie I already have login details) then I don't seem to get the warning... int main(int argc, char *argv[]) {     @autoreleasepool {         int retVal = UIApplicationMain(argc, argv, nil, nil);         return retVal;     } } All a bit worrying but I have no clue what it means.

Update to above In summary I believe that with Simulator running with Xcode 14.0 beta 5 ( (986.2) SimulatorKit 624 CoreSimulator 857.7 ) simulating iOS16 then Callkit didActivateAudioSession never happens. If I use that simulator to run iPhone with iOS16 then didActivateAudioSession NEVER gets called so I get no speech path on my calls If I run from that Xcode on my real device iPhone 12 running iOS16 Beta5 then it works correctly (didActivateAudioSession is called as expected) If I run on the simulator running iPhone 12 with iOS15.2 then that too works correctly (didActivateAudioSession is called as expected) If I run on simulator with Xcode 13.2.1 running iOS15.2 then that that too works correctly (didActivateAudioSession is called as expected)

I eventually updated to Monterey 12.5 But I still see the same problems There were no VoIP Pushes to start an incoming call Callkit does not seem to work so I get no Audio.

Further to this I discovered that the "fault" seems to be only when the UIPickerView is a component of an xib file. If after the xib file is loaded I then manually change the frame height of the UIPickerView then it "fixes it". Without this workaround the height of the UIPickerView is about 1.75 times what it should be.

Hi .... No I haven't had any progress with this.. I moved onto other tasks... I have not tried Monterey yet.. I will give it a try when I get some time. Thanks for the reply

Hey Scott.. Thanks... Yeah a few days I had already seen your Forum post with Eskimo about iCloud Frame Relay and I checked with customers and subsequently ruled it out as a cause of the problem. This morning we actually discovered the real cause of our problem... On one of our users experiencing the problem at the BSD socket level getaddrinfo was resolving to BOTH an IPv4 and IPv6 address. My code only ever tried to connect on iPv6 in that case. That failed to connect presumably because the cellular provider has some type of fault. They are newer 5G networks here in Europe. I tried a new testflight version with customer this morning that will now try to connect to IPv4 instead if that happens and it fixed the problem!!!! It was another forum item I saw from Eskimo https://developer.apple.com/forums/thread/48996?answerId=146136022#146136022 which pointed me in this direction where he says "BSD Sockets requires you to call getaddrinfo and then write a loop over each returned address, opening and connecting the socket, until you get one that works. Doing that reasonably well requires some ugly code, code that can’t be as good as the OS’s implementation!! That man Eskimo is a genius and saved me a ton of work!! I was close to starting a major rewrite of our App to use higher level networking code. Thanks for your help

No.. I just moved on and accepted it! Have not rechecked recently. Too busy with other stuff.

Hi.... We are using BSD Socket code too (For last 9 years) and have recently had some reports (So far only on iPhone 13 and iOS15.x) of sockets not connecting. However it is only a problem when connected on WAN. If user switches to WIFI then everything is OK. From your experience with the problem does changing from WAN to Wifi make any difference? i'm not sure if what we car seeing could be this issue or something else.