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

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