I see this issue Too.... Sometimes when running using XCode using Sandbox push servers I just never get thedidUpdatePushCredentials callback. It will frustrate me and then after a while it will start to work for a while..It is very frustrating hene trying to develop code for VoIP PushsSo far I have not seen the issue if I make an AdHoc distribution which will use the Production Push Servers. But I am worried when I deploy my solution that I will get real users seeing teh problem.Has anybody out theree found the reason for this?

I also see iOS killing the App Even BEFORE our App gets to run didReceiveIncomingPushWithPayload as can be seen from these 4 lines from console log OUR PUSH ARRIVES default 14:43:56.306168 +0100 apsd &lt;APSCourier: 0x100e0d7d0&gt;: Received message for enabled topic 'mds.mds.ourapp.us2.voip' onInterface: NonCellular with payload '{ aps =     {         alert = "[1095],[Dave Maj Main],[],[],[0]";     }; }' with priority (null) for device token: NO .... iOS DECIDES TO KILL OUR APP after 28 mSec error 14:43:56.334866 +0100 callservicesd Killing VoIP app mds.mds.ourapp.us2 because it failed to post an incoming call in time. .... didReceiveIncomingPushWithPayload is run in the App but iOS has already decided to kill it default 14:43:56.341304 +0100 Our App MDS DEBUG => => => => => => New Push: Payload is [1095],[Dave Maj Main],[],[],[0] .... iOS kills our App default 14:43:56.345273 +0100 runningboardd [application&lt;mds.mds.ourapp.us2&gt;:641] Terminating with context: &lt;RBSTerminateContext| domain:10 code:0xBAADCA11 explanation:<no explanation given&gt; reportType:CrashLog maxTerminationResistance:Interactive>

We are still seeing this issue on iOS14 Beta 8 After some testing we have not seen it happen yet on iOS 13.7 I presume iOS14 will be released soon so I hope we can get some solution from Apple. Are other developers seeing this?

I have been testing iOS14Beta 8 and I made about 400 incoming VoIP Pushes in the space of an hour or so. For those incoming calls I got two cases of "Killing VoIP app because it failed to post an incoming call in time" even though my code does that. I have logged that Issue in a separate Forum item ( https://developer.apple.com/forums/thread/653756) as I think that is a bug in iOS14Beta's as I have never seen that issue with iOS13.x Anyway after the second failure all other incoming VoIP Pushes were blocked with "Application will not be launched because it failed to report an incoming call too many times (or repeatedly crashed.)" This happened about 33 hours ago.. I tried restarting the iPhone (as Kevin DTS suggested) but it did not help. Pushes were still blocked. So maybe that behaviour has changed since Kevin's post. Every few hours I make a test call to the App but the VoIP Push is still ignored.. Kevin also suggested that it should allow Pushes through after ~24 hours. It would be great if we could get clarification from Apple about the following 1) What does "in time" mean? When we get a VoIP Push my understanding is that you must offer the call to Callkit before you return form pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void (^)(void))completion. However is there a time limit from when you start running this routine? We need to do some preprocessing on the pushed data before offering the call 2) When will iOS block all further incoming calls? For example is it if you fail to offer two calls within an hour. Or is it if you fail to offer 2 calls period? If you fail to offer a call and then 3 days later fail to offer a call will that Block all further calls. What is the algorithm? 3) When VoIP Pushes are blocked then what needs to happen to allow then through again? Is it simply a time period? if I keep sending calls in does that reset that? IE. Do you need no incoming Pushes for 24 hours to clear it? 4) Is there a new Issue in iOS14Betas Please see the separate thread about that https://developer.apple.com/forums/thread/653756 General Comment It has been a lot of work and very difficult to change our code to always offer calls before returning from "didReceiveIncomingPushWithPayload" routine. I can understand why Apple insist on that and will kill the App. HOWEVER I suggest that blocking all further incoming calls is a very very severe step to take. In complex call handing situations where you may not have a perfect connection back to your VoIP Server and there are time lags etc it is impossible to avoid the situation in extreme circumstances where a VoIP Push arrives but you are not in a position to offer the call. Apple's Callkit framework is far superior to the competition but this step makes it extremely difficult to make a reliable VoIP App. A VoIP App is useless if calls are blocked..

Further to this after further experimentation... Anything to the right of the Colon is shown but anything to the left of and including the Colon is not shown on the calling screen!!?

In addition to the issue with the Colon .. I also notice that Upper Case Letters are displayed as Lower Case So if I offer "Dave Maj" as the text then on the incoming Call Screen it shows as "dave maj" but later in the iPhone native phone App Recent list it is displayed correctly as "Dave Maj". This is all still happening in iOS15 Beta 6

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.

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

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

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

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.

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.

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 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.

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