I've looked and looked and can't seem to find anything obviously wrong, so I'll ask here. Are NSTableViewAppIntentsDataSource protocol methods expected to be called? Have others had success with this? I've got an extremely trivial NSViewController subclass that conforms to NSTableViewDataSource, NSTableViewDelegate, NSTableViewAppIntentsDataSource. Things I've verified: The NSTableView is setup in a storyboard and the delegate and data source are connected to the view controller. In viewDidLoad while attached to the debugger I see this works. The table view includes a single row and appears populated when running the app. There seems to be no way to assign the appIntentsDataSource view controller in the storyboard, so that's assigned in code in viewDidLoad for the view controller. I can confirm it's correctly set in the data source methods for the table view. I have an AppEntity conforming type and AppIntentsPackage conforming type in the project. I can look at the actionsdata in the built product to confirm the entity is registered. Here's the entirety of the view controller: class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate, NSTableViewAppIntentsDataSource { @IBOutlet var tableView: NSTableView! func numberOfRows(in tableView: NSTableView) -> Int { print("numberOfRows(in:)") return 1 } dynamic public func tableView(_ tableView: NSTableView, objectValueFor tableColumn: NSTableColumn?, row: Int) -> Any? { print("tableView(_:objectValueFor:row:)") return NSObject() } override func viewDidLoad() { super.viewDidLoad() tableView.appIntentsDataSource = self } override var representedObject: Any? { didSet { // Update the view, if already loaded. } } dynamic public func tableView(_ tableView: NSTableView, appEntityIdentifierFor row: Int) -> EntityIdentifier? { print("ViewController.tableView(_:appEntityIdentifierFor:)") return EntityIdentifier(for: MyFancyEntity.self, identifier: "1234") } } Unfortunately, while attached with a debugger, ViewController.tableView(_:appEntityIdentifierFor:) just never seems to be called.

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/

I keep running into rate limit issues that never go away while the app is running when trying to analyze images using Private Cloud Compute in iOS 27 Beta 6. After 20 or so images, I get a rate limit error from PCC, but the actual rate limit seems to come from SCML (see relevant log entries below). Once this happens, any attempted PCC requests result in an immediate rate limit error, no matter how long I wait, so long as the app is running. If I kill the app and relaunch, I no longer receive the rate limit error (unless, again I run several images through in succession). So it seems like once this state is triggered, you are stuck in it until you kill and relaunch the app. Has anyone else encountered this or have a workaround? I've filed a feedback already: FB24419603 Passing along Client rate limit exceeded, try again later in response to ExecuteRequest Passing along Client rate limit exceeded, try again later in response to ExecuteRequest systemPromptID failed for task textSafety: Rate limited. Wait a little bit and then try again.::Rate limited. Wait a little bit and then try again.: Client rate limit exceeded, try again later::Client rate limit exceeded, try again later; prompt template also not found: Rate limited. Wait a little bit and then try again.::Rate limited. Wait a little bit and then try again.: Client rate limit exceeded, try again later::Client rate limit exceeded, try again later End sanitizeText with error: Error Domain=com.apple.SensitiveContentAnalysisML Code=15 "SCML.CombinedTextSanitizerBackend.BackendError("SafetyGuardrailTextSanitizerBackend"): Rate limited. Wait a little bit and then try again." UserInfo={NSLocalizedDescription=SCML.CombinedTextSanitizerBackend.BackendError("SafetyGuardrailTextSanitizerBackend"): Rate limited. Wait a little bit and then try again., NSUnderlyingError=0x11a632ee0 {Error Domain=SensitiveContentAnalysisML.CombinedTextSanitizerBackend.BackendError Code=1 "SCML.CombinedTextSanitizerBackend.BackendError("SafetyGuardrailTextSanitizerBackend"): Rate limited. Wait a little bit and then try again." UserInfo={NSUnderlyingError=0x11a5dd380 {Error Domain=com.apple.GenerativeFunctionsFoundation.GenerativeError Code=1010000 "Rate limited. Wait a little bit and then try again."}, NSLocalizedDescription=SCML.CombinedTextSanitizerBackend.BackendError("SafetyGuardrailTextSanitizerBackend"): Rate limited. Wait a little bit and then try again.}}}

I’m trying to group my EntityPropertyQuery selection into sections as well as making it searchable. I know that the EntityStringQuery is used to perform the text search via entities(matching string: String). That works well enough and results in this modal: Though, when I’m using a DynamicOptionsProvider to section my EntityPropertyQuery, it doesn’t allow for searching anymore and simply opens the sectioned list in a menu like so: How can I combine both? I’ve seen it in other apps, but can’t figure out why my code doesn’t allow to section the results and make it searchable? Any ideas? My code (simplified) struct MyIntent: AppIntent { @Parameter(title: "Meter"), optionsProvider: MyOptionsProvider()) var meter: MyIntentEntity? // … struct MyOptionsProvider: DynamicOptionsProvider { func results() async throws -> ItemCollection<MyIntentEntity> { // Get All Data let allData = try IntentsDataHandler.shared.getEntities() // Create Arrays for Sections let fooEntities = allData.filter { $0.type == .foo } let barEntities = allData.filter { $0.type == .bar } return ItemCollection(sections: [ ItemSection("Foo", items: fooEntities), ItemSection("Bar", items: barEntities) ]) } } struct MeterIntentQuery: EntityStringQuery { // entities(for identifiers: [UUID]) and suggestedEntities() functions func entities(matching string: String) async throws -> [MyIntentEntity] { // Fetch All Data let allData = try IntentsDataHandler.shared.getEntities() // Filter Data by String let matchingData = allData.filter { data in return data.title.localizedCaseInsensitiveContains(string)) } return matchingData } }

A suspected RTL performance erratum in the Apple Neural Engine throttles DRAM weight streaming throughput down to 17–19 GB/s from the nominal 45–60 GB/s, whenever the total weight size is an integer multiple of 1 MiB. This was confirmed on M3 Macbook Air (2024) 24GB. 1 MiB is a common transfer size, and currently affects 7 of ANEMLL’s 15 baseline models. Avoiding the suspected problematic path in the kernel DMA's prefetch ring by splitting 1 MiB transfers into non-multiples of 1 MiB, directly increased Llama 3.2 1B token throughput from 10.0 to 24.3 tokens/s (DRAM usage from 24.7 to 60.0 GB/s), and Qwen3-8B from 1.36 to 2.97 tokens/s (DRAM usage from 22.4 to 48.7 GB/s). Please see writeup here: https://eiln.github.io/posts/ane-dma.html I'm looking to confirm that this behavior is reproducible on your side, and will provide the scripts in my plots.

Hi all, We're currently evaluating Private Cloud Compute (PCC) for a technical accuracy assessment. No production release or monetization is planned at this stage — our only goal is to test/evaluate the model. Per the official documentation, PCC access requires: Enrollment in the App Store Small Business Program Fewer than 2 million first-time downloads The Private Cloud Compute entitlement assigned to the account To complete Small Business Program enrollment, our Paid Applications Agreement is currently stuck at "User Information Pending", and we're being asked to submit a bank account and U.S. tax forms (Certificate of Foreign Status of Beneficial Owner / Substitute Form W-8BEN-E) before the agreement can go Active. Honestly, we're having a hard time accepting that submitting banking and revenue-related tax documentation is required when we have no intention of selling a paid app at all. The Small Business Program itself is meant to be a reduced-commission program for developers earning revenue through paid apps/IAP — using it as a gate for free AI model evaluation feels like a mismatch. On top of that, we're a Japan-based company, which raises the bar further. The required tax forms (W-8BEN-E etc.) are aimed at non-US entities and require pulling in our legal/finance teams just to prepare — a fair amount of overhead for what is, on our end, purely a technical evaluation. Before we go through the internal process of preparing this documentation, I wanted to confirm: Is there any path to obtain the PCC entitlement / Small Business Program status for evaluation purposes only, without completing the full Paid Applications Agreement (banking + tax forms)? Is submitting real banking and tax information a hard technical requirement of the Small Business Program itself (i.e., the Paid Apps Agreement cannot go Active without it), or can an account remain PCC-eligible while the agreement is "pending"? Is there an official Apple document (beyond the general Small Business Program / PCC pages) that explicitly confirms banking/tax submission is mandatory before PCC entitlement can be granted? We need something citable for internal approval. For non-US companies (e.g. Japan-based), has anyone gone through this purely for evaluation purposes? Is there any simplified path for foreign entities, or is the full W-8BEN-E process unavoidable? Any pointers to official documentation, or confirmation from anyone who has been through this, would be greatly appreciated — we need a clear, citable answer to justify preparing this documentation internally. Thanks in advance.

App intent has a perform method that is async and can throw an error, but I can't find a way to actually await the result and catch the error if needed. If I convert this working but non-waiting, non-catching code: Button("Go", intent: MyIntent()) to this (so I can control awaiting and error handling): Button("Go") { Task { do { try await MyIntent().perform() // 👈 } catch { print(error) } } } It crashes: AppDependency with key "foo" of type Bar.Type was not initialized prior to access. Dependency values can only be accessed inside of the intent perform flow and within types conforming to _SupportsAppDependencies unless the value of the dependency is manually set prior to access. Although it is invalid since the first version is working like a charm and dependencies are registered in the @main App init method and it is in the perform flow. So how can we await the result of the AppIntent and handle the errors if needed in the app? Should I re-invent the Dependency mechanism?

I ran into a gap in the MLXVLM → MLXLLM factory fallback and wanted to check whether this is expected behavior or something worth filing. Context: I maintain a Swift-native macOS agent built on MLX Swift, with a hardware-adaptive catalog of local models. I tried adding mlx-community/Qwen3.5-9B-4bit as a plain text model. Its config.json ships a full vision_config block — it looks like a multimodal config — but the actual checkpoint has no vision tower weights at all. It's genuinely text-only; the metadata just doesn't reflect that. ModelFactoryRegistry tries MLXVLM before falling back to MLXLLM. I expected that to fail cleanly and fall through, since there's no vision encoder to load. It doesn't. MLXVLM's Qwen35Configuration declares visionConfiguration as a non-optional property mapped to vision_config. Since the key is present in the raw config, decoding succeeds — there's nothing to catch at that stage. So MLXVLM proceeds to actually load the model as a VLM, and it crashes later, inside WiredMemoryUtils.tune(), because getRopeIndex() expects real vision-encoder dimensions to compute against, and there are none. Not a clean decode-time error I could catch — a runtime crash several layers past config parsing, in the RoPE indexing math. The workaround I ended up with is config-level surgery before the model reaches the factory at all: strip vision_config (and image_token_id / video_token_id) from the JSON first. With the key genuinely absent, Qwen35Configuration's decode throws DecodingError.keyNotFound as the fallback logic presumably intends, MLXVLM fails cleanly at that stage, and ModelFactoryRegistry falls through to MLXLLM correctly. That works, but it feels like a workaround rather than the intended path — the factory fallback seems to assume any failure will happen at decode time, and a config key that's present but semantically empty (no real vision weights behind it) skips that safety net entirely. Questions: Is there a more canonical/official way to detect whether a checkpoint actually has real vision tower weights, short of opening model.safetensors.index.json and counting vision_tower.* tensor names myself? (I've done exactly that for a different, genuinely multimodal Qwen VL checkpoint — 333 real vision tensors there vs. zero here — but it feels like something the loading path should be able to tell me.) Is the vision_config-present-but-empty pattern something the mlx-community conversion pipeline is aware of, or is this specific to how Qwen3.5-9B-4bit happened to get converted? Happy to share more logs/repro details if useful.

How can a local AI agent use MLX/Metal unattended while remaining confined to an authorized workspace? I am developing an AI-driven local media-processing workflow on an Apple-silicon Mac and am trying to understand the correct architecture for allowing it to run unattended without giving the AI agent unrestricted access to my primary personal computer. I am not a software engineer, so I may be missing an established macOS mechanism or using the wrong terminology. I would appreciate guidance from people familiar with MLX, Metal, sandboxing, and macOS security. What I am building I use OpenAI Codex as the local execution/software-development agent. The working system currently: ingests and verifies original video and still media while preserving immutable originals; performs visual semantic analysis and divides video into meaningful time-coded segments; separately analyzes spoken language rather than assuming audio and video are semantically equivalent; uses MLX Whisper locally on Apple silicon for time-coded speech transcription; stores visual and language semantics in a relational SQLite media catalog. These five stages are working. My current test corpus contains 148 original media files, 126 visual semantic segments, and 765 speech segments. The next stages are AI editorial construction from the semantic database and generation of instructions/scripts for a DaVinci Resolve rough cut. The security architecture I want Codex to operate autonomously within a deliberately bounded development environment. I do not want to solve this simply by granting an autonomous agent Full Disk Access to my primary personal Mac. The concern is ordinary fault containment. Codex generates and executes scripts, invokes applications and command-line tools, and manipulates files. A mistaken path or defective generated script should not have unrestricted consequences for the rest of my computer. I therefore separated AI execution from ordinary personal files. Codex is configured for Workspace Write access with explicitly authorized project roots. Canonical media resides on a separately authorized external SSD, and temporary AI working artifacts are kept separately. Ordinary Python and FFmpeg operations now run autonomously within these authorized areas. The problem The difficulty appears when the workflow invokes capabilities that cannot operate inside the ordinary Codex sandbox. The clearest example is MLX Whisper. I am using: MLX Whisper 0.4.3 mlx-community/whisper-small-mlx Apple silicon local transcription MLX Whisper works successfully and its transcription quality is sufficient for my semantic-retrieval application. However, MLX could not access Apple Metal/GPU execution from inside the ordinary Codex sandbox. Codex therefore requested permission to execute the transcription operation outside the sandbox. Once approved, MLX/Metal worked and the entire corpus was successfully transcribed. The processing therefore works, but the workflow cannot run genuinely unattended. A future operation should be able to run: new media → integrity verification → visual semantic analysis → MLX Whisper transcription → language semantic analysis → SQLite update → QA But if execution stops midway waiting for a human to click Allow, the pipeline is not operationally autonomous. What I have already tried I initially encountered permission problems even with ordinary file operations. I therefore: separated Codex work from ordinary personal documents; created dedicated project/work areas; explicitly authorized the required working roots; configured Workspace Write; separately authorized the external media repository; tested shell/Python and FFmpeg operations within those boundaries. Those changes worked. Routine Python and FFmpeg operations now run without approval prompts. The remaining issue occurs with MLX/Metal and some other application/runtime operations that require sandbox escalation. My question Is there a supported architecture for allowing a local AI agent to invoke MLX/Metal and other deliberately authorized development tools unattended, while still confining the agent to defined project/workspace boundaries rather than granting unrestricted access to the entire Mac? For example, should I be investigating: App Sandbox entitlements; a signed helper tool or XPC service; security-scoped resources; a dedicated executable with appropriate entitlements; a different method of launching MLX/Metal; or another macOS mechanism? In particular, can Metal/GPU access coexist with persistent bounded filesystem access without requiring interactive approval each time the AI invokes it? I am also unsure which security layer is actually responsible here: the Codex sandbox, macOS App Sandbox, TCC, executable/code-signing rules, Metal restrictions, or some interaction among them. If this kind of bounded unattended execution is intentionally not supported, that would also be useful to know. My alternative would be a dedicated Apple-silicon Mac containing only the AI-development environment and replaceable project data, where broader permissions would have a much smaller failure domain. I can provide the Codex configuration, exact successful and failing commands, directory/root configuration, macOS/hardware information, and sandbox diagnostics. I would particularly appreciate guidance on which security layer is causing the MLX/Metal escalation and what the supported architecture would be for this use case. Thank you.

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.

Hello, My app fully relies on the new Foundation Models. Since Foundation Models require Apple Intelligence, I want to ensure that only devices capable of running Apple Intelligence can install my app. When checking the UIRequiredDeviceCapabilities property for a suitable value, I found that iphone-performance-gaming-tier seems the closest match. Based on my research: On iPhone, this effectively limits installation to iPhone 15 Pro or later. On iPad, it ensures M1 or newer devices. This exactly matches the hardware requirements for Apple Intelligence. However, after setting iphone-performance-gaming-tier, I noticed that on iPad, Game Mode (Game Overlay) is automatically activated, and my app is treated as a game. My questions are: Is there a more appropriate UIRequiredDeviceCapabilities value that would enforce the same Apple Intelligence hardware requirements without triggering Game Mode? If not, is there another way to restrict installation to devices meeting Apple Intelligence requirements? Is there a way to prevent Game Mode from appearing for my app while still using this capability restriction? Thanks in advance for your help.

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’m seeing a major change in reported memory usage (and eventual termination due to memory pressure) when running a Core ML workload built with Xcode 27 on iOS/iPadOS 27. The source code, model files, and MLModelConfiguration are unchanged. Only the Xcode/SDK version used to build the app differs. On the same iPad running iPadOS 27: Xcode 26 build: model loading and prediction complete normally, with a relatively small reported application footprint. Xcode 27 build: the application footprint grows continuously as models are loaded and can exceed 5 GB. The app is eventually terminated unless models are unloaded very aggressively or the increased-memory-limit entitlement is used. I also tested an Xcode 27 build on a device running iOS 26. Its reported peak was only around 300 MB. This suggests the change requires both an Xcode 27-linked binary and the iOS 27 runtime. The workload consists of several compiled Core ML models using .cpuAndNeuralEngine. Loading models sequentially instead of concurrently does not materially change the final footprint. Releasing each MLModel after use does reduce it, so this appears to be model or Neural Engine residency being charged to the application rather than a conventional heap leak. I noticed that the iOS 27 release notes mention Neural Engine memory now being attributed to the application instead of the system. However, I’m unclear about the practical consequences of that change. If the same Neural Engine resources were already physically resident on iOS 26, I would have expected them to contribute to system memory pressure even when they were not attributed directly to the application. Instead, the older configuration runs comfortably, while the Xcode 27/iOS 27 combination approaches or crosses the application’s per-process memory limit. A few additional observations: The problem is more likely to occur after Core ML has already compiled and specialized the models. Cached model loading is much faster and the footprint grows quickly. The first uncached run can survive model preparation because specialization spaces the loads farther apart. Under Instruments, the app often does not terminate, presumably because profiling slows the workload enough to change the peak. os_proc_available_memory() decreases in line with the newly reported footprint. With the increased-memory-limit entitlement, the workload completes, but the reported footprint still reaches several gigabytes. Has anyone else observed a large Core ML memory increase specifically with an Xcode 27 build running on iOS 27? In particular, I’m trying to understand: Is this purely a change in how existing Neural Engine memory is accounted for, or does the new runtime also retain or allocate more memory? Is the new accounting used for the application’s jetsam/per-process memory limit? Is this behavior intentionally gated by the linked SDK version? That would explain why an Xcode 26 build behaves differently on the same iOS 27 device. Should applications now treat the Neural Engine residency of every loaded MLModel as part of their process-memory budget and unload models accordingly? Are there recommended APIs or Core ML loading strategies for controlling this residency? Any confirmation that others are seeing the same Xcode 27/iOS 27 behavior—or clarification of the intended memory-accounting model—would be very helpful.

I've already used the new Siri for a few weeks but now it disappeared. The Siri app still exists but cannot use. Currently the Siri is the original Apple Intelligence. I went to Settings, Screen Time, Content & Privacy Restrictions, Siri, and the Siri AI (Beta) is grey cannot choose. Anyone knows how to fix it?

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.

After updating my iOS and xcode to latest iOS 27 beta5 and xcode 27 beta5 all the system language model session calls with tool calls inclusion throwing Unrecognized system-instruction prefix ID: com.apple.fm_api.tool_calls_override error. The same code was working perfectly in iOS27 beta 4. Even the apple sample project OrigamiCraftingADynamicTutorialForAppleIntelligence failing with the same error when tool calls invoked. Anybody else facing similar issue or any workaround for this issue? sample code: struct GetRecordNotesTool: Tool { let name = "getRecordNotes" let description = "Fetches internal notes and returns Note_Title and Note_Content for up to 10 notes." @Generable struct Arguments { @Guide(description: "The API name of the module, e.g. Companies or Contacts") var module_api_name: String @Guide(description: "The unique record ID to fetch notes for") var record_id: String } func call(arguments: Arguments) async throws -> String { return "Fetched content" } }

When using Private Cloud Compute, I want to be able to submit more than one prompt per LanguageModelSession, ideally using the prompt and response from the first interaction to inform a second interaction. How can I reference this first prompt and response when making a subsequent prompt in a session? I have tried plain language like "current data" and "previous prompt" but it does not seem to understand.

While building with Apple's Foundation Models, I kept running into a workflow problem before the app code itself. The hard part was not only calling LanguageModelSession. It was figuring out the shape of the interaction: What should be in the system prompt? What should stay in the user input? What output is actually usable by the app? How much instruction is too much? How do I test the same prompt repeatedly without creating another small Xcode project? I ended up building a small macOS tool for myself, LocalLM Lab, mainly to speed up that loop. The first use case was a Prompt Playground: system prompt, user input, model output, and a repeatable way to compare results before moving the workflow into app code. The current version also experiments with connector-style context, such as system clock, weather, reminders/calendar, contacts, and a scoped filesystem folder. That has made the prompt design problem more interesting, because the question becomes: what context should the model see, and how should the app frame that context so the output is useful? I am curious how other developers are handling this while building with Foundation Models. Are you mostly iterating inside Xcode playgrounds? Are you building small internal test harnesses? Are you separating system prompts and user inputs during testing? How are you evaluating whether the output is reliable enough for the app workflow? For reference, this is the tool I have been using for my own experiments: https://thisbrain.ai/locallm I would be especially interested in any patterns people have found for designing and testing prompts before committing them to app code.

Let's say my app is a password or other type of secret manager, which means it can display highly sensitive data to the user. If Siri summarize whats on screen, it would then be able to "see" that sensitive data and transmit it off device in a way the user might not expect nor want. Is there a way that I can prevent this by marking specific views in an app as sensitive, or detect if Siri is analyzing the contents of the apps screen? The .privacySensitive() modifier and @Environment(\.isSceneCaptured) environment variable do not seem to apply in this case.

On iPhone 16e running iOS 26, we have now lost barcode detection through two independent APIs. Other device models in the same fleet, on the same app build and the same iOS version, are unaffected. Background: the original failure (AVCaptureMetadataOutput) Our retail app scans EAN-13, Code 128 and ITF barcodes. It originally used AVCaptureMetadataOutput with metadataObjectTypes set accordingly. After the update to iOS 26, this stopped working on iPhone 16e. The behaviour was completely silent: the capture session reported isRunning == true, the camera preview stayed live and correctly exposed, no interruption or runtime-error notifications were posted — but metadataOutput(_:didOutput:from:) simply never fired again, for any barcode. There was no error of any kind to go on. Restarting the app did not help. Only a full device reboot restored detection. Because the metadata path performs detection in the media daemon rather than in our process, we moved detection into the app to work around it. The current failure (Vision) Frames now come from an AVCaptureVideoDataOutput (preset .hd1280x720, .up orientation) and are analyzed in-process: let request = VNDetectBarcodesRequest() request.symbologies = [...] let handler = VNImageRequestHandler(cvPixelBuffer: pixelBuffer, orientation: .up, options: [:]) try handler.perform([request]) On the same devices, handler.perform() now throws for every analyzed frame: Error Domain=com.apple.Vision Code=9 "Could not build inference plan - ANECF error: failed to load ANE model file:///System/Library/Frameworks/Vision.framework/ mrcdetector.H17.espresso.hwx Error=createProgramInstanceForModel:modelToken: modelFilePath:qos:isPreCompiled:enablePowerSaving:skipPreparePhase:statsMask: memoryPoolID:enableLateLatch:modelIdentityStr:owningPid:cacheUrlIdentifier: aotCacheUrlIdentifier:optOutOfModelMemoryUnwiring:error:: Program load failure (0x50004) (DESIGN)" So the second approach fails as well — but loudly, and one layer down. The failing model is a system model shipped inside Vision.framework; we load no Core ML model of our own. Shared characteristics Both failures behave identically in the ways that matter: Same device model (iPhone 16e), starting with iOS 26 Camera pipeline healthy throughout: frames keep arriving continuously (verified by a watchdog on the sample buffer delegate), preview live, no AVCaptureSessionWasInterrupted and no AVCaptureSessionRuntimeError Detection never recovers on its own An app restart does not help; only a device reboot does Over one workday we recorded ~65,000 consecutive Vision failures across four devices, with zero successful detections in between. This makes us suspect both symptoms share a root cause below the two APIs, rather than being two unrelated bugs. What we tried We found thread 761095, where the same error signature (Code=9, "Could not build inference plan - ANECF error", "(DESIGN)") was reported on visionOS 2.0 beta for a different system model, and where the suggested workaround was to restrict the request to CPU/GPU via setComputeDevice(_:for:). We implemented that as a runtime fallback: let devices = try request.supportedComputeStageDevices[.main] ?? [] // pick .gpu, else .cpu request.setComputeDevice(device, for: .main) We have not yet been able to confirm on an affected device whether this actually bypasses the failing path, since we cannot reproduce the state on demand. Questions Is this a known issue on iOS 26 / iPhone 16e? Could the silent AVCaptureMetadataOutput failure and this ANE model load failure share a common cause? Is restricting the compute stage to CPU/GPU a supported workaround for VNDetectBarcodesRequest, or does the barcode detector always require the ANE? Is there any way to recover the ANE state from within the app, so users do not have to reboot the device? Is there anything specific we should capture in a Feedback Assistant report to make this actionable? We can reproduce it in the field but not on demand.