Apple is actually pretty good about PMTUD as a sender, at least iPhones (but I assume Macs too) will quickly fallback to sending shorter packets if they don't get an ack with a large packet at the beginning of a TCP connection. I'd guess they do it throughout the connection, but I only saw it because network was broken, pcaps from iPhone show working connection, pcaps from Android show broken connection.
It doesn't help that FreeBSD used to do MSS sensibly (thanks to a patch from Microsoft), and switched to doing it the way everyone else does. There's not a good reason to send your naive MSS on SYN+ACK if it's bigger than the received MSS, it's highly likely that the other end can't successfully send a packet larger than they can receive, but it's not unlikely that something in the middle mangles SYN to reflect the true MSS, but doesn't mangle SYN+ACK. I could rant all day.
You can also get very good results by reflecting the received RSS minus 8 (assumed PPPoE), 20 (assumed IPIP tunnel), or 28 (assumed PPPoE over IPIP tunnel).
It doesn't help that FreeBSD used to do MSS sensibly (thanks to a patch from Microsoft), and switched to doing it the way everyone else does. There's not a good reason to send your naive MSS on SYN+ACK if it's bigger than the received MSS, it's highly likely that the other end can't successfully send a packet larger than they can receive, but it's not unlikely that something in the middle mangles SYN to reflect the true MSS, but doesn't mangle SYN+ACK. I could rant all day.
You can also get very good results by reflecting the received RSS minus 8 (assumed PPPoE), 20 (assumed IPIP tunnel), or 28 (assumed PPPoE over IPIP tunnel).