iOS Message Filter Extension - deferQueryRequestToNetwork(completion:) error I made a test app using the iOS App template and added a target using the Message Filter Extension template which invokes deferQueryRequestToNetwork(completion:) when receiving an SMS. The app and the extension have same "Associated Domains Capabilities" with "messagefilter" pointing to a server which receives query requests and returns proper responses. The extension has the "ILMessageFilterExtensionNetworkURL" key in Info.plist file which specifies the server URL. deferQueryRequestToNetwork(completion:) throws a com.apple.calls.messagefilter error which reads "Extension's containing app (appID ) unauthorized to defer requests to host "

Hi everyone, We are experiencing an issue with SMS messages sent from our banking app (iOS) to our customers. The SMS are being delivered by the carrier, but on iOS devices some of them appear to be filtered or blocked, and users don’t see them in the Messages app. This seems to be related to new SMS filtering rules on iOS (possibly affecting financial institutions and transactional SMS). • Has anyone faced a similar situation? • Are there specific Apple guidelines or best practices for SMS sender IDs / content to avoid being filtered? • Is there any official documentation from Apple regarding these new SMS filtering mechanisms? Any guidance or experiences would be greatly appreciated. Thanks in advance!

Hi, Since I updated my phone to 23A341, my Call filtering app is not blocking calls anymore. Same release checked on iOS 18 phone, it is working. I still see the callkit logs into the Console showing that numbers are loaded into the iOS-managed SQlite DB but the calls are not blocked nor identified. Anyone with the same issue? BR

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).

Hello. I've implemented the Live Caller ID Lookup feature in my app, but sometimes I get a weird error. When I call LiveCallerIDLookupManager.shared.refreshPIRParameters(...) from my app, it sometimes throws an error: Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSLocalizedDescription=Unable to query status due to errors: The resource could not be loaded because the App Transport Security policy requires the use of a secure connection., NSUnderlyingError=0x118f65740 {Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection., NSErrorFailingURLKey=http://www.example.com/config}}} What does this error mean? And where did the example.com part come from? What should I do to get rid of this error? My Service URL is hardcoded in the Live Caller ID Lookup Extension of my app and it is definitely not example.com.

Based on the documentation, I understand that the UnwantedCommunicationReporting extension works with SMS and MMS messages. However, I'd like official confirmation about support for different message types: SMS: Appears to be supported ✅ MMS: Appears to be supported ✅ RCS (Rich Communication Services): Support unclear ❓ iMessage: Support unclear ❓

Hi, On iOS 26 beta, calls can no longer be reported by swiping left on a call. This is unfortunately a breaking change. I have submitted a report on this on June with Feedback Assistant: FB17893517 I hope it will get some more exposure by posting here.

Hi Team, We are currently working on phone number lookup functionality for iOS 18 and have a few queries: When the extension sends a request to our backend server using the PIR encryption process, is the user's phone number visible to our server?

Hello, I'm working on implementing Live Caller ID Lookup, but I noticed that https://github.com/apple/live-caller-id-lookup-example redirects to https://github.com/apple/pir-service-example. Could you please clarify why this redirection occurs?

如下图所示，在iOS18以上，这个识别话术为“xx主叫号码”，这个如何修改？ 附：iOS18以下话术就很合理

I'm currently finding it impossible to get a text filtering extension to be invoked when there's an incoming text message. There isn't a problem with the app/extension because this is the same app and code that is already developed, tested, and unchanged since I last observed it working. I know if there's any history of the incoming number being "known" then the extension won't get invoked, and I used to find this no hindrance to testing previously provided that: the incoming number isn't in contacts there's no outgoing messages to that number there's no outgoing phone calls to the number. This always used to work in the past, but not anymore. However, I've ensured the incoming text's number isn't in contacts, in fact I've deleted all the contacts. I've deleted the entire phone history, incoming and outgoing, and I've also searched in messages and made sure there's no interactions with that number. There's logging in the extension so I can see its being invoked when turned on from the settings app, but its not getting invoked when there's a message. The one difference between now and when I used to have no problem with this - the phone now has iOS 18.5 on it. Its as if in iOS 18.5 there ever was any past association with a text number, its not impossible to remove that association. Has there been some known change in 18.5 that would affect this call filtering behavior and not being able to rid of the incoming message caller as being "known" to the phone? Update I completely reset the phone and then I was able to see the the message filter extension being invoked. That's not an ideal situation though. What else needs to be done beyond what I mentioned above in order to get a phone to forget about a message's number and thus get an message filtering extension to be invoked when there's a message from that number?

Hello I'm working on Live Caller ID Lookup implementation on my own pet-project, as I understood I need to create app and extension for this app. I also created test PIR-service. I did configure serviceURL, tokenIssuerURL and userTierToken. In My app I implemented following code Task { if LiveCallerIDLookupManager.shared.status(forExtensionWithIdentifier: "some-extension") == .disabled { `//` Show an alert. print("LiveCallerIDLookupManager is disabled") } do { // Open Settings. try await LiveCallerIDLookupManager.shared.openSettings() } catch { } It does open Call settings, but I don't understand what should I do next.

Hi Apple engineering team, I’m trying to integrate the new Live Caller ID Lookup (PIR) on iOS using your pir-service-example code as well as a custom mock server in Vapor, but the extension never advances past the /issue/token-key-for-user-token step. I’ve tried both: 1. Official Example Cloned https://github.com/apple/pir-service-example Ran PIRService locally Confirmed that GET /.well-known/private-token-issuer-directory → 200 GET /issue/token-key-for-user-token → 200 (DER bytes, correct SPKI) No POST /issue ever fires 2. Mock Server (Vapor) Implemented all five endpoints (/config, /.well-known/private-token-issuer-directory, /issue/token-key-for-user-token, /issue, /queries) Verified with curl and openssl asn1parse that: GET /.well-known/private-token-issuer-directory Content-Type: application/private-token-issuer-directory { "issuer-request-uri":"https://…/issue", "token-keys":[…] } GET /issue/token-key-for-user-token Content-Type: application/octet-stream <DER bytes> Added Cache-Control: public, max-age=3600 on directory and SPKI Stubbed POST /issue to always return { "token": "" } Still no POST /issue request from the extension Reproduction Steps Install and enable a Live Lookup extension pointing to my server. Trigger an incoming call on device. Watch server logs—only see the two GETs, never /issue or /queries. Expected Behavior After fetching the SPKI DER, the framework should issue a POST /issue call (Privacy Pass flow) and then POST /queries. Observed Behavior Stuck in an infinite loop of: GET /.well-known/private-token-issuer-directory GET /issue/token-key-for-user-token (repeat…) No progression to the /issue or /queries endpoints. What I’ve Tried Verified JSON kebab-case and headers exactly match examples Confirmed SPKI DER is valid via openssl asn1parse Added Cache-Control headers Tested on real device, localhost url, and ngrok public URL Mocked a valid-looking token response Could you advise what additional requirement or format detail I’m missing that prevents from advancing past /issue/token-key-for-user-token? These are the main files: LiveLookupExtension.swift routes.swift service-config.json Thanks in advance!

Hello, After submitting onboarding form for Live Caller ID Lookup feature, we received rejection response that our OHTTP gateway doesn't support HTTP/2. We have run provided command openssl s_client -alpn h2 -connect with our domain several times from different machines and environments, and our results consistently confirm that HTTP/2 is indeed supported by our OHTTP gateway. The output clearly shows ALPN protocol: h2, indicating successful HTTP/2 negotiation. Here is the log chunk from the command-line response: No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 4393 bytes and written 406 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 Server public key is 2048 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE ALPN protocol: h2 Early data was not sent Verify return code: 0 (ok) --- DONE We have also tried different 3rd-party services to check the HTTP/2 support and they also confirmed that HTTP/2 is supported. Is it possible to provide additional details on the specific criteria or test conditions that led to its non-approval? I'm happy to provide any further diagnostic information or engage in more detailed technical discussion.

A message filter extension is only forwarded SMSs by the OS for filtering, iMessages aren't. But what is the situation with RCS messages? Will they be filterable by a message filtering extension?

My iOS app uses a Message Filter extension (via ILMessageFilterQueryHandling) and works only when run directly as the extension target. When installed normally (via TestFlight), the filter does not trigger at all — which I now believe is because iOS enforces the com.apple.developer.identitylookup entitlement at runtime. Anyone know anything about this? I put in a request for the entitlement last week but heard nothing back. Called Apple "technical" support and they had no idea what I was talking about. The documentation around this is EXTREMELY lacking in my opinion...

Hi Apple Developer, I’m working on a message-filtering application and reviewing Apple's documentation on message filtering. The documentation clearly states that MMS messages can be filtered. (https://developer.apple.com/documentation/identitylookup/sms-and-mms-message-filtering) When we refer to MMS, it includes images, short videos, and other supported multimedia formats. However, the ILMessageFilterQueryRequest only provides the message body as a String, meaning we can access text and links but not images or other media files. Could you please confirm whether Apple allows third-party applications to access multimedia content sent from unknown numbers? Looking forward to your quick response. Thanks, Rijul Singhal

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.

In order to create a Message Filter Extension it is necessary to set up Shared Web Credentials. I'd like to form an understanding of what role SWC plays when the OS is making request to the associated network service (when the extension has called deferQueryRequestToNetwork()) and how this differs from when an app directly uses Shared Web Credentials itself. When an app is making direct use of SWC, it makes a request to obtain the user's credentials from the web site. However in the case of a Message Filter Extension, there aren't any individual user credentials, so what is happening behind the scenes when the OS makes a server request on behalf of a Message Filtering Extension? A more general question - the documentation for Shared Web Credentials says "Associated domains establish a secure association between domains and your app.". Thank you

Hi Team, We’re encountering a device-specific issue with our SMS Message Filter extension. The extension works as expected on an iPhone 11 running iOS 16.6, but it does not trigger on an iPhone 12 Pro running iOS 16.7. Key Observations: The extension is implemented using ILMessageFilterExtension and calls messageFilterOffline(appGroupIdentifier:for:) from our shared library. The App Group is properly configured and accessible across the app and extension. The extension is enabled under Settings > Messages > Unknown & Spam. There are no crashes or error logs reported on the affected device. The issue is consistently reproducible — it works on one device but not the other. We’re wondering if this could be a regression or a device-specific behavior change introduced in iOS 16.7. Has anyone encountered similar inconsistencies in Message Filter extensions across different iOS versions or device models? Any guidance or suggestions would be greatly appreciated. Thanks in advance!