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.

I'm working on building a Text Messages Filter Extension app and currently facing the below error: "Cannot find 'ILMessageFilterExtensionConfigurationManager' in scope". As required the app includes MessageFilterStatusManager.swift file, with the host app designated as the Target Membership. App minimum deployment is set to iOS 17.6 and I'm working with Xcode Version 26.2. If anyone has encountered this error I'd appreciate your feedback.

I am implementing a custom SMS filter using the IdentityLookup framework. My goal is to authenticate the network requests made via context.deferQueryRequestToNetwork using a user-specific JWT token generated in the containing (main) app after a successful login.

If there is this situation: A text message is sent from a sender and gets classified as junk (by a text filtering extension) with the result that it gets send to the spam folder as expected. A text message with different content is sent from the same sender and gets classified as allowed, however it also gets sent to the spam folder. If the above is repeated but after step 1 the message is deleted, then in step 2 the message doesn't get sent to the spam folder. So the presence of the message from step 1 being in the spam folder is having an effect on the behavior of step 2. Expected beahavour (if so, why?), or a defect?

When a user enables an SMS filtering extension via iOS Settings → Messages → Text Message Filtering and selects an app, the following prompt appears: "The developer of [App Name] will receive the text, attachments and sender information in text messages from senders not in your Contacts. Messages may include personal or sensitive information like bank verification codes." This message cannot be modified by developers, and we're receiving complaints and negative reviews from users who are alarmed by it, despite our app not collecting any data. iOS should allow developers to customize this message or reword this message to not make false claims about data collection. We've opened a feedback assistant report here: FB21445903

In my case, when I try to block calls on iOS 26, the blocking doesn't occur; the scenarios seem intermittent. If I create two CallDirectory extensions, the first blocks the numbers, but the second doesn't. Interestingly, the extension marks the number as suspicious. There's also a case where, on iOS 26 on an iPhone 16 Pro, the functionality doesn't work at all. I'd like to know if there have been any changes to the use of CallKit in iOS 26, because users of my app on iOS 18 and below report successful blocking.

I read online that there is no way to extract the call log from an iPhone. I want to develop an app to help people remember to call their mom, and if they did, the "nagging" would disappear automatically. I'm looking for any workaround to know when a user called someone, without having them log it manually.

Are we planning to have some APIs or methods to know that status of Call blocking extension and message filter extension in future releases as currently it is not available.

Hi, I developed an iOS app which will do SMS filtering by following this documentation. https://developer.apple.com/documentation/identitylookup/sms-and-mms-message-filtering) I built the app and send Test Flights to different testers. All the Testers from Sri Lanka (an asian country) says filtering is working and they can see all the enabled categories on the Messages too (including iOS 26). But the testers from Mexico cannot see the categories and filtering is not working. On official documentation there is nothing about supported countries. But I found true caller article https://support.truecaller.com/support/solutions/articles/81000406341-how-do-i-enable-sms-filtering-on-iphone mentioning it support only few countries for SMS filtering. Currently available in the following countries: India, Nigeria, South Africa, Kenya, Bangladesh, Sri Lanka. Our previous Categories filtering are still available for: Australia, Bahrain, Canada, Ghana, Tanzania, United Kingdom, United Arab Emirates, United States of America, Zambia Following article https://clearstream.io/blog/ios-26-iphone-new-text-message-filtering is saying some categories are supported by only Brazil and India. Still I could not find any official documentations saying different country supports.

We are not receving incoming call from blocked numbers below iOS 26 versions but same in iOS 26 onwards we are receiving the incoming call.. Can you please provide any solutions to fix the issue

Hello all, I'm developing a Mac app and need to read the content of incoming SMS, I am able to implement in android just the user has to consent and it does not read her contacts messages, so I am wondering if apple can allow this.

Hi, I am just wondering if there is any option to protect my endpoints that will be used by Message Filtering Extension? According to the documentation our API has 2 endpoints: /.well-known/apple-app-site-association /[endpoint setup in the ILMessageFilterExtensionNetworkURL value of the Info.plist file] that the deferQueryRequestToNetwork will request on every message Since all requests to these 2 endpoints are made by iOS itself (deferQueryRequestToNetwork), I don't understand how I can protect these endpoints on my side, like API key, or maybe mTLS. The only way that I found is white list for Apple IP range. Is there other methods for it?

Hi, We are working to integrate the Live Caller ID Lookup feature into our app. After submitting the request form via the link: https://developer.apple.com/contact/request/live-caller-id-lookup/, we received this reply from Apple: Apple’s OHTTP relay has been configured to talk to your OHTTP gateway. Now Live Caller ID Lookup should work for your application extension when distributed through App Store. However, before officially releasing our app on the App Store, we’d like to make sure the Live Caller ID Lookup feature is working as expected. To test this, we uploaded the app to TestFlight, and it successfully passed App Review. However, the test failed — we observed that the system tries to fetch the config from http://www.example.com/config instead of our actual configuration URL. Questions: Is this expected behavior when using TestFlight? Does the Live Caller ID Lookup feature only become active after full public release on the App Store? Is there any recommended way to test this feature before public release? Thank you!

Title's basically the whole question. I'm writing an SMS/Call Reporting extension (ILClassificationUIExtensionViewController). My goal is to keep everything on device and not use the built-in SMS/network reporting. To that end, I'm trying to write to a file in the App Group container from the classificationResponse handler. I'm getting Error 513: "You don’t have permission to save the file “classification_log.txt” in the [app group container folder]". I haven't been able to find much in the documentation on whether this behavior is enforced in classificationResponse handlers. Apple's barebones page on "SMS and Call Spam Reporting"[1] says "the system always deletes your extension’s container after your extension terminates," but that doesn't answer whether you can write to an App Group container. I haven't been able to find that answer elsewhere. ChatGPT and Gemini are both very sure it can be done. Any thoughts? [1] https://developer.apple.com/documentation/identitylookup/sms-and-call-spam-reporting

Hello fellow developers, Anyone blocked at the Live Caller ID Lookup configuration step? I submitted multiple times the form without any news from Apple since a few months (last one is FL7S57UFVR). This is blocking our app release to our customers. Thank you

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

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 "