Proof

expo-sms

native-seam: the upstream expo-sms JS (SMS.js wrapper, attachment processing, argument validation, the {result} resolution path) runs unchanged from the bundle; only the ExpoSMS expo module is ours, mirroring ExpoSMSModule.swift on the reference iOS Simulator EXACTLY — isAvailableAsync returns false because MFMessageComposeViewController.canSendText() is false on the Simulator, and sendSMSAsync throws the verbatim SMSUnavailableException reason "SMS service is not available" (the !canSendText() guard). this IS the complete faithful contract on the reference device: the iOS Simulator genuinely cannot send SMS, so an app calling expo-sms there already gets exactly this. same faithful "the platform/sim cannot do this, and that is correct" tier as react-native-exit-app / expo-local-authentication.

85%

API coverage

No visual proof cases have been published for this package yet. The registry summary below describes what the compat layer implements.

Working (2)

isAvailableAsync (false — exact MFMessageComposeViewController.canSendText() on the Simulator)sendSMSAsync (rejects with the verbatim SMSUnavailableException reason); real upstream wrapper handles argument validation/attachment processing and would resolve {result:"sent"|"cancelled"|"unknown"} on a device that can send

Missing

no real Messages compose UI can present — but neither can the reference iOS Simulator (MFMessageComposeViewController.canSendText() is false there); a real send path needs physical SMS capability the Simulator and browser alike do not expose