IOS 26.5 Update Bug -- RCS/SMS text messages sent from iPad to Android Phones are not delivered

I found a solution to this by working with Gemini. The problem started after upgrading iPad to 26.5.

On iOS 26.5 messages to Android numbers sent via iPad through iPhone (on T-Mobile), the green progress bar would get to 95% and then freeze. The solution involved sending a reset code to T-Mobile.

This allows sending and receiving to Android, but there is a residual (“hangover”) problem with conversations with messages sent prior to the reset for which there was a delivery failure.

Resolving this involves deleting existing conversations in Messages in which messages had previously failed (and *crucially* emptying the “trash” - details below).

Though crucial to being able to begin communicating again with Android users (to whom prior messages in an existing conversation had failed), it was very hard to get Messages to start a clean new “uncorrupted” conversation. (I found no way to clear the cache of a conversation in which a message had failed to deliver without deleting the conversation completely - which was frustrating.)

From Gemini: (Apple support were unable to fix this.)

🔴 The Issue: iPad SMS (Green Text) Failing to Deliver at 95%

Users trying to send standard carrier green text messages (SMS/MMS) from a Wi-Fi-only iPad via Apple's Text Message Forwarding encounter an issue where the outbound text's progress bar freezes precisely at the 95% mark. After a short delay, the message fails completely with a "Not Delivered" error. [1]

The issue typically behaves like this:

• Blue iMessages work perfectly fine on all devices.
• Outbound green SMS texts work fine directly from the iPhone.
• Turning features off/on, rebooting, and verifying the carrier status do not fix the issue.
• Starting a completely new conversation thread might work seamlessly, but replying to certain existinghistorical threads continuously triggers the 95% lockup. [1, 2, 3]

⚙️ The Root Cause

This issue is caused by a dual-layer database and routing token corruption following a software update:

1. Carrier-Level Block: The carrier’s broadcasting towers save a scrambled routing profile for the line, which blocks the local data handoff when the iPad requests the iPhone to broadcast an SMS.
2. Apple Metadata Cache Lock: When an outbound text fails multiple times at 95%, the local Messages database permanently locks that specific conversation thread to the broken carrier tokens. It also creates a formatting mismatch between 10-digit localized numbers and international formats (such as numbers matching or missing the +1 prefix). Even if the network is fixed, the old conversation thread remains permanently broken. [1]

🟢 The Solution: Step-by-Step Fix

To break this loop completely, troubleshooting must follow a specific sequence: clearing the carrier pipeline first, and then systematically purging the corrupted thread caches.

Step 1: Wipe the Carrier's Routing Tower Memory

You must clear any hidden or stuck forwarding commands directly on the carrier network.

1. Open the Phone app on the iPhone.
2. Dial ##21# and press the green Call button. This instructs the network to erase all active, unconditional text/call blocks.
3. Optional Master Reset: You can also dial ##002# and press Call to perform a universal master clear across all cellular routing paths.
4. Restart the iPhone. [1, 2, 3, 4]

Step 2: Fix "New" Conversations by Forcing a Unified Contact Path [Note: this strategy did not help me.]

1. Open the Contacts app on the iPad and locate the problematic contact.
2. If the number is saved as a basic 10-digit number, edit the card to include the global prefix: +1 (Area Code) XXX-XXXX.
3. This forces incoming network texts and outbound iPad handoffs to align on the exact same routing path, preventing future 95% freezes. [1]

Step 3: Purge Stalled "Ghost" Threads (For Defective Histories)

If existing threads are still failing at 95% after the network reset, the local thread cache must be wiped out entirely.

1. Backup Your Data First: Press and hold a message bubble in the stuck thread, tap More, select the text logs, tap the Forward/Share menu, and copy/paste the log into the Notes app for safekeeping.
2. Open the Messages app and Delete the stubborn thread.
3. CRITICAL STEP: If the thread stays stuck, turns grey, or reappears, tap Edit (or Filters) in the top-left corner of the Messages app and select Show Recently Deleted.
4. Select the corrupted conversation and tap Delete Permanently. (If left in the trash bin, the database will continue routing incoming texts into the trash cache, causing an internal indexing crash).
5. Force-close the Messages app (swipe up and flick it off the screen).
6. Navigate to Settings > Apps > Messages, toggle iMessage OFF for 5 seconds, and toggle it back ONto force a clean database reload. [1, 2, 3, 4, 5]

Once the old thread is permanently cleared from the trash, navigate to the Contacts app, open your updated contact card containing the +1 prefix, and tap the Message bubble icon to open a fresh, working text thread.[1]

Same here, slightly different details...

Sending messages from my Macs (two separate MacBook Pros: M4 and M5) to Android/green-bubble contacts fails, even when the thread clearly says “Text Message - SMS.” The send attempt sits for about 3 minutes and then fails with “Message failed to send". Sending the same message from my iPhone works perfectly, and the iPhone-originated message syncs normally to all devices afterward.

One reason I do not think this is the cellular-related issue some people have reported is that both Macs were on Wi-Fi on my Comcast home network when the failures occurred (although I believe the cellular service is used for some of the RCS handshaking). The iPhone itself can still send SMS messages normally over AT&T, so at least on the surface this does not appear to be a carrier connectivity issue.

I initially suspected the new RCS / End-to-End Encryption changes in 26.5, so I disabled all three RCS-related settings on the iPhone (RCS Messaging, End-to-End Encryption beta, and RCS Business Messaging). I also rebooted devices, reset Text Message Forwarding, deleted/recreated threads, and signed out/in of Messages on the Mac.

Another clue: when a Mac-originated message is going to fail, it never immediately appears on my other Apple devices. I’ve submitted detailed feedback to Apple.

Additional testing produced an interesting result that further narrows the issue. Mac-originated SMS messaging is not universally broken. SMS to business shortcodes (FedEx) works normally from the Macs, and I also successfully carried on a conversation from the M5 MacBook Pro with a brand-new Android/green-bubble contact that I had never texted before. However, multiple existing Android contacts still consistently fail when messages are initiated from the Macs, even though those same contacts work perfectly from the iPhone.

This sounds more like an iOS/iPadOS 26.5 Text Message Forwarding issue than an AT&T problem, especially since SMS/RCS works from your iPhone but not from the iPad.

I’d try signing out/in of iMessage on the iPad, disabling/re-enabling Text Message Forwarding from the iPhone if possible, and resetting Network Settings on both devices. If the toggle is stuck, I’d report it to Apple Feedback because it may be a 26.5 bug.

Two days ago in mid-chat I developed this same problem. Today after 2 hrs on with Apple support (they are GREAT!) we found the problem. I had Norton installed, and the VPN apparently caused the issue. Just turning off the VPN didn't resolve it but totally uninstalling it did.

So parts of this worked for me! Thank you! I ran your reply through Gemini as I have Spectrum Mobile (Verizon) and none of the prompts didn’t work for me that you provided. I was able to resolve it with additional information. You’re the best!

Whats what Gemini told me that worked. Hopefully it will help others:

Seeing that "Setting Erasure Failed" message is actually quite common when using these dialer codes on modern cellular networks like Spectrum. While it looks alarming, it does not necessarily mean your phone is compromised or malfunctioning.

Here is the breakdown of why this is happening and what it means for your troubleshooting process:

Why You Are Seeing This

• Carrier Limitations: These codes (like ##002# or *#21#) are legacy "GSM" commands. Many modern carriers, including Spectrum Mobile, have modernized their backend infrastructure. They often disable these universal codes for security or proprietary network management reasons, which causes the "Error performing request" or "Setting Erasure Failed" response.

• Wi-Fi Calling Interference: If you have Wi-Fi Calling enabled, your phone is prioritizing a data connection over the standard cellular circuit-switched network that these codes use. This frequently causes the codes to fail.

• You May Not Have These Features Active: In many cases, the "failure" simply means that the specific forwarding service (like "Fax" or "Sync Data Circuit") is not provisioned on your account, so there is nothing for the network to "erase."

Does this mean you can't fix your iPad/iPhone texting issue?

No. The fact that the code failed does not prevent you from fixing the 95% freeze issue. The core of the problem you are experiencing is almost certainly the "Ghost" thread cache on your local device, not a network-level forwarding setting.

Recommended Next Steps for Spectrum

Since the universal code didn't provide a clean "success," you should focus on the local device synchronization:

1. Skip the Network Codes: Since ##002# returned an error, don't worry about trying it again; your carrier likely doesn't support that specific command.

2. Focus on the "Ghost" Purge: The most effective part of the solution you found is the "Recently Deleted" folder in Messages. Ensure that every single conversation with a "Not Delivered" error is deleted, then go to Messages > Edit > Show Recently Deleted and permanently wipe them.

3. Toggle Wi-Fi Calling: Since Wi-Fi Calling can interfere with SMS handoffs, go to Settings > Apps > Phone > Wi-Fi Calling and toggle it OFF. Restart your iPhone, then restart your iPad. Test the messaging. If it works, you can turn Wi-Fi Calling back on.

4. Contact Spectrum Support: If you have done the "Ghost" purge and the issue persists, the only remaining "carrier-level" fix is to call Spectrum Mobile support and explicitly ask them to "Refresh the SMS profile/provisioning on the account." They can perform a reset from their side that is much more effective than the ##002# code.

In summary: You haven't broken anything, and your phone isn't "hacked." This error is simply a communication mismatch between your iPhone and the Spectrum network. Focus your efforts on clearing the corrupted threads on the devices themselves.

I also did NOT have to call my carrier. Deleting the messages, then deleting the recently deleted messages, switching off wifi calling, rebooting, and re-enabling it fixed my issue.

26.6 fixes this issue.

So I ran into something very similar with my two daughters for whatever reason. Tried a bunch of the suggestions to no avail. Could send SMS to each of them and both of them in a group from iPhone no problem. Send to individual from mac would spin and eventually get a 'Not Delivered' error. Send to group with them from mac would work as expected. I spent some time going through it with an LLM tool and eventually found an oddity deep down in the Messages.app database (sqlite3). I am posting the generic outline here in case anybody will find it useful. YMMV.

Symptoms:

- SMS/RCS forwarding from Mac worked for most recipients.
- A small number of individual SMS conversations would consistently fail with "Not Delivered."
- Sending to the same recipients directly from the iPhone worked fine.
- Group SMS conversations containing those same recipients worked normally.
- The failed messages never appeared on the iPhone at all, suggesting the failure was occurring on the Mac before the relay handoff.

I examined the local Messages database (~/Library/Messages/chat.db).

By comparing a working SMS conversation with a failing SMS conversation, I found that the failing chat record contained a malformed value in the last_addressed_handle field. The working conversation stored the relay phone number in full E.164 format (including the leading +), while the failing conversation stored the same value without the leading +.

Everything else looked normal:

- SMS service type
- account association
- chat identifier
- Text Message Forwarding configuration

After backing up the Messages database, quitting Messages, correcting the malformed last_addressed_handle value, and restarting Messages, the previously failing SMS conversation immediately started working.

So if:

- Text Message Forwarding is enabled and working for other recipients,
- SMS messages to specific recipients fail only from the Mac,
- those same messages send successfully from the iPhone,
- and the iPhone never sees the failed send attempt,

it may be worth inspecting the Messages database for malformed phone-number formatting in the affected chat record.

Important: Back up chat.db, chat.db-wal, and chat.db-shm before making any modifications, and make sure Messages is fully closed before editing the database.

In my case the chat_identifier was their phone numbers because they were direct messages so no need to do any complicated joins via the chat_handle_join table (ask your LLM if your chats fall into that category). In my case the 'good' last_addressed_handle had the full '+1XXXXXXXXXX' but the bad had just '1XXXXXXXXXX'. If those seem off then updating them accordingly.

-- bad
SELECT
    ROWID,
    guid,
    chat_identifier,
    service_name,
    account_id,
    last_addressed_handle
FROM chat
WHERE chat_identifier = '+15555555555';

-- good
SELECT
    ROWID,
    guid,
    chat_identifier,
    service_name,
    account_id,
    last_addressed_handle
FROM chat
WHERE chat_identifier = '+16666666666';

-- fix
UPDATE chat
SET last_addressed_handle = '+15555555555'
WHERE ROWID = AFFECTED_CHAT_ROWID;

I was able to fix this on my iPad by doing a back up and full factory resetting my iPad. It's working fine now with no issues. Inconvenient yes, but it did yield a result.

I have the exact same issue I contacted both Apple Care and my carrier. Both escalated after about two hours of troubleshooting. It's a persistent issue.

Two hours with both AppleCare and carrier support failing to fix it strongly points to one of these:

• Apple-side Messages/Continuity relay issue
• Carrier provisioning/RCS registration issue
• iOS/macOS update bug affecting SMS/RCS forwarding
• Account/device-token issue that normal support scripts cannot reset

I am having the same kind of problem with iPadOS 26.5... iPad won't send SMS/RCS messages to SOME Android users (T-Mobile network), yet iPhone (iOS 26.5) and MacBook (MacOS 26.5) both WILL send to the same users. This happens whether the (beta) Encryption is enabled or not.

Since it affects at least AT&T and T-Mobile, it's can't be a carrier-specific issue. Might try to downgrade the iPad to see if that helps.

On your Mac go to Apps type in console and open it , select your device in the top left pane under "Devices" and click start streaming, immediately send the text message. click stop after the problem is complete. Use the search filter at the top rights to filter for "Messages", you can select the filter on the top bar to limit the logs to errors and faults it makes things a bit clearer. At least on Tahoe(26.5) that's how I did it.

If it helps anyone else here... I got mine working again by deleting any message threads from the "Recently deleted" in the filter options on the top left corner. Then going to my wireless settings on my Mac (Mac mini M4 on 26.5) and turning off "Limit IP address tracking" on the wireless connection setting and reconnecting, after that it's been fine. I did the same on my iPad and it works too.

Relieved to discover this wasn’t something boneheaded on my part; I’ve had this 10th Gen iPad for awhile and had zero issues texting with peeps on droids; once I updated to 26.5 and every message failed at the 180 sec timeout. Attempted resetting the SMS forwarding and such, restarts (multiple), and no joy.

We have many computers here that had NOT been updated to 26.5 that continue to work fine; now reluctant to update as losing that convenience would be annoying. 🤨