Messages

RSS for tag

Create app extensions that lets users send text, stickers, media files, and interactive messages using Messages.

Posts under Messages tag

27 Posts

Post

Replies

Boosts

Views

Activity

Message Filter Extension Not Working on iOS 26.1
Hello, We are using a Message Filter Extension (ILMessageFilterExtension) to classify SMS/iMessage content (junk vs allow) in our app. After testing on iOS 26.1, we want to confirm whether there are any behavioral, performance, or API-level changes that impact message filtering, such as: Changes in how often the filter extension is invoked Differences in classification accuracy or system overrides New privacy, entitlement, or permission-related restrictions Execution time limits or memory constraints Any changes specific to iMessage vs SMS filtering We did not find any explicit mention of Message Filter Extensions in the iOS 26.1 release notes and would like to confirm whether the existing behavior from previous iOS versions remains unchanged. Has Apple introduced any known or undocumented changes in iOS 26.1 that developers should be aware of when supporting Message Filter Extensions? Sometime I also found unpredictable behaviour on iOS version 18.5 or below, like sometime it works but sometimes starts working. Thanks in advance for any guidance.
3
0
451
Feb ’26
Document Type Export / Import in Xcode - Shared via Messages
I’ve created a document type for my app and set it up in the Info Configuration in Xcode. This all works as expected: Implemented with the Transferrable API and ShareLink, I can share an app’s file via the Files app or Notes and then import the file via a Share extension and the fileImport swiftUI api. My question is regarding Messages, specifically. It appears as a ShareLink option and I’m able to send my app’s document type via a message, but I’m unable to open it or share it (internally, with my app), other than being able to forward or delete it. If I copy the file, I can’t access it within my app (it’s still stored in the Messages private bundle) and startAccessingSecurityScopedResource returns false as expected. The message does detect the right icon, so it’s recognizing the custom document type. If my Share Extension, exported document type, and transferable implementation is configured correctly, should I be able to open a file for my app shared via Messages? Is this an allowed action? I get various answers from AI, and I can’t test this in the Simulator on pre-26 devices.
1
0
270
Feb ’26
iMessage Extension: didSelect not called when tapping message bubbles on iPad
I'm developing a turn-based Messages game extension and experiencing a persistent issue on iPad where tapping on message bubbles does not reliably trigger lifecycle callbacks after the extension has been used once. The Problem: On iPad, after a player: Opens the extension by tapping a game message Takes their turn (plays a card) Sends the updated game state as a new message Extension collapses When the opponent sends their response and the player taps on the new message bubble, the extension often does not open. The didSelect(_:conversation:) method is not called. The user must refresh the conversation by scrolling away and back or reopening the Messages App before tapping works again. This works perfectly on iPhone - every tap on a message bubble reliably triggers didSelect and opens the extension. What I've Tried: I've implemented every lifecycle method and workaround I could find: swiftoverride func willBecomeActive(with conversation: MSConversation) { super.willBecomeActive(with: conversation) if let message = conversation.selectedMessage, let url = message.url { loadGameState(from: url, message: message, conversation: conversation) } } override func didBecomeActive(with conversation: MSConversation) { super.didBecomeActive(with: conversation) if let message = conversation.selectedMessage, let url = message.url { loadGameState(from: url, message: message, conversation: conversation) } } override func didSelect(_ message: MSMessage, conversation: MSConversation) { // This is NOT called on iPad when tapping message bubbles guard let url = message.url else { return } loadGameState(from: url, message: message, conversation: conversation) } override func didReceive(_ message: MSMessage, conversation: MSConversation) { guard let url = message.url else { return } loadGameState(from: url, message: message, conversation: conversation) } override func didTransition(to presentationStyle: MSMessagesAppPresentationStyle) { super.didTransition(to: presentationStyle) // Attempted to reload here as well } I also tried: Observing NSExtensionHostDidBecomeActive and NSExtensionHostWillEnterForeground notifications Forcing UI refresh in viewDidLayoutSubviews Checking conversation.selectedMessage in every lifecycle method Research: I found several Developer Forums threads from 2016 describing this exact issue: Thread 53167: "MSMessagesAppViewController.didSelect not called on message reselect" Thread 60323: "willSelectMessage and didSelectMessage don't fire" An Apple staff member confirmed that didSelect only fires when selecting a different message, similar to UITableView selection behavior. However, on iPad, it seems like messages remain "selected" even after the extension collapses, so tapping a new message doesn't register as a new selection. Questions: Is there a recommended way to detect when a user taps a message bubble on iPad, even if iOS considers a message "already selected"? Is there a way to programmatically deselect the current message (similar to UITableView.deselectRow) so that subsequent taps trigger didSelect? Are there any iPad-specific lifecycle methods or notifications I should be observing? Is this a known limitation of the Messages framework on iPad? Environment: Xcode 16 iOS 18 and 26 Testing on iPad Pro (M4) and iPad Air iPhone works correctly on all tested devices Any guidance would be greatly appreciated. This is blocking our App Store submission as reviewers are flagging the iPad behavior as incomplete functionality.
2
0
120
Feb ’26
Unwanted Communication Reporting Extension deletes messages always
I am implementing an Unwanted Communication Reporting Extension (IdentityLookupUI) to allow users to report spam messages to our backend. The extension works perfectly in terms of data collection and network reporting (using ILClassificationExtensionNetworkReportDestination). However, I’ve encountered an issue with the message lifecycle: whenever the user taps "Done" and I return a response, the system automatically moves the reported message to the Recently Deleted folder. I want to report the data but keep the message in its current folder (especially when the user classifies it as "Safe"). I have tried varying the ILClassificationAction, but it seems the system ignores the action in favor of "cleaning up" the thread. Example of my current implementation: override func classificationResponse(for request: ILClassificationRequest) -> ILClassificationResponse { // Even when returning .none or .reportNotJunk let action: ILClassificationAction = (self.type == "spam") ? .reportJunk : .none let response = ILClassificationResponse(action: action) response.userInfo = ["type": self.taggedType, "sender": self.sender] return response } My Questions: Is there a specific ILClassificationAction or userInfo key that tells iOS not to move the message? Is this movement a mandatory "post-report cleanup" behavior of the IdentityLookup framework that cannot be overridden? Does anyone know a workaround to report the communication while maintaining its original location in the Messages app?
0
0
76
Mar ’26
iMessage login loop after Tahoe 26.5 beta update
iMessage Authentication Loop on macOS Tahoe 26.5 Beta Issue Description: iMessage is stuck in a persistent login/authentication loop after updating to macOS Tahoe 26.5 Beta. The app repeatedly prompts for Apple ID and password. After entering credentials, it briefly attempts to sign in before returning to the login prompt or showing an "unknown error." This issue is isolated to the MacBook Air (M3); iMessage continues to work correctly on iPhone, iPad, and Mac mini. Related Forum Thread: Several other users are reporting identical symptoms here: https://discussions.apple.com/thread/256256620 Troubleshooting Steps Taken (All Failed): Standard Maintenance: Restarted Messages app, rebooted the MacBook Air, and verified Date/Time settings. Credential Management: Changed Apple ID password and attempted sign-in with new credentials. Manual Keychain Cleanup: Attempted to delete iMessage and com.apple.idms entries via Keychain Access UI (entries were persistent and could not be deleted). Terminal-Based Force Deletion: Executed the following commands to target specific registration tokens: security delete-generic-password -s "com.apple.facetime: registrationV1" security delete-generic-password -s "com.apple.imessage: registrationV1" Cache & Identity Purge: Cleared local authentication state and app caches: rm -rf ~/Library/IdentityServices/* rm -rf ~/Library/Caches/com.apple.Messages rm -rf ~/Library/Caches/com.apple.imessage Full Keychain Reset ("Nuclear Option"): Renamed the Keychains folder to force macOS to create a brand-new database: mv ~/Library/Keychains ~/Library/Keychains-old Followed by an immediate system restart. Current Status: Despite a completely fresh Keychain and cleared caches, the "unknown error" and login loop persist, suggesting a regression in the authentication subsystem of build 26.5.
1
0
499
Apr ’26
TelephonyMessagingKit drops first SMS at cold launch — race between client XPC handler registration and server pending flush
Hi all, I'm the developer of OV Message, an end-to-end encrypted SMS messaging app already shipped on Google Play (Android, where it natively encrypts SMS content). The iOS port aims to be the default carrier-messaging app, handling SMS, MMS, and RCS through TelephonyMessagingKit with the com.apple.developer.carrier-messaging-app entitlement under the EU programme. While testing the cold-launch flow on iOS 26.x, I've hit a reproducible bug that silently drops the first SMS/MMS/RCS that wakes the app, and I'd like to confirm whether other devs working with this API see the same. The bug When a default carrier-messaging app is force-killed and a message arrives, iOS correctly: Routes the message via CommCenter (IMS in my case — SFR France) Wakes the app in background (state = .background at didFinishLaunchingWithOptions) Acquires a TelephonyMessaging runningboard assertion on the app But CommCenter then pushes the pending message via XPC before the client TMK library has finished registering its messageHandlersByID dictionary. Result: client responds Received unhandled request, server logs TMKXPCError Code=2, message is dropped, never delivered to for await in incomingMessageNotifications. Subsequent messages (with the app warm) work fine. Native log sequence (from idevicesyslog with the Telephony logging profile) T+0.000 CommCenter: SMS arrives via IMS (k3GPP) T+0.003 CommCenter: Default app is set to com.example.app T+0.004 CommCenter: Attempting to launch and acquire process assertion T+0.083 CommCenter: Notifying SMS message received, target: bundleID=... T+0.085 CommCenter(TMK): There are no client connections matching, pending message [~125 ms — app boots] T+0.128 App(TMK): Configuring connection T+0.128 App(TMK): Pinging remote end T+0.130 CommCenter(TMK): Received new connection from PID T+0.130 CommCenter(TMK): New incoming connection, flushing pending messages (1) ← server flushes T+0.130 App(TMK): Received unhandled request ← client not ready T+0.131 CommCenter(TMK): Failed to send pending message: TMKXPCError Code=2 T+0.132 App(TMK): Registered for IncomingMessageNotification (smsReceived) ← ~2 ms too late The race window between Pinging remote end (client) and Registered for IncomingMessageNotification (client) is 2–7 ms across my measurements. CommCenter considers the connection ready as soon as the ping completes, but the client library populates messageHandlersByID slightly after, so the dispatch fails. Minimal reproduction I built a ~50-line Swift app to confirm this isn't specific to OV Message. UIKit AppDelegate, single for await in TelephonyMessagingSession.shared.smsService.incomingMessageNotifications started in didFinishLaunchingWithOptions. No SwiftUI, no other modules, no Darwin notifications. Just TMK. Steps: Build & install on iPhone iOS 26.x with carrier-messaging-app entitlement (auto-provisioned in iOS 26) Settings → Apps → Default Messaging → select the test app Force-kill, then send 2 SMS in rapid succession from another phone Wait 30 s, open the app — log shows only the 2nd SMS Same result: the 1st SMS is gone. I've reproduced this consistently dozens of times. Source code (Swift + xcodegen project.yml): https://gist.github.com/ovmessage/fbc529292a65222191bec6ce5e5a4275 What I've tried Task.detached(priority: .userInitiated) to decouple the for await from main thread scheduling — no effect (race is internal to TMK lib, before our scheduling) Pre-fetching cellularServices synchronously — no effect Subscribing MMS + RCS in parallel — no effect Direct XPCSession/xpc_connection_create_mach_service to com.apple.commcenter.tmk.xpc — Apple has marked these unavailable on iOS for 3rd-party apps (no public way to bypass the lib) I've also done runtime introspection of the TMK framework via Mirror, which confirms the architecture: a single XPCConnection.messageHandlersByID dict shared by smsReceived, mmsReceived, rcsReceivedNotification — all four entries (incl. serviceStatusNotification) are populated after the XPC ping. So the same race affects SMS, MMS, and RCS equally. Suggested fixes (Apple-side) Either: Server (CommCenter): defer flushing pending messages until the client confirms its handlers are registered (extra XPC handshake message) Client (TelephonyMessagingKit): register messageHandlersByID entries before sending Pinging remote end, so they exist when the server starts flushing Buffer client-side: cache messages received before handler registration completes, dispatch on attach Filed in Feedback Assistant FB[YOUR_FB_NUMBER_HERE] Question for fellow devs If you're also building with carrier-messaging-app entitlement (Beeper, Google Messages on iOS, anyone in the EU programme), can you confirm whether you see the same race? Especially interested in whether: It happens with non-IMS carriers (mine is SFR France, IMS-routed via SIP) iOS 26.1 / 26.2 changed the timing Anyone has found a workaround I haven't tried Thanks.
3
0
332
May ’26
Sticker Pack App project not working
I started a fresh “Sticker Pack App” project, add one image to it and it wouldn’t show up on emulator or device. From what I remember, there shouldn't be any coding involved, just drag and drop images of the correct format and dimensions and it should work. I tried changing the file format, dimensions etc while consulting with web and AI assistant searches and but still didn’t work. Apple support also didn't reply with anything useful but to post in the forum. I'm guessing I'm missing something trivial where a lot of us here have encountered before. Appreciate your help here, thank you in advance!
4
0
121
May ’26
Message Filter Extension Not Working on iOS 26.1
Hello, We are using a Message Filter Extension (ILMessageFilterExtension) to classify SMS/iMessage content (junk vs allow) in our app. After testing on iOS 26.1, we want to confirm whether there are any behavioral, performance, or API-level changes that impact message filtering, such as: Changes in how often the filter extension is invoked Differences in classification accuracy or system overrides New privacy, entitlement, or permission-related restrictions Execution time limits or memory constraints Any changes specific to iMessage vs SMS filtering We did not find any explicit mention of Message Filter Extensions in the iOS 26.1 release notes and would like to confirm whether the existing behavior from previous iOS versions remains unchanged. Has Apple introduced any known or undocumented changes in iOS 26.1 that developers should be aware of when supporting Message Filter Extensions? Sometime I also found unpredictable behaviour on iOS version 18.5 or below, like sometime it works but sometimes starts working. Thanks in advance for any guidance.
Replies
3
Boosts
0
Views
451
Activity
Feb ’26
Document Type Export / Import in Xcode - Shared via Messages
I’ve created a document type for my app and set it up in the Info Configuration in Xcode. This all works as expected: Implemented with the Transferrable API and ShareLink, I can share an app’s file via the Files app or Notes and then import the file via a Share extension and the fileImport swiftUI api. My question is regarding Messages, specifically. It appears as a ShareLink option and I’m able to send my app’s document type via a message, but I’m unable to open it or share it (internally, with my app), other than being able to forward or delete it. If I copy the file, I can’t access it within my app (it’s still stored in the Messages private bundle) and startAccessingSecurityScopedResource returns false as expected. The message does detect the right icon, so it’s recognizing the custom document type. If my Share Extension, exported document type, and transferable implementation is configured correctly, should I be able to open a file for my app shared via Messages? Is this an allowed action? I get various answers from AI, and I can’t test this in the Simulator on pre-26 devices.
Replies
1
Boosts
0
Views
270
Activity
Feb ’26
iMessage Extension: didSelect not called when tapping message bubbles on iPad
I'm developing a turn-based Messages game extension and experiencing a persistent issue on iPad where tapping on message bubbles does not reliably trigger lifecycle callbacks after the extension has been used once. The Problem: On iPad, after a player: Opens the extension by tapping a game message Takes their turn (plays a card) Sends the updated game state as a new message Extension collapses When the opponent sends their response and the player taps on the new message bubble, the extension often does not open. The didSelect(_:conversation:) method is not called. The user must refresh the conversation by scrolling away and back or reopening the Messages App before tapping works again. This works perfectly on iPhone - every tap on a message bubble reliably triggers didSelect and opens the extension. What I've Tried: I've implemented every lifecycle method and workaround I could find: swiftoverride func willBecomeActive(with conversation: MSConversation) { super.willBecomeActive(with: conversation) if let message = conversation.selectedMessage, let url = message.url { loadGameState(from: url, message: message, conversation: conversation) } } override func didBecomeActive(with conversation: MSConversation) { super.didBecomeActive(with: conversation) if let message = conversation.selectedMessage, let url = message.url { loadGameState(from: url, message: message, conversation: conversation) } } override func didSelect(_ message: MSMessage, conversation: MSConversation) { // This is NOT called on iPad when tapping message bubbles guard let url = message.url else { return } loadGameState(from: url, message: message, conversation: conversation) } override func didReceive(_ message: MSMessage, conversation: MSConversation) { guard let url = message.url else { return } loadGameState(from: url, message: message, conversation: conversation) } override func didTransition(to presentationStyle: MSMessagesAppPresentationStyle) { super.didTransition(to: presentationStyle) // Attempted to reload here as well } I also tried: Observing NSExtensionHostDidBecomeActive and NSExtensionHostWillEnterForeground notifications Forcing UI refresh in viewDidLayoutSubviews Checking conversation.selectedMessage in every lifecycle method Research: I found several Developer Forums threads from 2016 describing this exact issue: Thread 53167: "MSMessagesAppViewController.didSelect not called on message reselect" Thread 60323: "willSelectMessage and didSelectMessage don't fire" An Apple staff member confirmed that didSelect only fires when selecting a different message, similar to UITableView selection behavior. However, on iPad, it seems like messages remain "selected" even after the extension collapses, so tapping a new message doesn't register as a new selection. Questions: Is there a recommended way to detect when a user taps a message bubble on iPad, even if iOS considers a message "already selected"? Is there a way to programmatically deselect the current message (similar to UITableView.deselectRow) so that subsequent taps trigger didSelect? Are there any iPad-specific lifecycle methods or notifications I should be observing? Is this a known limitation of the Messages framework on iPad? Environment: Xcode 16 iOS 18 and 26 Testing on iPad Pro (M4) and iPad Air iPhone works correctly on all tested devices Any guidance would be greatly appreciated. This is blocking our App Store submission as reviewers are flagging the iPad behavior as incomplete functionality.
Replies
2
Boosts
0
Views
120
Activity
Feb ’26
Unwanted Communication Reporting Extension deletes messages always
I am implementing an Unwanted Communication Reporting Extension (IdentityLookupUI) to allow users to report spam messages to our backend. The extension works perfectly in terms of data collection and network reporting (using ILClassificationExtensionNetworkReportDestination). However, I’ve encountered an issue with the message lifecycle: whenever the user taps "Done" and I return a response, the system automatically moves the reported message to the Recently Deleted folder. I want to report the data but keep the message in its current folder (especially when the user classifies it as "Safe"). I have tried varying the ILClassificationAction, but it seems the system ignores the action in favor of "cleaning up" the thread. Example of my current implementation: override func classificationResponse(for request: ILClassificationRequest) -> ILClassificationResponse { // Even when returning .none or .reportNotJunk let action: ILClassificationAction = (self.type == "spam") ? .reportJunk : .none let response = ILClassificationResponse(action: action) response.userInfo = ["type": self.taggedType, "sender": self.sender] return response } My Questions: Is there a specific ILClassificationAction or userInfo key that tells iOS not to move the message? Is this movement a mandatory "post-report cleanup" behavior of the IdentityLookup framework that cannot be overridden? Does anyone know a workaround to report the communication while maintaining its original location in the Messages app?
Replies
0
Boosts
0
Views
76
Activity
Mar ’26
iMessage login loop after Tahoe 26.5 beta update
iMessage Authentication Loop on macOS Tahoe 26.5 Beta Issue Description: iMessage is stuck in a persistent login/authentication loop after updating to macOS Tahoe 26.5 Beta. The app repeatedly prompts for Apple ID and password. After entering credentials, it briefly attempts to sign in before returning to the login prompt or showing an "unknown error." This issue is isolated to the MacBook Air (M3); iMessage continues to work correctly on iPhone, iPad, and Mac mini. Related Forum Thread: Several other users are reporting identical symptoms here: https://discussions.apple.com/thread/256256620 Troubleshooting Steps Taken (All Failed): Standard Maintenance: Restarted Messages app, rebooted the MacBook Air, and verified Date/Time settings. Credential Management: Changed Apple ID password and attempted sign-in with new credentials. Manual Keychain Cleanup: Attempted to delete iMessage and com.apple.idms entries via Keychain Access UI (entries were persistent and could not be deleted). Terminal-Based Force Deletion: Executed the following commands to target specific registration tokens: security delete-generic-password -s "com.apple.facetime: registrationV1" security delete-generic-password -s "com.apple.imessage: registrationV1" Cache & Identity Purge: Cleared local authentication state and app caches: rm -rf ~/Library/IdentityServices/* rm -rf ~/Library/Caches/com.apple.Messages rm -rf ~/Library/Caches/com.apple.imessage Full Keychain Reset ("Nuclear Option"): Renamed the Keychains folder to force macOS to create a brand-new database: mv ~/Library/Keychains ~/Library/Keychains-old Followed by an immediate system restart. Current Status: Despite a completely fresh Keychain and cleared caches, the "unknown error" and login loop persist, suggesting a regression in the authentication subsystem of build 26.5.
Replies
1
Boosts
0
Views
499
Activity
Apr ’26
TelephonyMessagingKit drops first SMS at cold launch — race between client XPC handler registration and server pending flush
Hi all, I'm the developer of OV Message, an end-to-end encrypted SMS messaging app already shipped on Google Play (Android, where it natively encrypts SMS content). The iOS port aims to be the default carrier-messaging app, handling SMS, MMS, and RCS through TelephonyMessagingKit with the com.apple.developer.carrier-messaging-app entitlement under the EU programme. While testing the cold-launch flow on iOS 26.x, I've hit a reproducible bug that silently drops the first SMS/MMS/RCS that wakes the app, and I'd like to confirm whether other devs working with this API see the same. The bug When a default carrier-messaging app is force-killed and a message arrives, iOS correctly: Routes the message via CommCenter (IMS in my case — SFR France) Wakes the app in background (state = .background at didFinishLaunchingWithOptions) Acquires a TelephonyMessaging runningboard assertion on the app But CommCenter then pushes the pending message via XPC before the client TMK library has finished registering its messageHandlersByID dictionary. Result: client responds Received unhandled request, server logs TMKXPCError Code=2, message is dropped, never delivered to for await in incomingMessageNotifications. Subsequent messages (with the app warm) work fine. Native log sequence (from idevicesyslog with the Telephony logging profile) T+0.000 CommCenter: SMS arrives via IMS (k3GPP) T+0.003 CommCenter: Default app is set to com.example.app T+0.004 CommCenter: Attempting to launch and acquire process assertion T+0.083 CommCenter: Notifying SMS message received, target: bundleID=... T+0.085 CommCenter(TMK): There are no client connections matching, pending message [~125 ms — app boots] T+0.128 App(TMK): Configuring connection T+0.128 App(TMK): Pinging remote end T+0.130 CommCenter(TMK): Received new connection from PID T+0.130 CommCenter(TMK): New incoming connection, flushing pending messages (1) ← server flushes T+0.130 App(TMK): Received unhandled request ← client not ready T+0.131 CommCenter(TMK): Failed to send pending message: TMKXPCError Code=2 T+0.132 App(TMK): Registered for IncomingMessageNotification (smsReceived) ← ~2 ms too late The race window between Pinging remote end (client) and Registered for IncomingMessageNotification (client) is 2–7 ms across my measurements. CommCenter considers the connection ready as soon as the ping completes, but the client library populates messageHandlersByID slightly after, so the dispatch fails. Minimal reproduction I built a ~50-line Swift app to confirm this isn't specific to OV Message. UIKit AppDelegate, single for await in TelephonyMessagingSession.shared.smsService.incomingMessageNotifications started in didFinishLaunchingWithOptions. No SwiftUI, no other modules, no Darwin notifications. Just TMK. Steps: Build & install on iPhone iOS 26.x with carrier-messaging-app entitlement (auto-provisioned in iOS 26) Settings → Apps → Default Messaging → select the test app Force-kill, then send 2 SMS in rapid succession from another phone Wait 30 s, open the app — log shows only the 2nd SMS Same result: the 1st SMS is gone. I've reproduced this consistently dozens of times. Source code (Swift + xcodegen project.yml): https://gist.github.com/ovmessage/fbc529292a65222191bec6ce5e5a4275 What I've tried Task.detached(priority: .userInitiated) to decouple the for await from main thread scheduling — no effect (race is internal to TMK lib, before our scheduling) Pre-fetching cellularServices synchronously — no effect Subscribing MMS + RCS in parallel — no effect Direct XPCSession/xpc_connection_create_mach_service to com.apple.commcenter.tmk.xpc — Apple has marked these unavailable on iOS for 3rd-party apps (no public way to bypass the lib) I've also done runtime introspection of the TMK framework via Mirror, which confirms the architecture: a single XPCConnection.messageHandlersByID dict shared by smsReceived, mmsReceived, rcsReceivedNotification — all four entries (incl. serviceStatusNotification) are populated after the XPC ping. So the same race affects SMS, MMS, and RCS equally. Suggested fixes (Apple-side) Either: Server (CommCenter): defer flushing pending messages until the client confirms its handlers are registered (extra XPC handshake message) Client (TelephonyMessagingKit): register messageHandlersByID entries before sending Pinging remote end, so they exist when the server starts flushing Buffer client-side: cache messages received before handler registration completes, dispatch on attach Filed in Feedback Assistant FB[YOUR_FB_NUMBER_HERE] Question for fellow devs If you're also building with carrier-messaging-app entitlement (Beeper, Google Messages on iOS, anyone in the EU programme), can you confirm whether you see the same race? Especially interested in whether: It happens with non-IMS carriers (mine is SFR France, IMS-routed via SIP) iOS 26.1 / 26.2 changed the timing Anyone has found a workaround I haven't tried Thanks.
Replies
3
Boosts
0
Views
332
Activity
May ’26
Sticker Pack App project not working
I started a fresh “Sticker Pack App” project, add one image to it and it wouldn’t show up on emulator or device. From what I remember, there shouldn't be any coding involved, just drag and drop images of the correct format and dimensions and it should work. I tried changing the file format, dimensions etc while consulting with web and AI assistant searches and but still didn’t work. Apple support also didn't reply with anything useful but to post in the forum. I'm guessing I'm missing something trivial where a lot of us here have encountered before. Appreciate your help here, thank you in advance!
Replies
4
Boosts
0
Views
121
Activity
May ’26