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.

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