I’m looking for clarification on what iOS currently allows third-party apps to do in these areas: Siri integration and background voice activation: Can an iOS app implement a custom voice assistant that responds to a wake phrase such as “Hey Nowa” and performs app tasks through voice commands? Could it listen while the app is terminated or the iPhone is locked, similar to Siri? Call recordings: Is there a supported way for an iOS app to access recordings of phone calls made on the user’s iPhone and make them available within the app? I couldn’t find documentation for an API that provides access to these recordings. SMS access: Is there a supported way for an iOS app to access and fetch all SMS and iMessage conversations stored in the user’s Messages app, so they can be viewed within our app? As far as I understand, iOS may not allow these capabilities for third-party apps, but I’d appreciate clarification. If any are supported, could you please point me to the relevant Apple documentation?

Hello fellow developers, I’ve been working with the CallKit framework in iOS, specifically handling incoming calls. One issue I’ve encountered is that Siri when "read caller name" is enabled announces the caller name/surname set via localizedCallerName and then reads the generic handle value (usually alphanumeric) too! Has anyone encountered a similar situation or if there’s a solution to prioritize the localizedCallerName over the generic handle value without using CXHandleType.emailAddress? Alternatively, any insights or workarounds you know would be greatly appreciated. TLDR: even when I correctly configure the localizedCallerName property, Siri persists in reading the CXHandleType.generic. The original Implementation with CXHandleType.generic: The issue arises when using CXHandleType.generic for alphanumeric IDs (or even URLs as stated by documentation https://developer.apple.com/documentation/callkit/cxhandle). Despite correctly setting the localizedCallerName, Siri continues to announce the generic handle value. Expected Behavior: Siri should read only the localizedCallerName when set and ignore the generic handle value when announcing incoming calls. Workaround: Currently, the only workaround is to use CXHandleType.emailAddress for alphanumeric IDs. However, this is not ideal since it repurposes an email-related handle type for a different purpose. Steps to Reproduce: Create a CallKit app that handles incoming calls (example app from documentation can be used too). On incoming call create CXCallUpdate object Create a CXHandle with CXHandleType.generic and an alphanumeric value (e.g., “ABC123”). Pass the CXHandle to the CXCallUpdate objects' remoteHandle. Set the localizedCallerName property of the CXCallUpdate object with a custom caller name/surname. Report the call with reportNewIncomingCallWithUUID Observe that Siri reads both the localizedCallerName and the generic handle value during call announcements. While we are here a Feature Request: Developers should be able to provide a user-friendly caller name without resorting to workarounds like using CXHandleType.emailAddress. I kindly request that Apple consider enhancing Siri’s behavior in the following ways: Allow developers to suppress the reading of generic handle values while still using the correct handle type. Introduce additional type options for call announcements that don't read the generic value. Both of the above. Thank you for your help! 🙌

I am unable to dismiss Voice Control Siri AI bubble when enabling Voice Control in iOS 27. Can someone from accessibility team provide guidance on how to dismiss without touching the screen in the activation flow? Siri bubble remains on screen... Thank you, and appreciate all the work you do. Voice Control is an amazing capability system wide.

My phone no longer shows the waitlist for Siri and has the option to "Try New Siri." I select it, continue, continue and the settings change to "Siri (Beta)" and the waitlist option is no longer there, but when using Siri it's the old pre-Apple Intelligence Siri that activates (little bubble at the bottom) and it does not work. Going to Safari and typing "Siri://" opens the New Siri App, but it says "Siri Update in Progress; Adding support for Siri hasn't completed. Open Settings to check the status." The app does not show up in Spotlight. My phone is done Indexing and all signs point to my phone being enrolled to use the New Siri, but it isn't working at all and still has not shown up. I've tried restarting a few times. Anyone experiencing this too?

I want to share a Siri / Apple Intelligence issue I have been troubleshooting since the iOS 27 beta cycle, together with the configuration that finally resolved it. The issue started during iOS 27 beta, continued across multiple beta builds, and was still present after I updated to the official iOS 27 release. Updating iOS alone never fixed it. The main problem was that Siri / Apple Intelligence repeatedly failed to complete activation. Settings would remain stuck on: “Adding support for Siri is in progress” The Siri app would sometimes show: “Siri is not available” Siri also frequently fell back to the older floating-sphere interface instead of using the newer glowing-edge interface. Sometimes the new Siri interface would suddenly appear and work normally, but later it would fall back again. The most repeatable symptom involved charging. When the iPhone was connected to power, Siri sometimes appeared to finish downloading and would temporarily work normally. After disconnecting the charger, Siri could become unavailable again or the system would behave as though Siri resources still needed to be downloaded. Connected to power → Siri sometimes worked normally Disconnected from power → Siri could return to downloading / unavailable There was also a difference between Wi-Fi and cellular data. On cellular data, iOS sometimes said Wi-Fi was required to continue downloading Siri resources. After connecting to Wi-Fi, it would return to “Adding support for Siri is in progress” and still fail to finish. Apple Intelligence storage also behaved abnormally. At one point, iPhone Storage showed approximately 7.37 GB in use. Later, the Apple Intelligence entry disappeared and storage usage decreased, then reappeared after changing language settings. Before finding the working configuration, I had already tried restarting, Reset All Settings, Recovery Mode update, multiple iOS 27 beta builds, the official iOS 27 release, different Wi-Fi networks, cellular data, disabling VPN/proxy, changing languages, removing additional languages, switching between old and new Siri, and leaving the phone on Wi-Fi and power for long periods. None provided a permanent fix. After repeated testing, the issue appeared to involve network transport, routing consistency, Siri language / voice configuration, Siri AI authorization, and local asset refresh. My final working setup was: System language: English (United States) Region: United States Siri language: English (United States) Siri voice: American Apple Intelligence enabled Proxy environment: Shadowrocket Proxy transport My proxy node uses an AnyTLS-based configuration. Previously, UDP traffic was enabled. During troubleshooting, some Apple / iCloud requests appeared unreliable when using UDP / QUIC through this node, with timeouts, resets, or repeated retries. I changed the node transport to TCP only while keeping TLS enabled: TCP + TLS After this change, Apple-related authentication and asset requests appeared much more stable. Routing rules This was one of the most important changes. I use split tunneling so that Chinese apps can remain DIRECT while selected traffic uses the proxy. However, some Apple traffic was being matched by broader fallback rules such as: apple.com,DIRECT GEOIP,CN,DIRECT This meant some Siri / iCloud / Apple Intelligence requests could use the proxy while related requests went directly through the local connection. I added these high-priority rules and moved them above broader Apple / DIRECT / GEOIP rules: DOMAIN-KEYWORD,gateway,PROXY DOMAIN-KEYWORD,probe,PROXY DOMAIN-KEYWORD,gdmf,PROXY DOMAIN-KEYWORD,guzzoni,PROXY DOMAIN-SUFFIX,iphone-ld.apple.com,PROXY Rule priority was important. If broader DIRECT rules were above these entries, the specific traffic could still bypass the proxy. After moving these rules to the top, the relevant Apple traffic consistently followed the same network path. Split tunneling still worked normally, and apps such as WeChat, Alipay, Meituan, and Xiaohongshu could remain DIRECT. Language and Siri configuration I standardized the Siri environment: System Language: English (United States) Region: United States Siri Language: English (United States) Siri Voice: American I selected an American Siri voice, such as Voice 4. After changing everything to the same English (US) environment, asset loading became more consistent. Enable Siri AI I manually selected: Try Siri AI (Beta) and completed the authorization process. I also temporarily disabled “Require Face ID” for the standalone Siri app while troubleshooting. I cannot confirm that this directly affected the download, but it removed an extra authentication layer while testing. Refresh local language assets I opened Apple’s built-in Translate app, deleted the downloaded English (US) language package, and downloaded it again. My goal was to refresh the local language / MobileAsset download state. I cannot confirm that Translate directly controls Siri’s generative models, but this appeared to help clear the remaining stuck asset state. Final installation step After making all of the above changes, I connected the iPhone to Wi-Fi and power, locked the screen, and left the device idle for approximately 10–15 minutes. After this, the Siri / Apple Intelligence state finally changed and remained stable. Current result: Siri consistently uses the full-screen glowing-edge interface Type to Siri works correctly Siri no longer falls back to the legacy floating-sphere interface “Siri is not available” no longer appears “Adding support for Siri is in progress” is no longer permanently stuck Apple Intelligence remains active Siri continues working after disconnecting the charger Split tunneling still works normally Most importantly, the previous charging-related behavior is gone. Before: Connected to power → Siri temporarily worked Disconnected from power → Siri failed again Now: Siri continues to work normally whether or not the device is connected to power. I am not claiming that Apple has officially documented every domain or internal process above as the root cause. These findings are based on repeated troubleshooting and network behavior observed on my own device. However, this issue persisted from the iOS 27 beta cycle through the official iOS 27 release, and standard system updates alone did not resolve it. In my case, the successful fix only came after correcting the combination of: TCP transport + consistent Apple routing + English (US) system / Siri configuration + Siri AI authorization + local asset refresh. If anyone else is experiencing “Adding support for Siri is in progress,” “Siri is not available,” repeated fallback to the legacy Siri UI, Apple Intelligence storage disappearing / reappearing, or Siri working while charging but failing after unplugging, I would be interested to know whether the same configuration also resolves the issue on other devices.

I had a complete voice-only experience working with AppIntents and AppShortcuts on iOS 27.0 prior to enabling Siri AI. Once I enabled Siri AI, Siri refused to recognize any of the donated phrases in one particular AppShortcut. It still worked for several others. For the AppShortcut that no longer works, Siri responds to some of the phrases claiming the app doesn't support that action through Siri, and Siri responds to some of the phrases telling me I need to open the app to do that. FB24854409 includes a Sysdiagnose file. Note that I'm aware of App Schemas, but none apply well to my app.

I’m seeing a reproducible UI bug with Spotlight on macOS 27 RC (26A428). The issue has been present since at least build 26A5416b (Developer Beta 6 / Public Beta 4), persisted through subsequent beta releases, and is still reproducible on RC 26A428. When I open Spotlight using the new Search or Ask interface and begin typing, the entered query text can become completely invisible from approximately the second character onward, even though Spotlight continues searching and displaying results normally. The interesting part is that the issue seems tied to Spotlight updating its search results. For example: Open Spotlight. Type a character that quickly matches something on the Mac. Continue typing. Once the results update, the query text becomes invisible. If I type random characters extremely quickly, before Spotlight has time to return a result for the first few characters, the text may remain visible. Another useful detail: after the query text disappears, pressing Delete/Backspace causes it to become visible again. The search itself is still functioning, the problem appears to be with rendering or state updates in the new Siri-integrated Spotlight query field, rather than with Spotlight search/indexing itself. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by user preferences, caches, login items, or third-party software. I submitted a screen recording through Feedback Assistant that clearly shows the text disappearing as results update. Feedback: FB24462893 Is anyone else seeing this on the RC? The correlation between the text disappearing and the results UI updating makes me suspect a rendering/state-update issue in the new Spotlight interface.

I have a photo editing app that owns no photo library. I want a user viewing an image in another app (e.g. Photos) to say "filter this image in MyApp" and have Siri hand that on‑screen image to my intent. Targeting iOS 27. What I've tried, and the result in each case: • App Shortcut + @Parameter var image: IntentFile — Siri resolves my other parameters (a filter AppEnum) by voice, but never binds the image; the run fails. • @AppIntent(schema: .photos.setFilter) with a .photos.asset entity — never routes from Photos. • @AppIntent(schema: .system.open): OpenIntent with a custom AppEntity target — "Open this image in MyApp" just launches the app by name; perform() is never called, and the entity query never runs. My understanding from WWDC26 "Build intelligent Siri experiences with App Schemas" (session 240) and "Discover new capabilities in the App Intents framework" (session 345): • Cross‑app content transfer (Transferable + IntentValueRepresentation) seems limited to system value types (IntentPerson, PlaceDescriptor); IntentFile is not a _SystemIntentValue, so an image can't ride that rail. • Onscreen awareness (NSUserActivity.appEntityIdentifier, View Annotations) appears to expose only the foreground app's own content — which here is Photos, not me. Question: Is there a supported way for a third‑party app to receive another app's on‑screen image (vs. a contact/place) through Siri/App Intents today? If so, which API carries the pixels — an IntentFile parameter, @UnionValue, IntentValueQuery, something else — and what must the source app do to make it available? Or is asking "do X to this image in <third‑party app>" simply not supported yet outside Shortcuts?

Since iOS 18, I have an OpenIntent to open documents. For Siri AI, I understood that I need to annotate the entity with @AppIntent(schema: .system.open) for Siri AI to be able to open documents. This is only supported starting with iOS 27. I tried duplicating the intent (one for iOS 27, one for the other versions), however, Xcode complains and says that only one OpenIntent is possible per target entity. How are we supposed to: support Siri AI "open" functionality preserve functionality for older iOS versions ? Thank you

Hello, I'm a EU-based developer. Our app is distributed worldwide. I'd like to clarify the following regarding Siri AI and EU: is Siri AI unavailable to users based in EU, or to apps based in EU. In other words, will my app developed in Europe work with Siri AI for US users? Or the fact that my app is developed in Europe excludes it from compatibility with Siri AI? Kind regards, Bruno

My intents and entities show up in Shortcuts, and my tests that use App Intents Framework pass. But I can't for the life of me figure out why Siri won't work. I'm trying phrases like "Add to my list in ". All I ever get from Siri is variations of "I can't add items directly to " or "I can't add items to your lists in ". Does anyone see any issues with the following? ( I've left out some of the AppEnum and Entity types for brevity, but these are the main ones) @AppIntent(schema: .reminders.createReminder) struct AddToListIntent { var title: String var list: ListEntity? var note: AttributedString? var isFlagged: Bool? var images: [IntentFile] var tags: Set<String> var urls: [URL] var dueDate: DateComponents? var recurrence: Calendar.RecurrenceRule? var locationTrigger: LocationTriggerEntity? var section: SectionEntity? func perform() async throws -> some ReturnsValue<ReminderEntity> { let newReminder = ReminderEntity(id: "foo", reminder: .init(name: title)) return .result(value: newReminder) } } struct Reminder { var name: String } @AppEntity(schema: .reminders.reminder) struct ReminderEntity { // MARK: Static static let defaultQuery = ReminderEntityQuery() // MARK: Properties let id: String let reminder: Reminder @ComputedProperty(title: "Title") var title: String { reminder.name } var note: AttributedString? { nil } var tags: Set<String> { Set() } var urls: [URL] { [] } var dueDate: DateComponents? { nil } var recurrence: Calendar.RecurrenceRule? { nil } var isCompleted: Bool { false } var isFlagged: Bool? { nil } var creationDate: Date? { nil } var completionDate: Date? { nil } var list: ListEntity var locationTrigger: LocationTriggerEntity? { nil } var displayRepresentation: DisplayRepresentation { .init(title: "\(title)") } // MARK: Query struct ReminderEntityQuery: EntityQuery, EnumerableEntityQuery { func entities(for identifiers: [ReminderEntity.ID]) async throws -> [ReminderEntity] { identifiers.map { .init(id: $0, reminder: .init(name: "Foo")) } } func allEntities() async throws -> [ReminderEntity] { ["foo", "bar", "baz"].map { ReminderEntity(id: $0, reminder: .init(name: $0)) } } } } @AppEntity(schema: .reminders.list) struct ListEntity: AppEntity, IndexedEntity { let id: String let myName: String var name: String { myName } // 3. Define how this entity is displayed to the user in shortcuts/Siri var displayRepresentation: DisplayRepresentation { DisplayRepresentation(title: "\(myName)") } @Property var type: MyListType // 4. Provide a query so the system can resolve specific lists static var defaultQuery = ListEntityQuery() }

We found an apparent iOS 27 WorkflowKit bug when implementing: @AppIntent(schema: .photos.editAsset) with an entity conforming to: @AppEntity(schema: .photos.asset) Despite Apple’s general guidance that schema entity types may be renamed, Siri only worked when our entity’s Swift type was named exactly AssetEntity. Controlled on-device results: AssetEntity — works PhotoAssetEntity — fails FooAssetEntity — fails For the failing names, neither the entity query nor perform() was reached. WorkflowKit logged: Failed to retrieve entity metadata Error Domain=WFActionErrorDomain Code=6 Siri responded: Unable to retrieve the data information to process. The generated App Intents metadata was internally consistent, and the issue persisted across clean installs and a device restart. Current workaround: name the .photos.asset entity type exactly AssetEntity. Tested with Xcode 27.0 beta (27A5252f) and iPadOS 27.0 (24A5423a). Filed with Apple as FB24604095 for anyone from Apple investigating this behavior.

When trying to access new Siri in macOS 27 beta 7 it always showing 'I’m having trouble with the connection. Please try again later.'. Tried changing the language multiple times and restarted the mac as well. But nothing resolved the issue. Has anybody faced this issue. is this related to network settings ?.

Hi all, I’m seeing what looks like a bug with AppShortcutParameterPresentation and the Shortcuts app. Any time I provide an OptionsCollection to a shortcut so I can give it a nice category name and symbol in Shortcuts, it hides all other existing app shortcuts that my app has from the UI. I have created a sample that illustrates the problem. My app provides two App Shortcuts: A simple shortcut with no parameters. A shortcut with two parameters. Its Destination parameter uses AppShortcutParameterPresentation to generate “Home” and “Office” options in a separate section. When the second shortcut is present, the first parameterless shortcut disappears from the Shortcuts app. If I comment out the shortcut containing parameterPresentation, the parameterless shortcut appears again. Before commenting out: After commenting out the second shortcut: Here's the code: import AppIntents struct ParameterlessIntent: AppIntent { static let title: LocalizedStringResource = "Parameterless Intent" static let description = IntentDescription("Runs without asking for any parameters.") func perform() async throws -> some IntentResult { .result() } } struct ParameterizedIntent: AppIntent { static let title: LocalizedStringResource = "Parameterized Intent" static let description = IntentDescription("Runs with a destination and a copy count.") // The same provider is used by this parameter and by ParameterPresentation below. @Parameter( title: "Destination", optionsProvider: DestinationOptionsProvider() ) var destination: String @Parameter(title: "Copy Count", default: 1) var copyCount: Int static var parameterSummary: some ParameterSummary { Summary("Send \(\.$copyCount) copies to \(\.$destination)") } func perform() async throws -> some IntentResult { .result() } } nonisolated struct DestinationOptionsProvider: DynamicOptionsProvider { func results() async throws -> [String] { // Each generated App Shortcut option is a value for the Destination parameter. ["Home", "Office"] } } struct BugReproductionShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { // This parameterless shortcut should always appear in the Shortcuts app. AppShortcut( intent: ParameterlessIntent(), phrases: [ "Run the parameterless shortcut with \(.applicationName)" ], shortTitle: "Do I exist?", systemImageName: "1.circle" ) #warning("The presence of this shortcut causes the top one no longer appear in Shortcuts.app") AppShortcut( intent: ParameterizedIntent(), phrases: [ "Run the parameterized shortcut with \(.applicationName)" ], shortTitle: "Parameterized Shortcut", systemImageName: "2.circle", parameterPresentation: ParameterPresentation( for: \.$destination, summary: Summary("Send to \(\.$destination)") ) { // This title and symbol create a separate section in Shortcuts. OptionsCollection( DestinationOptionsProvider(), title: "Destination Shortcuts", systemImageName: "mappin.and.ellipse" ) } ) } } This code and reproduction is as of Xcode 27 Beta 6 and happens on older versions as well. Is there a known limitation with this or is this somehow expected behavior? If so, how can I mitigate this issue and provide a nice title for another shortcut, while keeping the old parameterless shortcuts present? Thanks!

Hi everyone, I am currently implementing the new Search API in a UIKit app using @AppIntent(schema: .system.search), ShowInAppSearchResultsIntent, and UISceneAppIntent. While testing on the iOS beta, I’ve hit a significant lifecycle disparity between how UIKit and SwiftUI apps process system intents during a process-cold launch. According to the documentation for UIScene.ConnectionOptions.appIntent, this property should contain the intent that triggered the scene creation. However, in a UIKit app with a single-window scene lifecycle, this isn't happening consistently. Here is the behaviour breakdown I am seeing: Cold Launch (Siri/Search → App completely closed) SwiftUI App: Works as documented. The intent is present in connection options. scene(_:willPerformAppIntent:) is not called. UIKit App (with AppIntentSceneDelegate): The connectionOptions.appIntent property is completely nil inside scene(:willConnectTo:options:). Instead, the intent is delivered late via scene(:willPerformAppIntent:) right after scene connection completes. Warm Launch (Siri/Search → App already suspended in memory) Both SwiftUI and UIKit: Behave identically. The intent is delivered directly to scene(_:willPerformAppIntent:). The Problem Because of this gap, there is no unified way to handle a process-cold launch under UIKit. There is no LaunchOptionsKey available to identify that an App Intent initiated the launch, and the missing connection option forces us to bifurcate our routing logic. I have already filed a bug report via Feedback Assistant: FB24513291 and attached a minimal reproducible sample project. Has anyone else run into this specific AppIntentSceneDelegate race condition on the iOS beta? If so, what architecture or unified pattern are you using to normalize the lifecycle routing between cold and warm launches in UIKit? Any insights or clean workaround ideas would be highly appreciated!

Hi, it seems that something in OS27b3 changed regarding Core Spotlight: Whatever I try, Siri and Spotlight only seem to find the text inside the title or displayName attribute. But attributes like textContent or contentDescription or keywords seem to be ignored. Those attributes are still found, when I do a manual search using CSUserQuery or using the AppEntityDefinition.spotlightQuery(_:) in App Intent Testing. I have already filed a Feedback – but wonder whether anyone else is having this issue? FB23635795 Thanks, Friedrich

Apple's 8 June 2026 announcement states that developers in the EU will not be able to test or use the new Siri AI features in their apps for iOS 27, iPadOS 27 or watchOS 27. I am an EU-based developer building apps for users in multiple markets. App Intents Testing, simulator checks and unit tests can validate parts of an implementation, but they do not appear to replace end-to-end validation of Siri AI behaviour on supported iPhone and iPad hardware. What is Apple's supported route for an EU-based developer to validate the following for users in supported markets? • intent discovery and invocation • parameter resolution and follow-up interaction • error handling and confirmation flows • Siri's presentation and completion of an action • behaviour on supported physical devices Is an official remote-device environment, controlled developer testing mode or another Apple-supported arrangement available or planned? I am not asking for a way to bypass regional restrictions. I am looking for documented, compliant testing guidance for developers serving a global App Store. I have filed Feedback Assistant report FB24276767 about this testing-access issue. Apple source: https://www.apple.com/newsroom/2026/06/due-to-dma-siri-ai-delayed-in-eu-for-ios-27-and-ipados-27/

As App Intents power multi-step workflows via Siri, Shortcuts, Spotlight, and Apple Intelligence, I would like to request a platform pre-action policy surface: Before intent perform(): input: intent_id, parameters, caller_agent_id, session_id, risk_hints output: allow | warn | deny | require_confirmation side: local audit_receipt Why this is needed Sandbox and TCC solve app isolation and one-time permission grants. Multi-step agentic loops introduce a different risk shape: Destructive tool selection from noisy natural language2. Uncapped retry / network loops3. Unauthorized data movement across app boundaries4. Financial / identity / Wallet actions that need dual control even when the app is already authorized Prompt-only or documentation-only guidance is not enforceable mid-loop. Apple-aligned properties On-device evaluation by default (privacy)- Complements TCC / sandbox â does not replace them- User-visible WARN / DENY with recoverable explanation- Optional Instruments-style â agent action timelineâ with gate verdicts Risk classes (map to entitlements mental model) | Class | Example | Default posture || --- | --- | --- || Read local | calendar, on-screen text | Allow / low friction || Cross-app write | paste into finance app | Warn or confirm || Destructive | delete, wipe, revoke | Deny or hard confirm || Network exfil | send sensitive context off-device | Deny until confirm || Financial / Wallet | transfer, mint pass | Always confirm | Related discussion There is already an excellent thread on pre-effectuation / execution finality for high-consequence App Intents. This request is complementary: a first-class, developer-visible pre-action hook (ALLOW / WARN / DENY / CONFIRM) at the intentâ action boundary, plus local audit receipts. Shipping reference (independent OSS control plane) I ship ThumbGate (npm thumbgate) â a local-first pre-action firewall used today for AI coding agents: PreToolUse / MCP interception, ALLOW/WARN/DENY, thumbs feedback â prevention rules. Public: https://thumbgate.ai · https://github.com/IgorGanapolsky/ThumbGate I will also file this as a Feedback Assistant Suggestion. Looking for: Confirmation this belongs under App Intents / Apple Intelligence2. Any existing API I missed for third-party or system-level pre-perform gates3. The right internal owner / Feedback area if this should go through a different channel Happy to share a one-pager with the risk taxonomy and proposed hook shape.

Environment: iPadOS 27 Beta (Developer Beta) iPad with Bluetooth Classic (iAP2/ExternalAccessory) + BLE active session App uses UIKit, WKWebView, scene-based lifecycle Problem: When the user invokes the new Siri AI by long-pressing the power button while our app is in the foreground with an active Bluetooth Classic session, we observe: No scene lifecycle callbacks fire — no sceneWillResignActive, no sceneDidEnterBackground, nothing. We confirmed by logging every UISceneDelegate method. Main thread / data processing threads are starved for ~2 seconds, causing a backlog of incoming Bluetooth data. Our real-time data processing latency jumps from ~105ms to over 2,300ms within 2 seconds of Siri activation. CADisplayLink / requestAnimationFrame callbacks show a ~935ms gap coinciding with the Siri overlay appearance, then irregular intervals afterward. The Bluetooth Classic transport (ExternalAccessory/iAP2) remains physically connected throughout — the issue is purely host-side processing starvation. What we've ruled out: BLE link degradation: firmware-side diagnostics confirm 100% data delivery, 0 lost packets during the incident Memory pressure from our app: our process memory stays flat; system-available memory drops ~14 units externally Questions: Is the absence of sceneWillResignActive when Siri AI activates on iPadOS 27 intended behavior, or a beta bug? The new UIApplication.systemPrefersReducedResourceUsage property (iPadOS 27 beta) — is this intended to signal system overlays like Siri consuming resources? Does the corresponding systemPrefersReducedResourceUsageDidChangeNotification fire when Siri activates? Are there recommended patterns for apps with real-time Bluetooth data processing to maintain thread priority during system overlays? We currently use default QoS for our data processing dispatch queues. The processing starvation causes the waveform display to degrade (appears as a connectivity issue to the clinician) even though the wireless link is healthy. We need either: A notification that a system overlay is active, so we can adjust our UI accordingly Guidance on maintaining processing priority during Siri AI activation Any community insight on workarounds would be highly appreciated. Thanks.

I would like to discuss a possible security architecture for Siri, Apple Intelligence, and App Intents where permission to invoke an app action is separated from permission for that specific action to become externally effective. For low-risk actions, existing authorization may be sufficient. However, for higher-consequence actions—such as payments, file export, message transmission, account changes, device control, or other irreversible operations—there may be value in introducing an additional execution-finality boundary. Problem Space An AI assistant may be authorized to invoke an App Intent, but that does not necessarily mean every resulting action should immediately become effective. For example: Siri may be allowed to invoke a payment-related intent, but not every amount or recipient should necessarily be executable. An app may expose a file-sharing intent, but a particular file or destination may fall outside the permitted scope. An AI-generated message may be validly created, but its final transmission may require additional execution-specific validation. Context, permission, destination, revocation state, or security state may change between intent generation and actual execution. The proposed distinction is: Permission to invoke an App Intent versus Permission for the specific resulting act to become externally effective Proposed Architecture A high-consequence action could first become a Candidate Act and remain in a Non-Effective State. Conceptually: Siri / Apple Intelligence ↓ App Intent ↓ Candidate Act ↓ Non-Effective State ↓ Protected Validation ↓ Scoped Execution Authority ↓ Finality Sink Verification ↓ External Effect If validation fails, expires, is revoked, is replayed, or becomes ambiguous: Default Denial → No External Effect Short Definitions Candidate Act The specific operation proposed by Siri, Apple Intelligence, or an app before it is allowed to create an external consequence. Non-Effective State A state in which the operation may be prepared, inspected, or evaluated but cannot yet produce its intended external effect. Protected Validation A validation step checking execution-relevant conditions such as app identity, user authorization, purpose, destination, scope, freshness, limits, revocation state, or device security state. Scoped Execution Authority Authority limited to the specific validated action rather than a broadly reusable permission. Finality Sink The consequence boundary where the action becomes externally effective—for example, a network transmission, file release, payment commit, database change, or physical-device action. Why This Could Be Useful This architecture could provide: separation of AI decision-making from final execution authority; fail-closed behavior for invalid or uncertain actions; resistance to replay or stale authorization; action-specific rather than broadly reusable authority; validation closer to the actual consequence boundary; stronger control for increasingly autonomous AI workflows. This would be intended as an optional mechanism for higher-consequence actions, not as a replacement for App Intents, existing user authorization, entitlements, sandboxing, or other Apple security mechanisms. Possible Interoperability Relevance This question may also become relevant as operating-system interoperability requirements evolve, including in the European Union under the Digital Markets Act. As third-party AI assistants and services gain deeper interoperability with operating-system features, there may be a need to distinguish between allowing an interoperating service to request an action and allowing that specific action to cross the final consequence boundary. A device-side execution-finality mechanism could potentially provide a technical middle layer: third-party AI services could request interoperable actions, while the operating system retains a neutral protected mechanism for validating the specific action immediately before it becomes externally effective. This may help explore how broader interoperability and strong device-side security could coexist without requiring unrestricted execution authority for either first-party or third-party AI assistants. I would be interested in whether Apple considers this type of consequence-boundary enforcement compatible with existing or future App Intents and interoperability architectures. Questions for Apple Engineers and Developers Does App Intents currently provide a supported mechanism for maintaining an action in a non-effective state until execution-specific authorization is verified? Where would Apple consider the correct enforcement point for such validation: App Intents, the host application, an OS-mediated service, or the actual consequence boundary? Is there an existing Apple framework or security primitive intended to provide this kind of action-specific, pre-effectuation execution authority? Would this model be relevant as Siri and Apple Intelligence gain the ability to perform more cross-app and agentic actions? Could an OS-mediated finality mechanism also provide a common security boundary for first-party and interoperating third-party AI assistants? I am particularly interested in understanding whether this should be considered an App Intents implementation pattern, an operating-system security concern, or a broader architectural mechanism for secure AI interoperability.