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

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.