The most persistent issue with compatibility is that there is no defined standard on what the "body" parameter of the SMS URI scheme should contain and what's expected from the sender implementing this. While SMS-to link solutions favor the smsto: Suffix prefix, the prefilled text parsing is wildly different between iOS and Android and even different default messaging apps on the same OS. A common blocker? The question mark syntax that indicates the message body. Android expects a question mark (?body=) to follow the cell phone number, but we've seen iOS versions choke on this if the cell number is not present on the link or specific there results at times in an ampersand(&body=) and at times fails to load the app altogether. iOS 15 and later Apple sometimes defaults the smsto: code with no recipient to "Add to Contacts" screen versus composer resulting in breaking the intended marketing workflow. An unanticipated trap door in our experience in global software delivery is URL encoding. If the body text is not properly encoded iOS can just ignore that parameter passing leaving Android distributions to show the %20 to the user. Because of this fragmentation in user experience, the safest engineering choice is to use a short branded URL that works for device identification then redirects based on device detected and sends the user to the associated SMS deep link for the right device. It is easy to think of QR codes being a "set it and forget it" technology when mobile OS updates can quietly break these workflows. Testing against native camera apps from the top three manufacturers, Apple, Samsung, and Google is your only guarantee that your call-to-action actually makes it to the messaging app!
The biggest compatibility issue I see is with SMS QR codes. They open differently on iOS and Android phones. Usually works fine for iPhones but Android behavior will vary by manufacturer. For example, some Android phones open a browser instead of messages. This inconsistency is what makes SMS QR codes unreliable across phones.