Hello DTS Engineer...are you still there? Have you looked at the simple project I created that recreates this issue?

I have uploaded a simple app that recreates the issue to Dropbox. Here is the link: https://www.dropbox.com/scl/fi/yb1b3zh3tzubx0oze6lc4/QLPreviewControllerTest2.zip?rlkey=3m9hiaw06550r5xs4xluoc5gz&st=i3x8obq0&dl=0 The app loads a ViewController with a single button that when pressed creates an object that generates and displays a CSV file via QLPreviewController. When the QLPreviewController is loaded the above flurry of warnings ensue.

I disabled SIP and installed the file and now i get the same issue as @kennywyland FileMerge doesn't show the error, but it crashes immediately with a crash report in Console.

The call central.maximumUpdateValueLength is only valid if you are using the iOS app as a peripheral. In most cases this is not what is happening and therefore there is only a call to peripheral.maximumWriteValueLengthForType which for me ALWAYS returns 512 regardless of the actual MTU being set on my peripheral. The only way I was able to get the actual MTU size in my iOS app was to add a read characteristic to my BLE protocol that is the MTU size and then on my peripheral, when it gets the onMtuChanged callback, set the negotiated MTU value on the MTU read characteristic. Then in iOS, before I need to know the MTU size, I read this characteristic and get the actual MTU value. This gives me a correct value for the MTU.

This doesn't seem to give the actual MTU size but rather simply returns the max value it could possibly be which is 512. I have tested this with a variety of MTU values set on my peripheral and iOS always returns 512 for this value. The only way I was able to get the actual MTU size in my iOS app was to add a read characteristic to my BLE protocol that is the MTU size and then on my peripheral, when it gets the onMtuChanged callback, set the negotiated MTU value on the MTU read characteristic. Then in iOS, before I need to know the MTU size, I read this characteristic and get the actual MTU value. This gives me a correct value for the MTU. I think this is a ridiculous solution/hack since CoreBluetooth is obviously getting the onMtuChanged callback just not making it available to the delegate. What's the point of a delegate if you don't give it all the information?!?!