I’m in over a month now with non-working RCS on my iPhone 15 Pro. Apple blames the carriers, the carriers tell me it’s not them (mostly T-Mobile since I have good contacts there). They tell me they can’t really do anything about iPhones not working on RCS, go back to Apple. This is what it looks like:

In short, it’s probably Apple or Google and there’s zero accountability from Apple. I have AppleCare+ and really hoped they’d actually try to troubleshoot and fix this rather than waste my time working around it (in a stupidly expensive way for me and Apple).

I’m OS agnostic as much as possible, I daily both Android and iOS devices and previously used BlackBerry 10 and Harmattan (Nokia N9’s OS). If Windows Phone was still around I’d probably still be running that as well. If it’s possible to gather information on how all this works under the hood, I can and do. The OnePlus Android devices I’m running are my own LineageOS builds.

Previous history fixing MMS failures for Carriers/Vendors #

I’m also happy to blame carriers and vendors: I previously brought and helped resolve an issue with Verizon Wireless on LineageOS phones due to how MMS messaging works. Here’s my initial submission, their developer LuK found a better way to go about it, but it at least started the ball rolling: https://review.lineageos.org/c/LineageOS/android_device_oneplus_sm8250-common/+/333379

In short: When you received a picture message on Verizon in the past their network would notify your device that a new message arrived. When the device went to grab and download the image, it sends something similar to browser User Agent, called a UAProf. This is a link to a file that describes what the phone can handle, so a smartphone gets a high resolution image and a featurephone gets a lower resolution one. Verizon’s management sucks and decommissioned the domain that hosts all the UAProfs for their devices. Of note, Verizon is uniquely affected by this issue, T-Mobile doesn’t care what UAProf a device advertises, it’s not required on their network. I haven’t done enough testing with AT&T to answer whether it’s an issue for them.

MMS Failure Demonstrations #

This is a former link to a Verizon UAProf for a Samsung device: http://uaprof.vtext.com/sam/i515/i515.xml

Notice it doesn’t load? Apple/Blackberry and basically any non-Android manufacturers didn’t trust carriers to host these files. Some manager at Verizon decided to kill the vtext service and also fucked over any MMS users on their network not using an iPhone.

Here’s Apple’s: https://www.apple.com/mms/uaprof.rdf.
And here’s Blackberry’s: https://www.blackberry.com/go/mobile/profiles/uaprof/9700/5.0.0.rdf

I’m getting off-topic though, I just wanted to post some context that this is not my first rodeo with fixing these kinds of issues. Carriers are incompetent with this sort of interoperability and they gave up on running their own RCS servers to let Google do it through something called Google Jibe, I’ll talk about that soon.

Starting around the end of 2023, Google started to maliciously break RCS for custom Android OS’s. I say maliciously because it was a silent failure, RCS reported as working, but messages wouldn’t go through, and incoming messages would fail to receive. Google could have remained silent about it and rumors probably would have swirled: Perhaps it was a technical issue or the custom ROM developers’ faults?

No, Google intentionally broke it.

They straight up admitted to blocking it: https://www.androidauthority.com/google-silently-blocking-rcs-rooted-android-phones-custom-roms-3421652/ and it wasn’t until months later that they even showed a notification that it was disabled on affected devices. I really hope some lawyer or regulator reading this will get to extract their pound of blood because Google loves to boast about doing 911 over RCS: https://blog.google/products/messages/google-messages-rcs-911-emergency/

Eventually for my own devices I would spoof to the fingerprint of Google PIxel devices to be able to use RCS. It has mostly continued to work since then, but it begs the question: If I could reliably work around the blocking, then what excuse do you have about it being to prevent spam? Since those spammers will just use the same methods I’ve used, which are hardly secret. It just aims to hurt users that want some control of their device.

At some point Apple was dragged kicking and screaming into RCS interoperability. I actually have some sympathy here because MMS was really a terrible protocol that nobody should have adopted and Apple was dragged into supporting that years after the original iPhone launch in iOS 3. Regardless, with iOS 18, Apple brought in baseline RCS (version 2.4) support. It is hoped that they will update it sometime in the iOS 26 series to include E2E encryption.

RCS always worked on my phone in iOS 18 until the past month when I upgraded to iOS 26. I should note that unlike Android, I do not modify iOS device in any way, basically I expect it should ‘just work’. The only unusual thing I run is Mullvad’s DNS to act as an adblocker, but so does my family and their iDevices don’t have RCS issues.

I am a dual-sim user on T-Mobile and US Mobile (usually on the AT&T network). With iOS 26 both lines have been stuck on “Waiting for activation…”. If I transfer the lines off to any other iPhone, the lines activate in seconds. I additionally took a Verizon Wireless line from my Mom’s 14 Pro Max and it also displayed the same issue. My girlfriend has a 14 Pro Max and a SE3, both can activate my RCS lines when I transfer them over.

I’ve done an absolutely exhaustive level of testing to see if these lines would activate on my phone, there’s probably more than this but this is what I could think of:

1. Rebooted/Toggled Airplane Mode/Toggled RCS
2. Resetting Network Settings
3. Removed all my VPN profiles and apps. (Mullvad/Orbot/Mullvad’s DNS profile/my server’s wireguard profile)
4. Deactivated one of my lines and tried reactivating RCS.
5. Disabling 5G and trying to activate RCS.
6. Reissuing both eSIM’s from the carriers.
7. Toggling iMessage.
8. Resetting All settings 9 Resetting everything on device.
   • Restoring from iTunes backup
   • Restoring from iCloud backup (literally activated a trial to be able to do this)
   • Tested resetting with and without eSIM.
9. Recovering device (recovery mode, setting up as new device)
   • Both with and without eSIM’s on device.
10. Disabling RCS and waiting days before attempting to reactivate.
11. Updating my e911 addresses, disabling/renabling wifi calling. Testing on Wifi.
12. Reissuing just T-Mobile eSIM but to the other IMEI on the phone that it’s normally not on.
13. Deleting the numbers out numerous times in Carrier settings (I have no idea what this does but it does make the signal reconnect).
14. Testing sending messages from devices that work with RCS to this device in hopes it upgrades.
15. Testing the iOS beta releases.
16. I brought up the Gentoo Linux packages for libimobiledevice so I could run idevicesyslog and dump hundreds of megabytes of live logs in hopes of being able to see what the phone is failing on: (the packages) https://github.com/joecool1029/joecool-overlay/tree/master/app-pda
    • This is a small T-Mobile related excerpt of what looks like the problem could be. Specifically, UserInteractionRequired.xml. I don’t know what interaction is needed and why Apple’s software isn’t presenting more information, but this is the best I could do from digging through a ton of redacted logs: Nov 9 15:54:14.294398 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294406 CommCenter[101] <Notice>: #I --> switch: true, bundle_support: false, entitlement_support: true, enabled_by_default: true, disabled_by_profile: false, is_store_demo_device: false Nov 9 15:54:14.294415 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294424 CommCenter[101] <Notice>: #I --> encryption_supported: false, push_supported: false, push_enabled: false, private_relay_supported: false, msisdn_source: (empty) Nov 9 15:54:14.294432 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294440 CommCenter[101] <Notice>: #I --> Changed: (nothing) Nov 9 15:54:14.294448 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294455 CommCenter[101] <Notice>: #I Ims registration interface: kUnknown --> kCellular Nov 9 15:54:14.294463 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294471 CommCenter[101] <Notice>: #I Lazuli model not allowed: [provisioning style: kUsingToken, sms online: false, msisdn OK: true] Nov 9 15:54:14.294479 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294487 CommCenter[101] <Notice>: #I Provisioning not possible Nov 9 15:54:14.294494 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294505 CommCenter[101] <Notice>: #I Infinite validity of UserInteractionRequired.xml xml Nov 9 15:54:14.294514 CommCenter[101] <Notice>: #I [config.rcs.mnc260.mcc310.jibecloud.net] Declaring IMS not ready. Unexpired : UserInteractionRequired.xml Nov 9 15:54:14.294522 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294529 CommCenter[101] <Notice>: #I Nudge not required: Allowed Nov 9 15:54:14.294537 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294546 CommCenter[101] <Notice>: #I Evaluate recheckEntitlementForRCS. Ent:Allowed, Switch toggled:false, CB recheck:false Nov 9 15:54:14.294554 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294561 CommCenter[101] <Notice>: #I Entitlement result: [RCS support: kSupported, user eligibile: kEligible, token-support: true] Nov 9 15:54:14.294569 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294577 CommCenter[101] <Notice>: #I Evaluated provisioning style: kUsingToken Nov 9 15:54:14.294584 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294592 CommCenter[101] <Notice>: #I Retrieving feature switch state Nov 9 15:54:14.294600 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294608 CommCenter(CoreServices)[101] <Debug>: Starting database access (depth 0, options: 1) Nov 9 15:54:14.294616 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294624 CommCenter(CoreServices)[101] <Debug>: BindingEvaluator::CreateWithBundleInfo(ID=<private>, name=<private>, CC=????, vers=(null)) Nov 9 15:54:14.294633 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294641 CommCenter(CoreServices)[101] <Debug>: Truncating a list of bindings to max 1 known-good ones. Nov 9 15:54:14.294648 CommCenter[101] <Debug>: #D supportsHOVirtualInterfaces: ret = false Nov 9 15:54:14.294656 CommCenter(CoreServices)[101] <Debug>: Truncating a list of bindings to max 1 known-good ones.

So this last entry probably tells us where to look. The carrier (T-Mobile here) is provisioned for RCS, it’s receiving this interaction required file with infinite validity. So long as that’s in place, it fails to activate. (This is a guess, but it’s certainly more information than the KB articles give on Apple’s sites).

Apple does not provide their employees with correct information on troubleshooting this issue. They do not empower them to properly troubleshoot the issue. #

The standard instruction given to them is: “Do not take accountability, blame the carrier.”

So then I come in and say I have failures with all 3 major carriers and categorically refuse to accept that explanation, when I know my lines work just fine on other iDevices.

The Apple Store initially blamed software, this would be reasonable except we’ve reloaded the state of my phone 3 times now (once from iTunes, and twice now from iCloud, tomorrow will be the 4th time). I gave them permission to wipe any setting and recover the phone, but I go a step further and request they transfer my T-Mobile eSIM to another store device preferably in the 15 Pro line. They cannot do this because of user privacy reasons. This is a dealbreaker from troubleshooting, I am not made of money and I do not have any additional 15 pro devices to test with, it’s already crazy enough I have multiple carriers at the ready to test, 2 14 Pro Max’s and a SE3.

I think this is where we need information. As I said before, the carriers in the US gave up running their own RCS infrastructure and Apple’s employees aren’t really trained about this situation. With the exception of my own knowledge and the logs I pulled from the phone, Jibe was not mentioned once in the 3 phone calls and the multiple hours onsite in Apple Store today.

I have no business relationship with Google Jibe, and there’s no way for me to interact with or contact them. Their documentation is probably here but I can’t read it, since I’m not a carrier partner: https://docs.jibemobile.com/ Apple knows there’s a ‘carrier’ issue, but in reality, RCS is run through Google Jibe in the US and this was never once disclosed to me. I never brought it up until this blog post, I cannot go into a store and say “I have been using opensource tools to analyze the logs from this phone and think it’s a failure with Jibe”. Do you get how crazy this sounds?

Since they hit a wall and I refuse to continue to entertain the “go bug T-Mobile/US Mobile” direction, Apple is swapping the board in my phone. Of course they didn’t have the parts in the store to do it, so I have to wait to drive back tomorrow for them to do it. This will have new IMEI numbers and given the experience I’ve had with these lines activating on 3 other iDevices, it should probably work. The only way it wouldn’t is if this was a generational issue, but they have not given me a way to test this. They adamantly tell me: “We are doing you the favor as a courtesy, we don’t believe this is our problem.” I know they are trained to say this but it’s terrible customer service. I shelled out for Applecare+, if it might be the phone just swap it and analyze it back at Apple HQ, I’ve done enough testing now to know it’s something with just this specific device. I referred people to use iPhones because in general they do not often have these issues and the customer support was good. The board swap solution they are offering only wastes my time/fuel and punts the problem down the road. Since we never actually looked at the logs I might hit it again, other users might be affected.

I use opensource software not because it’s inherently better, but rather because I can at least triage, understand, and fix problems. Give me a radar Apple. I’m a rare dual-SIM user in the US with a Google Jibe RCS failure. Where did it fail? Dig into my logs and tell me: Is it because I hop between primary data carriers (because the whole reason I have dual-carrier is better service coverage). I don’t spend a lot of time on WiFI, I run my house on mobile carriers. The only thing I know is I didn’t change my configuration from iOS 18 to iOS 26, but things stopped working and there’s no way for me to downgrade to 18 because you stopped signing it!