TelephonyMessagingKit drops first SMS at cold launch — race between client XPC handler registration and server pending flush

The bug When a default carrier-messaging app is force-killed and a message arrives, iOS correctly:

If you haven't already, please file a bug on this and then post the bug number back here.

Anyone has found a workaround I haven't tried?

Maybe. Try calling "isConfiguredForCarrierMessaging" before you "touch" any of the service objects. If that still fails, then I'd use a task to briefly delay session creation a while after you called isConfiguredForCarrierMessaging.

There's actually infrastructure in place that's supposed to handle this issue. I'm not sure why it's failing, but my best guess is that this particular sequence means that the pending queue isn't set up properly. Calling isConfiguredForCarrierMessaging might give that infrastructure the head start it needs to avoid this issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin,

Thanks a lot for jumping on this — really appreciate it.

I tested the pattern you suggested in a fresh, isolated repro: read isConfiguredForCarrierMessaging first, then delay session creation via a Task.sleep before touching smsService.incomingMessageNotifications. I varied the delay across four values to be thorough.

Code shape (full source available, Swift, ~50 lines):

let session = TelephonyMessagingSession.shared
let configured = session.isConfiguredForCarrierMessaging          // PHASE 1
TMKLogger.shared.log("isConfiguredForCarrierMessaging=\(configured)")

Task.detached(priority: .userInitiated) {
    try? await Task.sleep(nanoseconds: kDelayMs * 1_000_000)      // PHASE 2
    let notifications = try session.smsService.incomingMessageNotifications  // PHASE 3
    for await notification in notifications {
        TMKLogger.shared.log("✅ SMS received: \(notification.message.content.body)")
    }
}

Test protocol on each delay:

1. Settings → Apps → Default Messaging → TMKTest
2. Force-kill the app
3. Send two SMS in rapid succession from another phone
4. Wait 30 s without touching the phone
5. Open TMKTest, read the persistent log

iPhone 14 Plus, iOS 26.4.2, SFR France (IMS-routed SIP).

Empirical results

The 1st SMS is dropped identically across all four runs. The 2nd SMS arrives normally. Pattern is rigorously identical regardless of delay length.

A relevant detail

In every test, isConfiguredForCarrierMessaging returns true synchronously before the delay starts (1–19 ms after didFinishLaunchingWithOptions, never failing). If reading that flag is what arms the pending-queue infrastructure you mentioned, that infrastructure should already be in place by the time the delay runs and Phase 3 fires. Yet the message is still flushed to a connection that doesn't have its handlers registered yet — the native CommCenter logs continue to show TMKXPCError Code=2 and Received unhandled request regardless of how long we wait before touching the service.

This suggests the race isn't between "infrastructure armed" and "service touched", but rather inside the XPC handshake itself: messageHandlersByID on the client XPCConnection is populated after Pinging remote end returns, and CommCenter starts flushing pending messages on Received new connection from PID — that ~2–7 ms gap is what we keep losing the 1st message in. Delaying anything before smsService access doesn't move the XPC handshake — it just delays it later.

Question

In the runtime introspection I did earlier on the framework binary, I found a TelephonyMessagingKit.Messaging.Server type (mangled _$s21TelephonyMessagingKit0B0O6ServerC) with what appears to be a synchronous callback method setIncomingMessageHandler<A: Message>(@Sendable (XPCPeerMessage<A>) throws -> ()). A synchronous handler installed at session creation would sidestep the for await race entirely.

Is that an internal-only API for now, or is there any chance it's being considered for @_spi exposure to carrier-messaging-entitled apps in a future iOS 26.x point release? If not, would you have any other client-side angle to try, or is the right path here to wait for a server-side fix in CommCenter (option 1 in my original post: defer flushing until the client confirms handler registration)?

Thanks again for taking the time on this — happy to share the full TMKTest_Workaround repro project (xcodegen + 4 Swift files) if useful.

Best,

SO, before I talk about any details, the most critical thing here is that you must get a bug filed on this. See the end of this post for the details of exactly what I need in that bug report.

I'm happy to try and look for some kind of workaround, but the ultimate solution is a fix on our side. One thing to understand here is that the reason I'm asking you to file a bug isn't simply to note the problem but is actually to document the developer impact, which is one of the main factors we use to prioritize our work.

Yet the message is still flushed to a connection that doesn't have its handlers registered yet — the native CommCenter logs continue to show TMKXPCError Code=2 and Received unhandled request regardless of how long we wait before touching the service.

SO, one thing to clarify here is that CommCenter isn't acting "spontaneously". What's actually happening in the sequence above is that CommCenter was told to "flush its messages", which is what it then "did". This message here:

T+0.130  App(TMK): Received unhandled request                                       ← client not ready

...happens because the message router inside TMK didn't have a message handler in place for SMS messages. This message here:

T+0.132  App(TMK): Registered for IncomingMessageNotification (smsReceived)         ← ~2 ms too late

...is actually happening when THE handler is registered. In other words, the problem here is that TMK told CommCenter to flush before it was fully configured, NOT that CommCenter flushed too soon.

Similarly, this error:

T+0.131  CommCenter(TMK): Failed to send pending message: TMKXPCError Code=2

...is actually an error that TMK returned to CommCenter, NOT an error CommCenter itself generated.

That then leads to here:

In every test, isConfiguredForCarrierMessaging returns true synchronously before the delay starts (1–19 ms after didFinishLaunchingWithOptions, never failing).

The object that actually manages the XPC connection is a private object which is lazily initialized on access, so my hope was that kicking that initialization off earlier might mean that the pending message queue was in place before SMS delivery started.

I'm not sure exactly why it didn't work, but it's probably tied to the exact ordering of the initialization process across multiple threads. That leads me to my next step, which is to:

• Set up your test project so that you're logging between every single call into TMK and make sure the logging is going to the system console.

• Install the "Phone (General)" profile on your test device.

• Reproduce the issue a few times on your test device. For each test, note the time you started and finished the test and then wait a few minutes between each test. (The goal here is to make sure there is a significant time gap between each test, so that the activity of one test doesn't overlap with the next test.)

• Collect the sysdiagnose using the instructions found in the profile instructions.

• Upload the sysdiagnose, your test code (so I can see exactly what and where you're logging), and the time log to a bug report, then post the bug number back here.

The sysdiagnose will let me see exactly how the event ordering and threading is happening, which is the best shot at a workaround.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware