Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

Environment Platform: iOS iOS versions tested: : 26.5.2, 26.5 Xcode: 26.3 Language: Swift UI framework: SwiftUI App distribution: App Store Device models tested: : iPhone 17, iPhone 16, iPhone 15 pro max, iPhone 17 pro max Issue We are experiencing an issue where the app icon does not update to the latest app icon after an app update on some devices. Initially, our app used Apple's alternate app icon functionality through setAlternateIconName to dynamically change the app icon. However, we observed that the alternate icon was not being updated correctly on some devices. As it was not working , we removed the alternate icon approach and changed the primary/default app icon in the application itself. We then submitted an updated app version with the new default icon. After updating the app, the new app icon is displayed correctly on some devices, but on some other devices the previous/old app icon continues to be displayed, even though the app has been successfully updated to the latest version. The issue appears to be device-specific, as the same app version can display the new icon on one device while continuing to display the old icon on another device. Expected Behavior After installing an app update containing a new default app icon, the new app icon should be displayed on the Home Screen and in relevant system locations such as Shortcuts. Actual Behavior On some devices, after successfully updating the application to the new version, the old app icon continues to be displayed. The application itself is updated successfully and launches normally. The issue is specifically with the icon displayed by the system. Steps to Reproduce Install an older version of the application containing the old app icon. Update the application to a newer version where the default/primary app icon has been changed. Verify that the application has been updated to the latest version. Return to the Home Screen. Observe the application icon. If applicable, check the application icon in the Shortcuts interface. Expected: The new app icon is displayed. Actual: On some devices, the previous app icon is still displayed. Additional Observations We observed different behaviors on affected devices: On one affected device, the old icon remained after the app update but changed to the new icon after restarting the device. On another affected device, the icon changed to the new icon after some time without reinstalling the application. However, on that device, the old icon continued to be displayed in the Shortcuts interface even after the Home Screen icon had changed to the new icon. Reinstalling the application causes the new icon to appear correctly. These observations make the behavior appear to be related to how iOS refreshes or caches application icons after an app update. Additional Information We initially attempted to use Apple's alternate app icon functionality through setAlternateIconName. The alternate icon approach did not update the icon consistently across all tested devices. We therefore changed the application's default/primary icon instead of relying on alternate icons. The issue still occurs on some devices even after changing the default app icon. The application itself functions normally after the update; only the displayed app icon remains unchanged on the affected devices. The issue appears to occur specifically with updating an existing installation rather than installing the application for the first time. Questions Is there any known iOS behavior where the previous Home Screen icon can remain cached after an app update? Is there a recommended way to ensure that iOS refreshes the Home Screen icon after changing the default app icon? Could this behavior be related to the previous use of alternate app icons through setAlternateIconName? Why might the Home Screen icon update after a restart or after some time while the icon shown in Shortcuts continues to display the previous icon? Are there any specific requirements for CFBundleIcons, asset catalogs, Info.plist, or other configuration that we should verify when changing the primary app icon? Is this a known issue on any specific iOS versions or device configurations? We would appreciate any guidance on whether this is expected iOS behavior, an icon caching issue, or if there is something specific we should change in our application configuration.

Hello Apple Developer Team, We are observing a BLE connectivity issue in our application BlueDiamond Mobile Elite after upgrading devices to iOS 27 Public Beta. Environment App: BlueDiamond Mobile Elite Platform: iOS 27 Public Beta Framework: CoreBluetooth Device Type: iPhone BLE Peripheral: Access control/BLE reader Testing Status: BLE scanning works correctly. Reader discovery works correctly. Connection establishment succeeds. Service and characteristic discovery complete successfully. Issue occurs during credential transmission. Problem Description After connecting to a BLE reader, our application sends mobile credentials to the reader using CoreBluetooth. The workflow is: Scan for BLE readers. Discover target reader. Connect to reader. Discover services and characteristics. Start credential transfer. BLE connection disconnects unexpectedly during or immediately after the credential write operation. The disconnect occurs before the credential transaction completes successfully. Observed Behavior BLE scanning is functioning normally on iOS 27 Public Beta. The reader is discovered without issues. Connection is established successfully. Credential provisioning/credential write operation triggers the problem. centralManager(_:didDisconnectPeripheral:error:) is invoked after the credential transfer attempt. The credential is not successfully delivered to the reader. Expected Behavior The BLE connection should remain active throughout the credential provisioning process and disconnect only after the transaction is completed or when explicitly terminated by the application. Additional Information The same credential issuance flow worked correctly on previous iOS versions. We have already addressed another iOS 27 compatibility issue related to QR code access by updating to Apple's recommended APIs. We are currently investigating whether the BLE disconnection is caused by: Changes in CoreBluetooth behavior in iOS 27 Public Beta. MTU/write packet handling. Write-with-response versus write-without-response behavior. Peripheral firmware compatibility. Credential payload size or transfer timing. Questions Are there any known CoreBluetooth regressions or behavior changes in iOS 27 Public Beta related to characteristic writes or BLE credential provisioning? Has anyone observed unexpected peripheral disconnects during write operations on iOS 27 Public Beta? Are there any recommended changes for applications performing secure credential transfers to BLE peripherals? Any guidance would be greatly appreciated.

Hi, We've implemented age assurance logic in our app using the DeclaredAgeRange framework to comply with regulations in Brazil (Digital ECA, effective March 17, 2026) and Utah (App Store Accountability Act, effective May 6, 2026). Our implementation calls AgeRangeService.shared.isEligibleForAgeFeatures on app launch to determine whether the current user is subject to age assurance requirements, and proceeds to call requestAgeRange(ageGates:) accordingly. However, after monitoring in production since the Brazil enforcement date, we've consistently observed isEligibleForAgeFeatures returning false for users in regulated regions, with no age range data being returned. What we'd like to clarify: Is isEligibleForAgeFeatures currently returning true for users in Brazil in production (not sandbox)? For Utah — given that HB 498 pushed the developer compliance deadline to May 6, 2027, will isEligibleForAgeFeatures reflect the original May 6, 2026 activation date or the revised 2027 date? Is there a known rollout schedule or gradual activation plan for these regions that would explain why the flag remains false even after the legal enforcement dates have passed? We've seen similar reports from other developers on these forums, so it seems this may be a widespread issue rather than an implementation problem on our end. Any official guidance on the current status of the API in regulated regions would be greatly appreciated. Thanks.

Using VisionKit, there's two main ways to get text from images. ImageAnalyzer VNRecognizeRequest Based on some OCR tests, I'm seeing that the outputs from these two methods are different. Initially, I thought ImageAnalyzer was running VNRequestTextRecognitionLevel.fast because it's for Live Text, but the outputs from ImageAnalyzer are sometimes better than VNRequestTextRecognitionLevel.accurate. Is ImageAnalyzer running VNRequestTextRecognition in the background? Or if it isn't, what pipeline is it using to detect text?

We're evaluating Apple-hosted Background Assets for an app distributed on App Store and would like to understand the security model behind it before adopting it. So far the public documentation only mentions the HTTPS requirement for asset transport. We'd appreciate any additional documentation or guidance covering: How asset downloads are authenticated (e.g., is access tied to the app's entitlement/provisioning, or is there a separate token/credential mechanism?) How access to specific assets is controlled/scoped Where Apple-hosted assets are physically/logically hosted (e.g., is this CDN-backed, and is there any control or visibility over hosting region?) Any other security considerations typically associated with cloud-hosted content (encryption in transit and at rest, integrity verification, etc.) Is there a more detailed security/architecture document beyond the public developer documentation, or can someone from the team point us in the right direction?

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.

I recently had my app Spark Matched: https://apps.apple.com/us/app/spark-matched/id6786071027 accepted to the Apple Store but when I try to launch promptly closes and the icon I added isn’t displaying

On iPadOS 26, PDFKit runs VNRecognizeDocumentsRequest over the pages of a PDFDocument when those pages are rendered. The analysis pipelines are never released. Measured on an iPad Pro 12.9-inch 4th gen (iPad8,11), iPadOS 26.6, with a 61-page image-only scanned score: each newly-created-and-rendered PDFDocument costs about 2.7 OS threads and 20 MB, permanently. Repeatedly loading the same file from disk reached 153 threads and 1519 MB in under seven minutes, then died of an allocation failure. Nothing releases it: not replacing PDFView.document, not deallocating the PDFView entirely, not releasing the PDFDocument, and not time. With every code path in the app stopped, the thread count does not fall — it continues to rise. The stack -[PDFView visiblePagesChanged:] → +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] → -[VNImageRequestHandler performRequests:gatheredForensics:error:] → -[VNRecognizeDocumentsRequest internalPerformRevision:inContext:error:] → -[VNDetector processUsingQualityOfServiceClass:options:regionOfInterest:…] → -[VNControlledCapacityTasksQueue dispatchSyncByPreservingQueueCapacity:] Thread census at 1519 MB — 153 threads total, after 66 document loads: 66 PDFKit.PDFDocument.formFillingQueue 64 com.apple.VNRecognizeDocumentsRequestRevision1 10 ANEServicesThread 66 orphaned pipelines for 66 loads, all blocked on Vision's capacity limiter. The console also emits Invalid permutation index when reordering subregions. Index N must be less than number of subregions 1 continuously, with N increasing — and these keep arriving after all application activity has stopped. Isolation Each row is a separate run on the same device and OS, one variable changed. Counts are OS threads; baseline is 13. Configuration Result Page-stepping only on a stable document (~1000 visiblePagesChanged: events) No growth; footprint declines Recreating PDFThumbnailView on every load No growth Creating a PDFDocument and never rendering it No growth Creating + rendering, assigned to a PDFView +2.0 to +2.7 threads / +20 MB per load Creating + rendering, never assigned to any PDFView Same growth Creating + rendering, entire PDFView destroyed and rebuilt per load Same growth Two points worth drawing out: The leak occurs with no PDFView involved at all — plain PDFPage.thumbnail(of:for:) or PDFPage.draw(with:to:) on a freshly created document is sufficient. Destroying the PDFView releases nothing. Whatever retains the analyses outlives every object the application can reach. Also, for anyone who arrives here from the other PDFPageAnalyzerV2 threads: the usePageViewController(true, withViewOptions: nil) workaround does not help this. It reduces visiblePagesChanged: frequency, and page changes on a stable document leak nothing. The variable is newly rendered documents, not new pages. The switch already exists PDFView implements -setDocumentAnalysisEnabled: and -isDocumentAnalysisEnabled, plus -handleAnalysisCompletionOfPage:resultTypes:. None of these appear in any public header. With document analysis disabled, the leak disappears completely — 28 consecutive document loads with zero thread growth, and after stopping, the process released down to 6 threads and 64 MB, below its own idle baseline. It also suppresses the leak for documents never assigned to that PDFView, so whatever the flag gates is not scoped to a single view. For completeness, the per-page -setCandidateForOCR: / -setDidPerformOCR: accessors do not help: the writes land and read back correctly, and the analysis runs anyway. They appear to be state rather than policy. Request Either: Fix the leak — cancel and release analyses when the document or the view goes away; or Make documentAnalysisEnabled public on PDFView (or add an equivalent on PDFDocument). Ideally, please do both. The second costs Apple nothing: the property exists, it works, and it is exactly the control that is needed. Applications that render sheet music, engineering drawings, or any other content where document understanding provides no value are currently paying for it with unbounded memory growth and no supported way to decline. Filed as FB24211659. Happy to share the isolation harness with anyone from the PDFKit team. Related: 825803 (crash in PDFPageAnalyzerV2, FB22409977), 827781 (deadlock in the same class), 838272 / 837282 (PDFTileSurface over-release), 107007 (CGContextDrawPDFPage thread safety, open since 2018).

Question 1 (Return journey from containing app back to original host): Is there an alternative, supported method for a custom keyboard extension to launch its containing app such that when that containing app is later suspended/resigned, the system returns the user to the original host app (e.g., Notes) instead of the Home screen? Does iOS 26 provide any handoff/return APIs for the keyboard voice‑input scenario? Question 2 (Full‑access‑off persistence and settings navigation): (a) Is the shared app group container expected to be effectively read‑only (with EPERM) when Full Access is off? If so, is there any supported way to persist keyboard settings (that require writing to shared files) without Full Access? (b) What is the supported method for a keyboard extension to direct the user to Settings to enable Full Access on iOS 26, given that openURL via responder chain and extensionContext.open both fail? We are seeking a reliable, non‑private API approach.

How does iOS handle Associated Domains and AASA files when switching between environments? I have an iOS application that supports multiple environments (test and production). Each environment has its own domain and its own AASA file. We have an SDK that requires a domain during initialization. Based on the selected environment, we initialize the SDK with either the test domain or the production domain. We have configured the Associated Domains capability in Xcode with the required domains. However, i'm unclear about how iOS manages the AASA association in this scenario. For example: test.example.com Has its own AASA file. Used when the SDK is initialized with the test domain. example.com Has its own AASA file. Used when the SDK is initialized with the production domain. The SDK receives the domain during initialization, and we dynamically select the domain based on the environment configuration. The question is: If multiple domains are configured in Associated Domains, does iOS fetch and cache the AASA file for all configured domains when the app is installed, or only for the domain currently being used by the application? If the application switches the SDK configuration from the test domain to the production domain (or vice versa) after installation, how does iOS know that it needs to fetch the AASA file for the new domain? Is there any supported way to force iOS to re-fetch the AASA file for a newly selected associated domain? Trying to understand the correct approach for supporting multiple environments when the SDK domain is selected dynamically at runtime. If both test and production domains are configured in Associated Domains, how does iOS determine which AASA file should be used when the SDK is initialized with a specific domain (for example, test)? Does iOS fetch and validate both AASA files upfront and then check only the matching domain at runtime, or does it dynamically fetch/check only the domain provided to the SDK?

We're seeing a behavior change with ILMessageFilterExtension on iOS 26 and would like to confirm whether this is expected or a regression. Environment iOS: 26.x Framework: IdentityLookup Extension type: ILMessageFilterExtension Behavior For a new sender: An incoming SMS arrives. handle(_:context:completion:) is invoked. The extension returns a classification. The conversation is moved to the Spam folder. Subsequent SMS messages in the same conversation are delivered to the Spam folder, but handle(_:context:completion:) is no longer invoked for any new messages. Expected behavior We expected the message filter extension to be invoked for every incoming SMS, regardless of the current conversation folder, allowing the extension to evaluate each message independently. Actual behavior Once the conversation is in the Spam folder, all subsequent messages bypass the extension completely. The extension receives no callback, making it impossible to: Re-evaluate new messages using updated filtering logic. Change the classification if sender reputation changes. Apply cloud-based or dynamic filtering policies on subsequent messages. Questions Is this behavior expected in iOS 26? Has the message filtering pipeline changed so that conversations already classified as Spam no longer invoke ILMessageFilterExtension? Is there any documented API or recommended approach to have the extension evaluate every incoming message for an existing Spam conversation? If this is not expected, is this a known issue? If anyone from Apple or other developers can confirm whether this is by design, it would be greatly appreciated.

WeatherKit consistently fails with the following error: WDSJWTAuthenticatorServiceListener.Errors Code=2 This happens on a physical device regardless of the troubleshooting steps I try. After the error occurs, the app uses a third-party fallback provider successfully. The issue appears similar to failures reported by other developers on iOS 26, even though the WeatherKit entitlement and signing configuration seem valid. I have verified the following: • The signed application binary contains the WeatherKit entitlement. • The embedded provisioning profile contains the WeatherKit entitlement. • The application identifier and team identifier match the provisioning profile. • The WeatherKit capability was disabled, saved, enabled again, and saved. • Xcode automatic signing generated a new provisioning profile after resetting the capability. • The project was cleaned and a fresh build was installed on the physical device. • Both the application and the device were restarted. • Location permission is granted and the app receives valid coordinates. • Network connectivity works correctly. • A non-Apple fallback weather provider successfully returns a forecast for the same coordinates. Despite this, every WeatherKit request still fails with WDSJWTAuthenticatorServiceListener.Errors Code=2. Has anyone identified the cause of this error on iOS 17 or 26 or found an additional signing, entitlement, App ID, or provisioning step required to resolve it? Environment: • iOS version: iOS: 26.6 (23G71) • Xcode version: 26.5 • Device: iPhone 14 Pro • WeatherKit API used: WeatherService.shared • Distribution method:TestFlight

See crash details here:- https://pastebin.com/i9u5PE4X There's a comprehensive thread here, folks! https://discussions.apple.com/thread/255651156?sortBy=oldest_first Thanks for any thoughts.

~5% of our users when downloading the iOS application from the Apple Store for the first time are unable to enrol a Passkey and experience an error saying the application is not associated with [DOMAIN]. The error message thrown by the iOS credentials API is "The operation couldn't be completed. Application with identifier [APPID] is not associated with domain [DOMAIN]" We have raised this via the developer support portal with case id: 102315543678 Question: Why does the AASA file fail to fetch on app install and is there anything that can be done to force the app to fetch the file? Can this bug be looked at urgently as it is impacting security critical functionality? Other Debugging Observations We have confirmed that our AASA file is correctly formatted and hosted on the Apple CDN. Under normal circumstances the association is created on install and Passkey enrolment works as intended. We have observed that when customers uninstall/reinstall the app this often, but not always, resolves the issue. We also know this issue can resolve itself overtime without any intervention. We have ruled out network (e.g VPN) issues and have reproduced the issue across a number of different network configurations. We have ruled out the Keychain provider and have reproduced it across a variety of different providers and combinations of. We observed this across multiple versions of the iOS operating system and iPhone hardware including the latest hardware and iOS version.

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.

I am investigating premature DeviceActivityMonitor.eventDidReachThreshold callbacks on physical devices running iOS 26.x. I have also observed similar overcounting behavior on iOS 18.x. In one repeatable test, an all-activity event configured with a 10-minute threshold fired after approximately 5 minutes of actual unlocked usage. The event was created with: A single completion threshold. includesPastActivity: false. A nonrepeating DeviceActivitySchedule. A unique activity and event identity for each monitoring generation. However, eventDidReachThreshold could still arrive significantly earlier than expected. Defensive mitigation I have been testing a defensive mechanism that treats eventDidReachThreshold only as a wake-up signal, rather than authoritative proof that the configured usage duration has elapsed. When the callback arrives, the monitor extension independently validates the duration against locally persisted timing state. The flow is: Each logical work cycle has a unique cycle identifier and generation number. The app stores a local timing anchor when monitoring begins or resumes. When the threshold callback arrives, the extension verifies: The cycle identifier. The generation number. The activity name. The current application state. The extension calculates a locally trusted elapsed duration. If the local duration has not reached the configured duration: It does not send a notification. It does not apply any user-visible action. It persists only the locally trusted progress. It increments the generation number. It stops the previous monitor. It registers a new event for only the locally remaining duration. Completion is accepted only when the locally calculated duration is due. Delayed callbacks from previous generations are ignored. Simplified pseudocode: override func eventDidReachThreshold( _ event: DeviceActivityEvent.Name, activity: DeviceActivityName ) { let state = loadPersistedState() guard eventMatchesCurrentGeneration( event: event, activity: activity, state: state ) else { // Ignore stale or duplicated callbacks. return } let now = Date() let trustedElapsed = calculateLocallyAccountedElapsed( state: state, now: now ) let tolerance: TimeInterval = 3 if trustedElapsed + tolerance < state.configuredDuration { let remaining = state.configuredDuration - trustedElapsed var nextState = state nextState.confirmedElapsed = trustedElapsed nextState.generation += 1 // Persist the new generation before replacing the monitor. persistAtomically(nextState) center.stopMonitoring([activity]) let nextActivity = makeActivityName( cycleID: nextState.cycleID, generation: nextState.generation ) let completionEvent = DeviceActivityEvent( threshold: normalizedDateComponents(remaining), includesPastActivity: false ) do { try center.startMonitoring( nextActivity, during: makeNonRepeatingSchedule(), events: [ makeCompletionEventName(nextState): completionEvent ] ) } catch { // Persist a recoverable unavailable state. recordMonitoringFailure(error) } return } transitionToCompletedState() scheduleUserNotification() } Durations are normalized before creating the event: func normalizedDateComponents( _ duration: TimeInterval ) -> DateComponents { let seconds = max(1, Int(duration)) return DateComponents( minute: seconds / 60, second: seconds % 60 ) } This avoids using values such as second: 300. Example For a configured duration of 10 minutes: DeviceActivity incorrectly delivers the completion callback after approximately 5 minutes. Local accounting reports only approximately 5 minutes. No notification or other user-visible action is performed. The previous monitor is replaced with a new generation configured for the remaining approximately 5 minutes. Completion is accepted only after the locally trusted timing state is due. This mechanism has so far prevented premature DeviceActivity callbacks from producing premature notifications during my physical-device testing on iOS 26.x. Additional precautions The implementation also uses the following precautions: Only one completion event is registered instead of multiple minute checkpoints. includesPastActivity is explicitly set to false. Every replacement monitor has a new generation identity. Generation state is persisted before the old monitor is replaced. Callbacks from an old cycle, generation, or activity name are ignored. The extension performs only small, bounded state updates. User-visible actions occur only after local validation succeeds. Limitations This is a defensive workaround, not a fix for the underlying DeviceActivity or Screen Time accounting issue. Known limitations include: It cannot prevent iOS from delivering an incorrect callback. If the system never delivers another callback, completion may be delayed or missed. If every new event immediately fires, repeated re-registration may occur. startMonitoring may fail if the system considers the activities too numerous or too tightly scheduled. Local unlocked-time accounting depends on reliable lock and unlock observations. Wall-clock calculations must consider manual system-time changes. The approach cannot correct Screen Time’s internal activity data. For modes that intentionally count locked time, absolute local-notification scheduling may be more reliable and may avoid DeviceActivity thresholds entirely. All processing in this mitigation occurs on-device. It does not require uploading activity tokens, Screen Time data, user identifiers, or diagnostic logs. The implementation uses only public APIs. Questions for Apple Is treating eventDidReachThreshold as a wake-up signal and validating it against locally persisted timing state an acceptable design? Is stopping the current monitor and registering a new generation for only the locally remaining duration from the monitor extension considered a supported recovery pattern? Are there documented or recommended limits, rate controls, or backoff requirements for this type of defensive re-registration? Is there a more reliable supported API for usage-based completion when eventDidReachThreshold fires prematurely on iOS 26? I would appreciate confirmation from Apple engineers or feedback from other developers who have tested a similar approach.

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?

Configuring a VPN with includeAllNetworks causes CarPlay / Netflix Cast. Even enabling excludeLocalNetworks does not resolve this issue. Is this a known issue and can we work around this?

Overview I would like to observe calendar changes using NotificationCenter.messages(of: for:) I want receive Sendable messages, not traditional Notification which is not Sendable Problem I can't seem to get the following code to compile import EventKit NotificationCenter.default.messages( of: EKEventStore.EventStoreChanged.Subject.self, for: .changed ) Reference https://developer.apple.com/documentation/foundation/notificationcenter/messageidentifier/changed-50yz5 Questions How can I use by using NotificationCenter.messages(of: for:) for Calendar changes?