Environment: iOS 26.5, Message Filter app extension (IdentityLookup framework), offline filtering. Setup My Message Filter Extension performs offline string matching on the message body and returns one of: ILMessageFilterAction.allow / .junk / .transaction / .promotion In the Messages app the filtering UI shows these folders: Messages (the main/default folder), Transactions, Promotions, Junk. .allow is expected to surface a message in the main Messages folder. The documented behavior (API docs + WWDC22 "Explore SMS message filters") only describes a static mapping from action → folder. On iOS 26.5 I'm seeing what looks like a stateful, per-sender behavior that I cannot find documented anywhere, and I can't tell whether it is intended or a bug. Test methodology All messages in every sequence are sent from the same single phone number. Before each Case, I fully clear the receive history for that number, so every sequence starts from a clean slate with no prior state for that sender. The notation shows how many conversations/entries appear in each folder after each step. Case A — first message = allow allow → Messages: 1 promotion → Messages: 2 (allow + promotion), Promotions: 1 junk → everything collapses into Junk; Messages & Promotions become empty every subsequent message lands in Junk regardless of the action I return Case B — first message = allow, then transaction allow → Messages: 1 transaction → Messages: 2 (allow + transaction), Transactions: 1 junk → everything collapses into Junk; Messages & Transactions empty every subsequent message lands in Junk regardless of returned action Case C — first message = transaction transaction → Messages: 1, Transactions: 1 ← also appears in Messages allow → Messages: 2, Transactions: 1 promotion → Messages: 3, Transactions: 1, Promotions: 1 junk → Messages: 4, Transactions: 1, Promotions: 1, Junk: 1 (NOTE: here junk does NOT collapse the thread, and there is no "sticky junk") Case D — first message = promotion promotion → Promotions: 1 only (does NOT appear in Messages) allow → Messages: 2 (the earlier promotion now also appears in Messages), Promotions: 1 junk → everything collapses into Junk (sticky, same as Case A/B) every subsequent message lands in Junk regardless of returned action My core question: are the following two behaviors by design, or are they bugs? (1) "Sticky junk" after allow-first / promotion-first. In Cases A, B and D, once .junk is returned the whole sender thread collapses into Junk, and from then on every message is forced into Junk regardless of the action my extension returns. Is this expected/by-design, or a bug? If by design: is it permanent, and what resets it — does the extension have any control, or is it purely user-driven (e.g. the user moving the thread out of Junk)? What concerns me is that the system appears to ignore my returned action entirely once this state is entered. (2) .transaction-first behaving differently from .allow-first. A sender whose first message is .transaction (Case C) behaves differently: the message also appears in the main Messages folder, and a later .junk does not collapse the thread (no sticky junk). Is this .transaction-first behavior expected/by-design, or a bug? If by design, what is the underlying rule that makes .transaction-first confer this state while .allow-first does not? Since the history is cleared before each test, this is determined purely by the first action returned. Additional clarifying questions Is any of this per-sender state behavior documented beyond the static action → folder mapping in the API docs / WWDC22 "Explore SMS message filters"? If so, where? More generally, what determines whether a categorized (.transaction / .promotion) message is also mirrored into the main Messages folder? Thanks — I'd like my extension's return values to produce predictable categorization for users, and right now this first-message-dependent behavior makes that hard to reason about.

Hi! Sms reporting is no longer available in iOS beta 26 builds. I can set my app as the SMS/Call Reporting Extensions but the report button is missing for sms messages in the messages app. Xcode 26 beta 7 build the app without errors. This is a breaking change. Same extension was previously broken for calls but has been fixed in beta 7 build, as reported here. It is however still missing for sms messages in the messages app (beta 9 build).

I just updated my testing device OS to iOS 26.5 and was trying to validate if our sdk is working fine or not and we found Call blocking is not at working for this update. I already seen some of the post regarding call blocking will not work if call to the expected block number is initiated from testing device. So just to clarify that is not the case in our findings.

Hi everyone, I'm hoping to hear from developers who have submitted Live Caller ID Lookup entitlement requests, especially anyone successfully onboarded after the PIR architecture became required. My own request (ID 2C4HJDWYJ6, submitted March 23, 2026) has been under review for 85 days. Apple Developer Support confirmed on May 8 that it's "in the pipeline to be onboarded" but I haven't received a concrete timeline. Infrastructure is fully deployed and verified per Apple's PIR documentation: OHTTP Gateway: https://gateway.zinfo.ge PIR Service: https://service.zinfo.ge (Apple's Swift PIR Service) Token Issuer: https://issuer.zinfo.ge DNS TXT record correctly configured HTTP/2, TLS, Protocol Buffers wire format Production database loaded Questions for the community: For developers already onboarded, how long did your review take from final submission to approval? Did the Live Caller ID Lookup capability appear automatically in Certificates, Identifiers & Profiles after approval, or was there an additional step? Is there an Apple engineering contact who handles PIR onboarding questions directly, separate from Developer Support? Any guidance from those who have been through this process, or from Apple DevRel, would be appreciated. Thanks, Levan

Hello, I am hoping someone from Apple or the community can help escalate or advise on my situation. I submitted a Live Caller ID Lookup entitlement request for my app Zinfo (com.parastashvili.Mobile), Team ID: CNH4KYRW44. A support case was opened on February 17, 2026 (Case ID: 102823550184). Apple's documentation states entitlement review takes up to 2 weeks. It has now been over 3 weeks with no substantive response despite multiple follow-ups. Timeline: Feb 17: Case opened Feb 26: I provided all requested technical details in full — OHTTP endpoints, Privacy Pass token system, DNS TXT record, Apple test number (+1 408 555 1212 returning "Johnny Appleseed"), all fully deployed and ready for validation Feb 27: Apple replied with a generic "appropriate team will be in contact" message Feb 28, Mar 6, Mar 10: Follow-up emails sent — no meaningful response All technical requirements are fully implemented and operational. We are ready for Apple's validation at any time. Has anyone else experienced long delays with Live Caller ID Lookup entitlement reviews? Is there a better escalation path? I have also submitted a new escalation ticket (Case ID: 102840874265) under Development and Technical > Entitlements today. Any advice or visibility from Apple staff would be greatly appreciated. App: Zinfo (com.parastashvili.Mobile) Extension Bundle ID: com.parastashvili.Mobile.LiveCallerID Team ID: CNH4KYRW44

We’re building an iOS app that uses an ILMessageFilterExtension to classify unwanted property-related SMS messages. Our goal is for filtered/junk messages to trigger an automatic scan/classification flow so the main app can show the user useful stats like “X messages blocked since your last check-in,” and ideally categorize them by type such as likely wholesaler, investor, realtor, scam, or unclear. The bottleneck we’re running into is understanding the correct architecture and limits of the Message Filter Extension. We know the extension can inspect sender/message content and return allow/junk, and we understand that network requests are limited to Apple’s deferred query flow. What we’re trying to clarify is whether there is an Apple-compliant way for the extension to persist lightweight scan results or aggregate counts that the containing app can later read, without violating privacy or extension restrictions. We do not need to export a full copy of message bodies into the app; what we want is a compliant way to keep counters/summary metadata such as blocked count, blocked since last app open, and maybe category counts. Questions we’re trying to answer: Is it acceptable for an ILMessageFilterExtension to persist aggregate scan stats for later display in the main app? If so, what is the recommended storage pattern for lightweight counters/metadata? Can extension-side classification results be surfaced to the app only as summary data, not raw message content? If using deferred network classification, what is the best way to reflect those results back into user-facing counts like “messages blocked since last check-in”? Our desired user experience is: unwanted message hits the filter filter classifies it locally or via deferred server lookup message is junked if appropriate aggregate counters are updated when the user opens the app, they see something like: 12 messages blocked since your last check-in 8 likely wholesalers 3 scams 1 unclear We’re mainly looking for guidance on the correct Apple-supported architecture here, especially around what data can be retained/shared between the extension and the containing app.

Hi, I have some scenario in which I need to reportIncoming to CallKit with same UUID 2 times. So I just need to know that, it will cause an issue of CallKit or with application.

I'm trying to implement Unwanted SMS and Calls reporting in an app I'm doing in my idle time. If I place a UITextField or UITextView inside a ILClassificationUIExtensionViewController, every time I select on such control the extension crashes without any logs. The closet idea I have on why it crashes it has something to do with iOS requesting the dictation feature. I'm using the latest (beta 8 at the time) iOS 16.0 beta on my iPhone 13 pro. Attaching my code here if you want to try for yourself: github

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?

We’ve been implementing LiveCallerId using OHTTP and have hit a wall with the production environment. The setup works perfectly in TestFlight, but the release version of the app is consistently being rejected by the Apple OHTTP Relay when trying to tunnel traffic to our gateway. Timeline & Status: Applied via the form in September 2025. Received confirmation in November 2025 that our /.well-known/ohttp-keys endpoint was correctly configured. Since then, we've struggled to get a dialogue with Apple to confirm the final production whitelisting. Technical Observations: Our ohttp-keys endpoint is being polled frequently (every few minutes). Based on the traffic, this is clearly the Apple Relay infrastructure fetching/refreshing the keys, not the devices themselves. This suggests the Relay "sees" our configuration, yet it still refuses to tunnel traffic to our gateway in the production environment. Since everything is functional in TestFlight, our implementation seems correct. It feels like there is a configuration mismatch or a missing "production flip" on the Relay side for our Bundle ID. If anyone from the Apple engineering team could verify the status for this Bundle ID, it would be a huge help. We've been stuck in this "TestFlight-only" state for quite a while now.

Hi! We’ve had Live Caller ID Lookup in production for a while. We’re seeing backend RPS on our /queries endpoint much higher than our expected incoming call volume. While testing with Console.app during an incoming call, it looks like iOS may still hit our service even when the caller number is already in the user’s Contacts - but I’m not 100% sure from logs alone. Can you confirm: Does iOS invoke Live Caller ID Lookup (i.e. call /queries) for every incoming call, including calls from saved Contacts? If yes, is this simply expected framework behavior? Thanks!

Hi, I have a big suggestion for the next update! My suggestion is to upgrade the call filtering system : - “Block suspicious calls” It automatically block numbers that are likely to be unwanted or spam. These calls should not ring, should not appear in the call history, and should be silently discarded. - “Block unknown callers/hidden numbers” Instead of receiving a call from a hidden or unknown caller and seeing it appear in the missed calls list, the call should be completely blocked and not recorded at all, no notification, no sight of call. - “Filter numbers that are not from contacts” If the same unknown number calls too frequently within a week and the user never answers (for example 10 times per day, or 5 times per day if considered suspicious or too much spam in a little time), the iPhone should automatically block this number. The device would display a message such as: “This number has called too many times and has been automatically blocked for 3 day(or 1 week).” The block could also apply to the entire IP range or source associated with the unknown caller. It is very helpful for most of unwanted calls.

Do we need to take approval for any entitlement for the extension Unwanted Communication because currently I do not see my app in the Settings under SMS/Call Reporting extensions.

Currently, I have implemented Unwanted Communication Extension, But I wanted to send the reported call or message to my backed server. How can I achieve this and can I send message body to the server ?

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.

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.

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.

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.

Hi everyone, I am building an SMS filtering app using the IdentityLookup framework. My main application handles the user login and receives a JWT. I need my ILMessageFilterExtension to use this JWT to authenticate its backend requests via context.deferQueryRequestToNetwork. Since the extension is sandboxed and doesn't share a URLSession or standard Keychain with the main app, I am trying to use the Shared Web Credentials mechanism as suggested in the documentation. My Questions: Is SecAddSharedWebCredential still the recommended way to "bridge" a token from the main app to the messagefilter service in 2026? If the backend returns a 401 Unauthorized with a WWW-Authenticate: Basic realm="api.mydomain.com" header, will iOS automatically retry the request with the stored token? Are there any specific AASA (Apple App Site Association) requirements for the messagefilter key? Does it need to be a separate top-level object or nested? Current Setup: Entitlements: Both Main App and Extension have messagefilter:api.mydomain.com and webcredentials:api.mydomain.com. Main App Code: Swift SecAddSharedWebCredential("api.mydomain.com" as CFString, "UserAccount" as CFString, "my_jwt_token" as CFString) { error in // Returns nil (success) } AASA File: JSON { "messagefilter": { "apps": ["TEAMID.bundle.id"] } } Despite this, I see the first 401 in my server logs, but the automatic retry with the Authorization header never happens. Has anyone successfully implemented this "silent" handshake recently?

I am trying to set up a message filter extension that will use shared web credentials for basic auth when calling to its ILMessageFilterExtensionNetworkURL. I have associated domains set up for both "messagefilter:" and "webcredentials:" and the message filter IS correctly calling the ILMessageFilterExtensionNetworkURL with each message - so that part is working. As detailed here, I have set up Shared Web Credentials and my view controller is using SecAddSharedWebCredential() to save the creds to the correct domain. Using Authorization services, the creds are auto-filled into my app's login screen. When I go under Settings > Passwords, I see the creds are saved and they are the correct creds to the corrent website that matches ILMessageFilterExtensionNetworkURL. Regardless of all of this, the deferQueryRequestToNetwork() refuses to use the creds and implement Basic Auth in its URL call. It makes the call to the correct URL, it just won't use the Shared Web Creds for basic auth. Any help would be greatly appreciated.