The issue below affects every partner app embedding our SDK, so we'd appreciate DTS taking a deeper look. We're happy to open a code-level support request and provide screen recordings and a sysdiagnose. Details are in FB25326312. We ship an SMS filtering SDK (a Message Filter app extension) that partner apps embed. Password AutoFill is treating the SDK's messagefilter: associated domain as a credential domain for the host app, so unrelated saved logins appear on the partner app's sign-in screen. Configuration Apple validates Message Filter network deferral against the containing app (an unauthorized containing app gets ILMessageFilterError.Code.networkURLUnauthorized), so the entitlement must be declared on each host app, not the extension: messagefilter:messagefilter.example.comThe AASA file at messagefilter.example.com lists the host app IDs under messagefilter only. It has no webcredentials key. Network deferral works as expected. (The real domain is in FB25326312.) Observed behavior On the host app's sign-in screen, saved logins for the SDK provider's domain (example.com) are suggested in the QuickType bar and the QuickType suggestions list: No webcredentials: domain: only example.com logins are suggested. App's own webcredentials: domain added (valid AASA entry): the app's logins appear, but example.com logins are still suggested alongside them. Password managers Reproduces with Apple Passwords and third-party password managers (tested with 1Password, Dashlane, and Norton Password Manager): Credential providers appear to receive the messagefilter domain in the serviceIdentifiers array passed to prepareCredentialList(for:). Some use only the first identifier, others use all of them. QuickType suggestions come from iOS itself, so the unrelated credentials appear regardless of which password manager is used. Seen on iOS 26 and iOS 27 in a production partner app. Questions Is it intended that a messagefilter: domain contributes to Password AutoFill credential matching? Is there a supported way to exclude it from AutoFill without breaking Message Filter network deferral?

Hello ! following up from a related thread (account transfer issue, now resolved: https://developer.apple.com/forums/thread/843546?answerId=911820022), but this is a distinct, new issue so starting fresh as suggested. The extension launches fine, XPC handshake succeeds, and PIR registration completes successfully. But the subsequent NEPIRChecker status check fails every time (retried repeatedly over several minutes, same result each time): PIR status returned error <Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: Error details were logged and redacted." UserInfo={NSLocalizedDescription=Unable to query status due to errors: Error details were logged and redacted., NSUnderlyingError=0x677037cf0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}>Config being registered (confirmed from the logs): pirServerURL = https://pir.dropbet.app/ pirPrivacyPassIssuerURL = https://pir.dropbet.app/issueBoth endpoints are live and were already validated as part of the original NEURL Filter configuration approval. I've captured a sysdiagnose from the device right when this was happening, so I have that ready to attach to a bug report if useful — just let me know and I'll file one. Any idea what CipherML error 1100/1800 typically indicates?

An explicitly blocked cellular caller continues to ring on iOS 26.6.2 (23G90). The number was previously saved and contacted. After removing it from Contacts and deleting its visible Recents entries, blocking still fails. We reproduced this with a minimal Call Directory extension containing exactly one bundled number. It uses no App Groups, shared storage, ranges or identification entries, and does not read isIncremental. Logs from 19 October 2026, IST: 08:03:01.701 — Apple’s Call Directory service: Added 1 phone number blocking entries 08:03:01.708 — Extension completion: expired=false 08:03:15 — Incoming cellular call from the configured test number communicationtrustd: Outgoing interactions found communicationtrustd: No remaining handles, returning trustScores callservicesd: shouldBlock: NO shouldSilence NO The call rings despite successful loading. Is there a supported API or entitlement allowing an explicit block to override prior-interaction precedence? Which retained interaction source could remain after Contacts/Recents deletion? We have a minimal reproduction project and sysdiagnose. Please advise how to provide them privately for engineering investigation.

We ship a Live Caller ID Lookup extension (PIR-based) for spam call blocking. It works, and our PIR server is fast. But in practice, whether a call gets blocked depends on the quality of the user's internet connection at the moment the call arrives. The system waits only about 1 second for the blocking response. On a fast, stable connection it arrives in time. On an average or unstable connection it often doesn't, and the spam call rings through. So under the current platform limits we cannot guarantee blocking for every call. How we measured For each call we read the device syslog (CommCenter, CallDirectory, ciphermld, callservicesd) and our server logs. The extension cache was reset before each call, so every call triggered a real network lookup. All times are in ms and measured from addNewIncomingCall. Server-side processing of the PIR query was consistently 51–61 ms. The variance is almost entirely network transfer between the device and the server (or relay): In call D, HTTP/2 metrics show the ~28 KB request was handed to the network stack immediately (outbound_duration_ms=0), but response headers arrived only after 2216 ms. In call E, the device waited ~660 ms between finishing the upload to the relay and receiving the first byte of the response. Connection setup on a new connection cost 176–271 ms (DNS + TCP + TLS, or a QUIC handshake to the relay). Before the first byte was sent, the system spent another 54–225 ms after the call arrived. In the failing cases the syslog shows: CallDirectory: not all blocking fetches returned within 1 second(s) callservicesd: shouldBlock: NO shouldSilence NO The block response (shouldBlock=1) then arrives 100–1500 ms too late, and the call keeps ringing. What works: repeat calls After the first lookup the result is cached on the device. A repeat call from the same number is silenced without contacting the server, whatever the connection speed. In our logs, follow-up calls from the same number were silenced within ~65 ms of addNewIncomingCall, with no network request. So a user may get the first spam call from a number but not the next ones. The first call, though, is exactly the one users complain about. The problem with the 1-second budget Each blocking lookup has to: Send a PIR query Receive a response of ~22–25 KB. Often open a new TLS/QUIC connection through the OHTTP relay. All of this has to fit into about 1 second, together with the system's own overhead before the request is sent. On a good connection that takes about 250–650 ms. On an average mobile or congested Wi-Fi connection it easily goes past 1 second, and nothing the developer can optimize on the server helps. Our server already responds in about 50 ms.

Hello everyone, I found an interesting post by a developer on social media that mentions that Apple has provided a new configuration profile. Is this a new feature? Does anyone have any additional information about it? And can anyone provide me with the link to download this profile?

We have a Live Caller ID Lookup deployment that has been blocked for weeks, and the core difficulty is not technical. It is that we cannot find out anything about the state of our onboarding submission. Here is where we stand. We submitted the onboarding form and our configuration was approved on 8 August. That approval email is the only communication we have ever received about this feature. Our service is deployed and verified: the OHTTP gateway negotiates HTTP/2, serves a valid key configuration, the issuer directory returns 200 and Apple polls it continuously, the DNS TXT record is in place, and the validation identity is in our corpus. Development builds work end to end and display caller names correctly on incoming calls. App Store builds do not. Every authenticated request fails on the device in roughly 47 ms, before anything leaves the phone: ciphermld(CipherML) requestData(byKeywords:shardIds:clientConfig:) threw NSURLErrorDomain Code=-1009 _NSURLErrorPrivacyProxyFailureKey = true nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed" The network path is healthy in the same moment, and other processes on the device do receive proxy configuration. Only our extension's bundle identifier never does. We reproduced this on Wi-Fi and on cellular, and after a device restart. We have since learned, from a maintainer replying to an issue we opened on the pir-service-example repository, that "approved" in the CloudKit console is not the same thing as "successfully onboarded", and that we are still in the first state. That explains the behavior completely. What we cannot explain is how a provider is supposed to discover this. There is no status field in the console, no notification when the state changes, and nothing in the onboarding documentation that mentions a second stage exists. We wrote to Apple several times over these weeks. We were told more than once that an internal team would look into it, and we never received a reply. Apple Support told other providers in the same situation that this is a technical matter beyond their scope. Looking through the pir-service-example issues, this pattern is common. One provider reported waiting three months without a response. Another reported that form to production took almost four months. Another only discovered the feature had been enabled by noticing traffic arriving at their own server. My questions: Is there any supported way to check the onboarding state of a submitted configuration, or to ask about one that appears stuck? If not, is anything planned? Is the transition from "approved" to "successfully onboarded" expected to be automatic, and roughly how long should it take? For anyone who has been through this: did you eventually get a notification, or did you find out by watching your own server logs? We are not asking for our submission to be prioritized. We would simply like to know whether we are waiting on something or whether something needs to be resubmitted, and right now there is no way to tell the difference. Our paying subscribers cannot use the feature, and we have not been able to give them an accurate answer either. Thank you.

Summary Our Live Caller ID Lookup deployment works end-to-end from an Xcode-signed build but fails on the App Store build of the same app, on the same device, same network, same Apple ID. On the production build every authenticated request fails locally in ~47 ms, before any packet leaves the device. Our Identity & Trust configuration in CloudKit Console has read "Approved" since 2026-08-08. Device log at the moment of failure nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed" ciphermld(CipherML) <Error>: queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token _NSURLErrorPrivacyProxyFailureKey=true NSUnderlyingError={NSPOSIXErrorDomain Code=50 "Network is down"} (_NSURLErrorNWPathKey=satisfied, Wi-Fi up, LQM: good) Control experiment: the device's privacy proxy stack is healthy at that exact moment 0.93 seconds before our extension is refused, the same device attaches a proxy to another connection without any problem: 11:51:59.417 mDNSResponder nw_endpoint_proxy_add_config_if_applicable Adding proxy masque Proxy: https://mask.icloud.com:443 11:52:00.337 ciphermld [C15 ... bundle id: <our extension>, proxy fail closed] start 11:52:00.346 ciphermld Proxies not present, but required to fail closed System state in the same capture: Privacy Proxy Service Status: 1 Privacy Proxy User Tier: 1 Privacy Proxy Networks: (<Cellular, Active>, <WiFi, Active>) Counts across the capture: nw_endpoint_proxy_add_config_if_applicable appears twice (mDNSResponder and Safari SafeBrowsing), while Proxies not present appears 16 times, all from ciphermld, all for our extension's bundle id. No connection made on behalf of our extension is ever given a proxy configuration. Reproduced on two networks and after a device restart, with the device charging and Low Power Mode off. Apple's own endpoint already recognises our issuer 11:51:59.405 ciphermld(CipherML) Fetching token issuer directory from https://gateway.icloud.com/pat-issuer-directory?issuer=<our-issuer-host> 11:52:00.332 200, 1511 bytes, 928 ms Our validation Bearer token from the onboarding submission also returns 200 on /token-key-for-user-token when Apple's validator calls it, which we observe on our server several times a day. A second observation that may be the key In apple/pir-service-example issue #139 an Apple engineer stated that once onboarding is complete, "all requests ... will automatically use OHTTP even when it is a development build". We captured our development build today with full device logging. Every one of its connections goes directly to our PIR host over QUIC, with no proxy fail closed stamp, and the words ohttp, oblivious, mask.icloud and our OHTTP gateway hostname appear zero times in the capture: 16 connections, all: Hostname#<our-pir-host>:443, attribution: developer "proxy fail closed": 0 "Proxies not present": 0 If a completed onboarding forces OHTTP even for development builds, then our development build going direct indicates the relay configuration was never distributed for our extension's bundle id, despite the console showing "Approved". Fleet-level data, not a single device On the day of release, 40 distinct premium accounts on the current App Store build fetched their user tier token from our backend. Across that entire day our PIR service saw zero Privacy Pass issuances and zero queries from App Store builds. For contrast, a single development-signed device produced 144 /issue requests in one day earlier in the month. What we already checked and fixed on our side HTTP/2 ALPN negotiates on all three hosts (service, issuer, gateway). The DNS TXT ownership record is in place. The OHTTP gateway serves a valid key config (X25519 / HKDF-SHA256 / AES-128-GCM). The PIR use case names match the required <extension bundle id>.block / .identity format exactly. The validation identity +1 408 555 1212 "Johnny Appleseed" is present in the live corpus. We found and fixed a real defect of our own: our OHTTP gateway's allowed target origin list was missing the issuer host. We corrected it and restarted the gateway (its HPKE key config was byte-identical afterwards, so no key rotation occurred). The failure reproduced with an identical signature seven minutes later, and the device log confirms these hops never touch our gateway anyway. Questions Is relay / privacy proxy provisioning for a production bundle id a separate step after the Identity & Trust configuration is approved, and what is the expected propagation time? Is there any way for a developer to check provisioning status? Right now an "Approved" badge and a completely non-functional production build look identical from our side. Is there a supported way to exercise the production privacy proxy path before shipping to the App Store? Development builds bypass it by design, so the first real test of the production path was made by paying customers. This seems likely to affect other adopters. Is provisioning keyed on the extension bundle id, the app bundle id, or the team id? Other system consumers on the same device receive proxy configurations normally. We accidentally submitted two identical configurations three minutes apart on 2026-08-08 and both show "Approved". Can a duplicate block or confuse provisioning, and should one be revoked? Environment: iPhone 17 Pro Max, iOS 26.6.1, Xcode 26.5 (17F42). App Store build version 14 (36). Feedback Assistant report with full device logs: FB24501570 GitHub issue with the same detail: https://github.com/apple/pir-service-example/issues/162 Configuration ID: 693155e2-b8ba-4b47-9b6c-64fd97677386 and a1959377-8069-4225-87b9-c1ff81016611

Our NEURLFilter (URL Filter) and Live Caller ID Lookup entitlements are both Approved, but on device the URL filter never activates — the NEURLFilter session loops starting → stopped, so no URLs are filtered. App: bundle app.scamzero (App ID 6768433709) URL Filter Config ID: 224e33c9-b03b-44ce-87cd-2153c86908ce Live Caller ID Lookup Config ID: 0abdc42b-c98b-4753-8af4-9334d42abdb8 Device: iPhone on iOS 26. Test account has the paid plan that enables the feature. The system log shows the failure is fetching the Privacy Pass token issuer directory through Apple's relay (gateway.icloud.com), not our backend: ciphermld : Failed to fetch Token Issuer Directory. URL: https://gateway.icloud.com/pat-issuer-directory?issuer=issuer.scamzero.app Status Code: 404 → NEURLFilterPlugin setStatus:error — NEAgentURLFilterErrorDomain Code=3 → NESMURLFilterSession status changed to stopping with error 3 → prefilterCleanup (removes the prefilter mmap) → session restarts → loop This looks like NEURLFilterManager.Error.serverSetupIncomplete (9). What we have already verified on our side (everything conforms): We run Apple's unmodified reference PIRService (from apple/pir-service-example). Our issuer directory at https://issuer.scamzero.app/.well-known/private-token-issuer-directory returns 200 with valid token-keys (token-type 2) and issuer-request-uri. OHTTP gateway (gateway.scamzero.app/ohttp-configs and /gateway), PIR service (service.scamzero.app), use case app.scamzero.url.filtering, bearer token AAAA, DNS TXT apple-url-filter=app.scamzero, and the validation URL apple.com/url-filter-test = 1 are all configured. Our pre-launch checks pass. The precomputed Bloom prefilter loads on device with the correct bit/hash/seed and ~37k domains. Key observation: our OHTTP gateway logs show zero successful OHTTP requests from Apple's infrastructure since Aug 10, and gateway.icloud.com/pat-issuer-directory?issuer=issuer.scamzero.app returns 404 on device. This suggests our Privacy Pass issuer is not registered/validated in Apple's PAT issuer directory, even though both entitlements are Approved. Question: How can we get our Privacy Pass issuer (issuer.scamzero.app) registered/validated in Apple's token issuer directory for the use cases app.scamzero.url.filtering and Live Caller ID Lookup? The entitlements are approved, but the on-device token issuer directory lookup fails with 404, which prevents the filter from ever activating. Happy to file a Feedback with a sysdiagnose if useful.

iOS 18 (22A3354) will not offer a option in settings (> Apps > Phone) after calling openSettings to enable live caller id lookup extension. iPhone and MacBook are in the same network. The PIRService runs on MacBook and is reachable via iPhone Safari (via http://MacBookPro:8080/). Hummingbird print log: hb_method=GET hb_uri=/ [Hummingbird] Request. After deploying the application via Xcode to the iPhone no requests are printed in the terminal. The extension was added like documented and bundle id is also checked multiple times. issuerRequestUri in service-config.json is http://MacBookPro:8080/issue. As far as I can tell, everything has been set up in accordance with the Testing Live Caller ID instructions. Is there something missing?

Does iOS support launching of 2 MFMessageComposeViewControllers back to back i.e without dismissing the previous one? We are integrating an SDK from a vendor who, inside the SDK is presenting the MFMessageComposeViewController 2 times back to back, and one of the MFMessageComposeViewController is getting dismissed but the other one doesn't, their standalone app does the same but it works there, not inside the SDK, Just wanted to know why the second MFMessageComposeViewController doesn't dismiss, or is it the correct approach to do so.

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.

We submitted Live Caller ID Lookup requests for two apps and both remain “In Review.” Our PIR server, Privacy Pass issuer and OHTTP gateway are deployed, DNS TXT records are published for both bundle identifiers, and the test number returns correctly. Is there a way to verify from our side that Apple’s automated endpoint validation passes? Any common misconfiguration that causes a request to sit without feedback?

您好，想咨询下Configuration ID为32b92585-4221-4b39-a305-c3de951bb53a的Live Caller ID Request的最新审批状态，目前功能开发已完成缺少OHTTP网关就可以正式投入使用。

您好，想咨询下Configuration ID为2641fd1b-8023-4644-b301-1d57785b8f6c的Live Caller ID Request的最新审批状态，目前功能开发已完成缺少OHTTP网关就可以正式投入使用。

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.