If I understand correctly, ATT MTU size negotiation is managed by CoreBluetooth automatically and transparently. (Just in case - I'm not talking about Bluetooth 4.2 PDU size negotiation here - as far as I know, it is rarely supported).I'm not sure if / how to adjust my code to account for the actual MTU size to make communication as efficient as possible.Let's say, I want to implement duplex serial-like data exchange between two devices (at least iOS 8). As I have seen, common approach (and maybe the best one) is to have two characteristics on the peripheral : one characteristic is "notifiable", the other one - writable. The peripheral sends data to the central through notifications, the central sends data to the peripheral through the writable characteristic.The most technically useful answer that gave useful hints and highglighted possible caveats was http://stackoverflow.com/a/20321542/217823 by Justin Middleton. Is this even today, after 4 years, the most efficient way to implement BLE communication using CoreBluetooth?I have seen a suggestion to use central.maximumUpdateValueLength on the peripheral to avoid pushing more data than the central can accept. Is this value affected by the ATT MTU size? Is there any similar way for the central side also to determine actual current MTU size when writing the data to the peripheral's writable characteristic? Or I should write in safe chunks of 20 bytes and ATT subsystem will automatically collect MTU-sized messages?Also, I have heard that on some implementations you have to add a short sleep() after the first connection to give ATT subsystem some time to negotiate MTU sizes. Is this necessary for CoreBluetooth or does it happen automatically and I won't receive connection delegate calls sooner than MTU size negotiation was complete?