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.

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’d like to submit a feature request regarding the availability of Foundation Models in MessageFilter extensions. Background MessageFilter extensions play a critical role in protecting users from spam, phishing, and unwanted messages. With the introduction of Foundation Models and Apple Intelligence, Apple has provided powerful on-device natural language understanding capabilities that are highly aligned with the goals of MessageFilter. However, Foundation Models are currently unavailable in MessageFilter extensions. Why Foundation Models Are a Great Fit for MessageFilter Message filtering is fundamentally a natural language classification problem. Foundation Models would significantly improve: Detection of phishing and scam messages Classification of promotional vs transactional content Understanding intent, tone, and semantic context beyond keyword matching Adaptation to evolving scam patterns without server-side processing All of this can be done fully on-device, preserving user privacy and aligning with Apple’s privacy-first design principles. Current Limitations Today, MessageFilter extensions are limited to relatively simple heuristics or lightweight models. This often results in: Higher false positives Lower recall for sophisticated scam messages Increased development complexity to compensate for limited NLP capabilities Request Could Apple consider one of the following: Allowing Foundation Models to be used directly within MessageFilter extensions Providing a constrained or optimized Foundation Model API specifically designed for MessageFilter Enabling a supported mechanism for MessageFilter extensions to delegate inference to the containing app using Foundation Models Even limited access (e.g. short text only, strict execution limits) would be extremely valuable. Closing Foundation Models have the potential to significantly raise the quality and effectiveness of message filtering on Apple platforms while maintaining strong privacy guarantees. Supporting them in MessageFilter extensions would be a major improvement for both developers and users. Thank you for your consideration and for continuing to invest in on-device intelligence.

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.

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

Currently I am not finding any API to read the status of Message Filter Extension from settings. Are we planning for any future releases ?

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.

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 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!

I'm seeking help troubleshooting a persistent com.apple.IdentityLookup.error.messagefilter Code=3 error when my Message Filter Extension tries to defer to network. I’ve exhausted Apple documentation and forum posts, and Apple Support has asked me to escalate this via the forums to reach engineering. ✅ My Setup: Xcode: 16.2 macOS: Sequoia 15.3.1 (Apple Silicon Mac mini) Device: iPhone 14 Pro iOS: 18.3.2 (Developer Mode enabled) Tested via: TestFlight install on real device 📦 App Structure: Main App Target (minimal "hello world" logic) Message Filter Extension Target Messages Extension Target Message Reporting Extension Target Notifications Extension Target ✅ Capabilities & Configurations Main App Capabilities: App Groups: group.com.example.shared Network Extensions: Content Filter Associated Domains: messagefilter:my-api.example.com applinks:my-api.example.com Message Filter Capabilities: App Groups: same as main app Network Extensions: Content Filter Associated Domains: same as above 📄 Info.plist Config Main App Info.plist: NSAppTransportSecurity with: NSAllowsArbitraryLoads = YES Exception domain my-api.example.com with: NSIncludesSubdomains = YES NSTemporaryExceptionAllowsInsecureHTTPLoads = YES NSTemporaryExceptionMinimumTLSVersion = TLSv1.2 MessageFilter Info.plist: Same ATS settings as above NSExtension block: <key>NSExtension</key> <dict> <key>NSExtensionAttributes</key> <dict> <key>ILMessageFilterExtensionNetworkURL</key> <string>https://my-api.example.com/api/sms-filter</string> <key>ILClassificationExtensionSMSReportDestination</key> <string>+10000000000</string> </dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.identitylookup.message-filter</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).MessageFilterExtension</string> </dict> 📜 Entitlements Main App Entitlements <key>com.apple.developer.associated-domains</key> <array> <string>messagefilter:my-api.example.com</string> <string>applinks:my-api.example.com</string> </array> <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider</string> </array> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.shared</string> </array> Message Filter Extension Entitlements Identical to main app’s, scoped to the extension. 📄 AASA File (Hosted on https://my-api.example.com/.well-known/apple-app-site-association) Serves as application/json, returns 200 OK, and is reachable on device via Safari. Logs confirm AASA is downloaded and installed successfully during TestFlight install. { "applinks": { "apps": [], "details": [ { "appID": "TEAMID.com.example.app", "paths": ["*"] }, { "appID": "TEAMID.com.example.app.MessageFilter", "paths": ["*"] } ] }, "messagefilter": { "apps": [], "details": [ { "appID": "TEAMID.com.example.app", "filterType": "URL", "domains": ["my-api.example.com"] }, { "appID": "TEAMID.com.example.app.MessageFilter", "filterType": "URL", "domains": ["my-api.example.com"] } ] }, "classificationreport": { "apps": [], "details": [ { "appID": "TEAMID.com.example.app", "domains": ["my-api.example.com"] }, { "appID": "TEAMID.com.example.MessageReporting", "domains": ["my-api.example.com"] } ] } } ❌ The Problem When the extension launches and receives an SMS to classify, logs show: deferQueryRequestToNetwork failed: The operation couldn’t be completed. (com.apple.IdentityLookup.error.messagefilter error 3.) The extension loads, network URL is available, the AASA is installed, and yet the extension is not allowed to defer to network. This occurs every time. 🧪 Other Notes Tried rebuilding everything from scratch Archiving to TestFlight, not running via Xcode Clean entitlements verified using codesign -d --entitlements :- Console logs show no issues with AASA download or validation Any help or insights from Apple engineering or others in the community who have successfully deployed a working Message Filter Extension would be hugely appreciated. Thanks in advance 🙏

Hello, I am developing a messaging filtering app (F-Secre) that includes a Message Filter Extension. The extension correctly identifies and filters spam SMS/iMessage. In iOS 18, when a message was filtered into the Junk folder, the Messages app would correctly display a label beneath it indicating it was filtered by our product, e.g., “Junk filtered by F-Secre”. After updating to the iOS 26 beta (26.0 (23A5330a)), the filtering functionality itself still works—messages are correctly moved to the Junk folder. However, the branding attribution ("filtered by F-Secre") is now missing. The message appears in the Junk folder with no indication of which extension filtered it. This is a regression in user experience, as it removes visibility and credit for our app's work and might confuse users about whether the filtering system is active.

We have received some information that with the release of iOS 18, there have been notable changes in how this API behaves, can apple team shed some light on this? on ios 17 this worked without much issues, what has changed on ios 18?

When I create a sticker app in any version of Xcode or for any iOS version, I keep running into the following error: Error acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2 "Could not find attribute name in domain plist" UserInfo={NSLocalizedFailureReason=Could not find attribute name in domain plist}> I only added stickers after creating the project and this is what happens after running it. I have cleared Derived Data, tried creating a new Info.plist, but nothing seems to solve this core issue. This also occurs both when attempting to run the project on a simulated phone and a physical device. This error also only happens when the sticker app is opened in iMessage. I have looked for solutions everywhere, but none seem to solve my problem. Am I overlooking something?

Hi, We have a need to provide SIM verification. At present, accessing the phone number bound to the device is not programmatically accessible. Would Apple consider exposing this API via a user consent? Otherwise, what is the suggested approach to verify the SIM card is the correct phone number on an iOS device?

Hello, I am building an iMessage extension for my app and I am struggling to figure out how to test it. The extension allows users to send their friends an interactive widget and the recipient experience is very important to test. I tried to do it in the simulators, but simulators do not support iMessage. I have got a second iPhone and created a sandbox account, but I cannot install TestFlight with the sandbox account, as this feature is not supported. Reddit, Stackoverflow, ChatGPT and Apple Developer support also did not help. Can someone share their experience with testing recipient experience in the iMessage extension?