Hi Kevin Many thanks for the reply. I am a bit unclear about your last comment. You say "the fix we shipped in beta5 does prevent that particular edge case.The team is looking into possible fixes ..." Did you mean to say ... "the fix we shipped in beta5 doesn't prevent that particular edge case. The team is looking into possible fixes...". I hope that is what you meant :-) because in iOS27 Beta6 I still see the problem when we start our App immediately after the first iPhone unlock after a power-up. That was the only way that I could 100% repeat the issue. Other times that I saw the problem seemed to happen randomly and very infrequently. However as I said previously...... The "immediately after" unlock issue seems to be "worked around" when for my first outgoing call then I will invalidate the instance that I had setup when App powered up [theMDSCXProvider invalidate]; theMDSCXProvider = nil; and then I create a brand new theMDSCXProvider. So this ties in with your "setConfiguration" workaround I believe. To be 100% clear without that "workaround" then I only see the issue after you first power up the iPhone up and then unlock and immediately start our App. (Please note that Ive recently had a major surgery and am recovering so my responses here might be slow as I slowly return to full-time work!)

I have found way where we can repeat this issue as follows in iOS27Beta4 1) Power phone completely off. Black screen. No power 2) Wait say 10 sec 3) Power phone on 4) Unlock the phone with your passcode 5) IMMEDIATELY Open my App 6) Wait a while (Say 20 sec). You could actually wait here for hours and still see the bug! 7) Make an outgoing call If I unlock phone and wait 20 sec and then open my App then I will NOT get the bug. So I think that this is something to do with Phone Unlock I am presuming this is some type of Race condition after UNLOCK where iOS is setting up something to do with Callkit and if at the same time my App opens and creates instance of CXProvider then something gets messed up. theMDSCXProvider = [[CXProvider alloc] initWithConfiguration: the_providerconfig]; To try prove this I changed my code so for my first outgoing call (Only) then I will invalidate the instance that I had setup when App powered up (line above) [theMDSCXProvider invalidate]; theMDSCXProvider = nil; and then I create a brand new theMDSCXProvider. When I did that I cannot repeat the problem I do not know if this is the only way this issue happens. When I saw this issue in previous Betas it was happening after other calls had already been made since the phone had been unlocked. I updated my FB23709940

This is still happening on iOS27 Beta 4. My very first call after iOS27 beta4 installation failed. I cannot repeat it since. Also a colleague of mine has now seen the same issue. I have not received any feedback to my FB.

Hi Albert i have filed the bug FB23709940 Thanks Dave

Hi Albert I will get around to filing the formal bug soon. I'm currently moving to a new MacBook so I've been offline. However I just had a quick look at the sysdiagnose file that I linked in previous post. I can see other successful calls preceding the failed call. The error in log seems to be error 2026-07-09 18:08:10.408839 +0100 callservicesd SessionCore_Create.mm:92 AudioSession creation failed with an error: <NSError:0x7ccf812160(NSOSStatusErrorDomain:2003329396) - { NSLocalizedDescription = "Session creation failed in server"; }> Maybe that might be of help? Thanks Dave

Thanks Albert Before I do that .. Just to check....because it seems to only happen for me on beta software is it allowed to actually file a code level support? (Because it's Beta)?? Also just to say you should be able to get the sysdiagnose from the link above. Thanks Dave

Hi Albert It has now happened on iOS27 Beta3. I am running on an iPhone 12. I am based in Dublin Ireland. So the local time is UTC+1 All times below are "Local" 17:04 Made outgoing call. Successful! 17:55 Made outgoing call. Successful 18:08 Made outgoing call. ActivateAudioSession did not occur so I had no path I straight away tried to get a sysdiagnose file. I tried to add here as an attachment but it would not attach (Too big maybe!?) so I have added a link to my google drive where I uploaded it https://drive.google.com/file/d/1yUINaVSzD-OjeYGKoM_vgmANP76yNVGG/view?usp=share_link Further info (In case relevant) I then waited till 18:56 and made another outgoing call. But that too has no path I then made an incoming call at 18:58 and answered the call. In that case I did get a call path !!! So that seemed to kick it out of the locked up state?! Note?: Unfortunately I cannot repeat this "at will". So I just keep making test calls every so often to try get it to happen.

Hi Albert Many thanks for the reply. I really appreciate it. The problem I had installed iOS27 Beta2 on my iPhone and every so often over a few days I was making test calls. Then one outgoing call failed and every subsequent call failed until I restarted the App. This was alarming for me because I had never seen such a scenario before. From my own debug log I could see that didActivateAudioSession had NOT been triggered by iOS. I then tried to repeat the problem but nearly a week went by before it happened again. So this is a random bug that I cannot repeat at will. Is this a new know issue? Have their been similar reports of this from other VoIP app developers with iOS27? Has that area of the framework been modified in iOS27? iOS27 Beta 3 I have installed this version on the iPhone yesterday. I am trying to repeat the problem but it hasn't happened again yet. If it happens again I will try to get a logfile as you suggest. I wish I could repeat the problem easily but I cannot! Timeout Mechanism? You suggest that I use a timeout mechanism so as the App can recover from the lockup. What should that mechanism do? For example if didActivateAudioSession does not happen after 10 seconds then what should I do? Do I need to kill my CXProviderDelegate object and create a new one? Do I need to recreate my Audio Chain? Historical problems Back in Oct 2016 (!!) there was a thread for a similar issue https://developer.apple.com/forums/thread/64544?answerId=191868022#191868022 They were "one off failures" rather than the App completely failing for every subsequent call which is what I see now. Apple's Stuart Montgomery mentioned it was reported in Radar # 28774388 and suggested workarounds at that time. At that time I found that if I "configureAudioSession" in the completion block of a successful theMDSCXProvider reportNewIncomingCallWithUUID:theUUID update:theCallUpdate completion then I got no failures of didActivateAudioSession. My code has been like that for 10 years working well with thousands of users. But now I think iOS27 has broken something!! Thanks for your help Many Thanks Dave

Thanks Kevin... This original post is from 8 years ago. I just tested it again now and there is in fact an alert tone given. So it must have been fixed sometime in teh last 8 years. Happy days!

Further to this in case it helps anybody. When I build my Code with Xcode 16.0 then this problem does not happen. It had been using Xcode 15.2 The only devices that we had seen with the problem had been running iOS18.0 or iOS18..0.1 . Even iOS18.1 had been OK.

I'm also having same issues with QuickLookPreviewController. I too have been ignoring these warnings. However I now have a particular Testflight user having problems with playing Videos in the QuickLookPreviewController so I believe this is because of the constraints It is a very useful ViewController if it could work properly:-) Here is my Debug... 2024-11-20 20:42:38.128950+0000 My App[82215:2024054] [LayoutConstraints] Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) ( "<NSAutoresizingMaskLayoutConstraint:0x6000021ca620 h=-&- v=--& UINavigationBar:0x11afbadc0.minY == 0 (active, names: '|':UILayoutContainerView:0x11afcf730 )>", "<NSAutoresizingMaskLayoutConstraint:0x6000021ca6c0 h=-&- v=--& UINavigationBar:0x11afbadc0.height == 44 (active)>", "<NSLayoutConstraint:0x6000021d23f0 V:[UINavigationBar:0x11afbadc0]-(0)-[UIFocusContainerGuide:0x600003d283c0'UINavigationControllerContentFocusContainerGuide'] (active)>", "<NSLayoutConstraint:0x6000021d24e0 UIFocusContainerGuide:0x600003d283c0'UINavigationControllerContentFocusContainerGuide'.bottom == UILayoutContainerView:0x11afcf730.bottom (active)>", "<NSLayoutConstraint:0x6000021d2bc0 V:|-(0)-[UILayoutContainerView:0x11afcf730] (active, names: QLPreviewControllerView:0x119c86e70, '|':QLPreviewControllerView:0x119c86e70 )>", "<NSLayoutConstraint:0x6000021d2c10 V:[UILayoutContainerView:0x11afcf730]-(0)-| (active, names: QLPreviewControllerView:0x119c86e70, '|':QLPreviewControllerView:0x119c86e70 )>", "<NSLayoutConstraint:0x6000021ca760 'UIView-Encapsulated-Layout-Height' QLPreviewControllerView.height == 0 (active, names: QLPreviewControllerView:0x119c86e70 )>"

Yes.... it was confirmed to me that the 60 sec behaviour is by design. I would suggest you file an enhancement request with them if you believe as I do that this is too short. For PABX behaviour calls can ring for longer than that in busy situations. Also as far as I know the callback we get from Callkit doesnt allow me to distinguish between a caller rejecting the call rather than this 60 sectimeout. In that case it looks to our call records that the user rejected the call rather than it being a missed call :-(

Just an update in case it helps anybody.... A function was called unexpectedly twice in quick succession leading to the NSSString being de-allocated before NSURL got to use it. I put some defensive code in and it seems to have fixed it

Updated to Sonoma 14.3 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. Am I missing something?

This was happening for me when using Xcode 14.3.1 In Case it helps anybody I found that if I deleted ~/Library/Caches/org.swift.swiftpm then it fixed the problem for me