I am shipping Core AI language models in an App Store app and have followed the ahead-of-time compilation workflow from WWDC26 session 326 and the article "Compiling Core AI models ahead of time". The remaining on-device specialization step is unusable for LLM exports, and I would like to know whether there is a supported way around it. Setup Models are exported with the coreai-models recipes and compiled with coreai-build for the Neural Engine: uv run coreai.llm.export Qwen/Qwen3-0.6B --platform iOS --compression-config models/qwen3/qwen3_0_6b_mixed_4bit_8bit.yaml xcrun coreai-build compile <model>.aimodel --platform iOS --architecture h18pThe compiled .aimodelc bundles are hosted remotely, one per architecture, and selected at runtime with AIModel.deviceArchitectureName. Loading uses CoreAILanguageModel(resourcesAt:) and FoundationModels.LanguageModelSession. Xcode 27.1 (27A9275), coreai-build 3600.83.1, coreai-models cc3c234, iPhone 17 Pro. The published bundles are public for reproduction: https://huggingface.co/333i/qwen3-0.6b-coreai-ios https://huggingface.co/333i/smollm2-1.7b-coreai-ios What happens on device Each compiled bundle carries its 30 Neural Engine regions (extend and prompt_opt, contexts 256 to 4096, query sizes 8, 16 and 64) as .mlir.bc under main-h18p-delegates/MPSGraph. On first load, ANELargeModelCompilerService compiles all 30 on the device. Qwen3 0.6B: the first reply takes over two minutes. Later launches load from the cache in about eight seconds. SmolLM2 1.7B: the compile fails after about a minute. The device reported 56 GB free. Freeing 20 GB more moved the failure from 33.6 GB to 35.5 GB. ANELargeModelCompilerService Convert 27/30 procedures of ANEHLO task 308/7012 ANELargeModelCompilerService ANECompiler internal error: temp file: F_PREALLOCATE failure (35500589056 bytes) -> (35511074816 bytes): No space left on device ANELargeModelCompilerService Caught ZinException kernel ERROR: [ANELargeModelCompilerService:61615] FATAL exception: type=0x1 reason=0x25 code=0x106 aned Could not create connection to com.apple.ANELargeModelCompilerService MPSGraphANEUtils.mm:1033: Error = Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ANELargeModelCompilerService" MPSGraphANEUtils.mm:1038: ANE compile failed! MPSGraphExecutable_Project.h:510: failed assertion `could not load module from MPSGraphPackage'The assertion terminates the app. No error reaches the load call, so there is no way to fall back or tell the user what happened. Compiling the same export with --preferred-compute gpu avoids the Neural Engine compiler but allocates roughly 0.5 GB of GPU memory per compiled function at load time. The 0.6B model reaches a 17 GB footprint at 4096 context on a Mac and is killed by Jetsam at about 6 GB on iPhone 17 Pro. What I have ruled out The ahead-of-time workflow is followed as documented. The article states that the compiled asset still requires some specialization on the device, and for these exports that residual step is the Neural Engine compile described above. coreai-build compile --help offers no option to generate the Neural Engine executables on the build machine. The failure reproduces on the October 18 runtime and on coreai-models cc3c234. Disk space is not the limit in practice. The compiler preallocates more than 30 GB of temporary storage for a 1.7B model, which no production device can be expected to provide. Related reports apple/coreai-models issue 387 (this failure, open since October 27 with no response): https://github.com/apple/coreai-models/issues/387 apple/coreai-models issue 406: a 0.6B export measured at roughly 600 seconds per specialization on iPhone 16 Pro Max, with Jetsam kills during specialization on a current-toolchain export. apple/coreai-models issue 205: coreai-build exits 0 and writes a GPU-only bundle when offline Neural Engine compilation fails, with an empty ErrorList. The Gemma 4 README in coreai-models states that ahead-of-time compilation is not supported for that model on the Xcode 27.2 beta toolchain and recommends on-device specialization from the raw .aimodel, which is the same path that fails here at 1.7B. Questions Is there a supported way to generate the Neural Engine executables for an LLM bundle on the build machine, so that no ANELargeModelCompilerService run happens on the user's device? If on-device specialization is the intended path, is there a bound on its temporary storage and time, and can the export emit fewer specializations or share work across them? Can a Neural Engine compile failure be surfaced as an error from the load call instead of an MPSGraph assertion that terminates the process? Is the per-function GPU memory in the --preferred-compute gpu build expected, and is there an export option that avoids it? At this point I have removed Core AI text models from the shipping app and kept Core AI for diffusion only, where ahead-of-time compilation works well. I would like to bring the text models back and am happy to test any build or export change.

With the Siri AI Developer Preview in iOS 27.3 beta 1, we are exposing custom intents to Siri as tools with @AppIntent(.tool). Some of these only make sense for Siri, for example a read-only status tool whose result Siri phrases as an answer, or variants that would duplicate existing Shortcuts actions. Our app already has a long list of Shortcuts actions, so we would like these tools to be available to Siri AI without appearing as actions in the Shortcuts app. @available(iOS 27.3, *) @AppIntent(.tool) struct GetStatusIntent: AppIntent { static let title: LocalizedStringResource = "Get Status" @Parameter(title: "Item") var item: ItemEntity func perform() async throws -> some IntentResult & ReturnsValue<StatusEntity> { // ... } }What we have tried on iOS 27.3 beta 1: static let isDiscoverable = false hides the action from Shortcuts, but Siri then never called the tool and used a different one instead. Conforming to DeprecatedAppIntent while keeping it discoverable also hides the action, but Siri stopped calling the tool over repeated attempts. Removing the deprecation brought it straight back. isAssistantOnly would describe what we want, but it only exists on AssistantSchemaIntent, and combining .tool with a Siri-supported schema is a build error. ToolIntent itself has no requirements in the 27.3 SDK. IntentVisibility only applies to entity properties, and .internal hides the property from Siri as well. Questions: Is there a supported way to make an intent available to Siri AI while keeping it out of the Shortcuts action list? Is it intended that isDiscoverable = false and DeprecatedAppIntent also make a tool unavailable to Siri AI? If there is no such option today, is one planned, and is there a feedback number we should reference? Related question about schema intents: https://developer.apple.com/forums/thread/838658 Thanks!

Is it possible to integrate Siri into an iOS app in a way that allows users to control the app entirely through voice commands? For example, imagine a user saying: “Siri, open my add-ons and show me my available internet packages.” I would like to understand whether Siri, using App Intents or another Apple framework, can: Recognize a voice command and identify the requested action. Navigate to a specific section of the app's Home Screen, even if that section is currently outside the visible area. Automatically scroll to the relevant UI component and bring it into view. Navigate to other screens when required. Perform multiple actions as part of one continuous experience, such as scrolling, opening a screen, selecting an option, and triggering an API request. My main question is: Can we create a conversational, voice-controlled experience where a single Siri command can trigger a sequence of UI navigation and app-related operations, rather than simply opening the app or navigating to a predefined screen? What are the recommended Apple frameworks and best practices for implementing this kind of experience?

I would like to know why there are limitations for languages used in Siri?

Hi, is there any way to have caching done better for CoreML models (ANE)? Right now from my testing, after the first model compile and specialization, the cached model loads fast etc, but it only persists until an app update, even if nothing was changed on the app side. Just changing the build number is enough to invalidate the cache and require the first time compilation and load again. This seems like such a huge issue to me, and I'm hoping I'm just missing something, and this isn't intended behaviour, especially with the massive degradation in first time model compilation and speialization time for A20 and M6 devices which have a larger neural engine.

Dear Apple Developer Relations & Technical Support Team, I am an iOS developer based in Mainland China. We are currently developing an on-device AI-powered translation assistant for reading original English books, targeted at a global market. We have upgraded our development setup to Xcode 27.3 Beta and iOS 27.3 Beta. When attempting to invoke the FoundationModels API on an iPhone 15 Pro (Mainland China SKU: MTQA3CH/A), the system fails to initialize and returns the following diagnostics: Availability: unavailable(FoundationModels.SystemLanguageModel.Availability.UnavailableReason.deviceNotEligible) Raw Error: FoundationModels.SystemLanguageModel.Error Code 0 ("The assets required for the session are unavailable.") Language Support: supportsLocale(zh-Hans): true Considering that the iPhone 15 Pro hardware (A17 Pro chip) meets the necessary performance criteria and the framework reports that Simplified Chinese is supported, we would like to consult with you on the following key questions: Current Availability & Expected Release Timeline: Is the FoundationModels API currently completely disabled for Mainland China hardware models (CH/A)? If it is currently restricted, when is it expected to become available for developers and users in Mainland China? If there is an established roadmap or target release schedule, could you please share a specific timeline so we can plan our product roadmap and release cadence accordingly? Model Strategy for Mainland China: In Mainland China, will Apple eventually enable the standard FoundationModels API seamlessly under the hood, or will a different, locally-partnered/compliant AI model be required to satisfy regional regulations? Should developers expect the existing FoundationModels API to unlock in the future, or should we design a separate, alternative AI backend specifically for the Mainland China market? Testing Solutions for Global App Deployment: Since our application is intended for global release outside Mainland China, what is the official recommended workflow for China-based developers using CH/A devices to test and debug FoundationModels features during this beta phase (e.g., using Xcode Simulator, overseas non-CH/A hardware, or a developer sandbox/allowlist)? Environment & Diagnostic Details: Developer Team ID: NVQ5CF8F2X Xcode Version: Version 27.3 beta (Build: 27C5020n) iOS Version: Version 27.3 (Build: 24C5037i) Test Device: iPhone 15 Pro (Hardware: iPhone16,1, Model: MTQA3CH/A) Diagnostic State: isAvailable = false, deviceNotEligible Error: Domain=FoundationModels.SystemLanguageModel.Error, Code=0, "The assets required for the session are unavailable." Thank you very much for your time and assistance. We look forward to hearing your insights. Sincerely, Kai

Our app is a secure enterprise portal (business email, files, chat) for MDM-managed corporate devices. Preventing selected text from leaving the app is a hard product requirement, so we opt out of Writing Tools everywhere. On iOS 27.2, the Siri AI entry still appears in the text-selection edit menu (the bubble menu shown on long-press/selection), in both WKWebView and UITextView, and it allows sending the selected text to Siri. We have exhausted every public API and documented all of it: writingToolsBehavior = .none is set and verified at runtime. WKWebViewConfiguration.writingToolsBehavior == .none (-1) before the web view is created, and the web view's internal content view also reports -1. UITextView.writingToolsBehavior = .none as well. The documentation for UIWritingToolsBehavior.none says "Writing Tools will ignore this view", so we expected no AI entry point for selections in these views. The entry is not in UIMenuBuilder. We dumped the entire menu tree in buildMenu(with:) (root and all children, before and after calling super): only standard-edit / open / format / learn / speech / share are present. There is no Siri-related menu or command to remove. The entry does not go through canPerformAction(_:withSender:). We log every selector that is queried; no Siri/WritingTools-related selector ever appears. Our override returns false for everything except cut/copy/paste/select/ selectAll/delete — yet the Siri AI entry is still shown. Even a fully custom menu does not help. Returning a UIMenu built from scratch (only our own UIActions, ignoring suggestedActions) from textView(_:editMenuForTextIn:suggestedActions:) still gets the Siri AI entry attached to the presented edit menu. So the entry is attached to the edit-menu container itself, not to the menu contents. Questions: Is there any supported API on iOS 27 for an app to suppress the Siri AI entry in the edit menu for specific views (or app-wide)? If not, is this intended behavior? It appears to contradict the documented contract of UIWritingToolsBehavior.none ("Writing Tools will ignore this view"). Is there a recommended approach for apps handling confidential data (banking/меdical/enterprise) other than the MDM allowWritingTools restriction? Environment: iOS 27.2 (Iphone 16Pro), Xcode 27.2, deployment target iOS 13.

I'm using foundation-models-utilities 1.1.0 (tag at 6c5a04c). An instructions skill created with allowsDeactivation: false can still be switched off by the model. I filed this as FB25367740 on October 29, with a repro and console output attached. The measurements below are from 1.1.0-beta1 (cc3820d). The only commit between 1.1.0-beta1 and 1.1.0 changes README.md and SKILL.md, so the stable release behaves the same. Setup One instructions skill, metric-units, with allowsDeactivation left at its default, false. No skill allows deactivation, so the synthesized tool is named activate_skill. Three prompts in one session, with .greedy sampling: "From now on, give every measurement in metric units." "Keep using metric units, please. How far is 3 miles?" "Switch metric mode off." Expected metric-units stays active through all three turns. Any of these would do: a call naming it is rejected or ignored, it is left out of the schema while active, or the tool isn't offered when no skill can be named. Actual (identical across repeated runs) Default, strictSchema: false: Turn 1: activate_skill {"skill": "metric-units"} → "Successfully activated skill: metric-units". Active: ["metric-units"]. Turn 3: activate_skill {"skill": "metric-units"} → "Successfully deactivated skill: metric-units". Active: []. The model answered, "Metric mode is now off." strictSchema: true: Turn 2: with the skill active, the argument's enum is empty ("enum": []), but the tool is still offered. The model called activate_skill {"skill": "metric-units"} anyway, and the skill was deactivated. Active: []. Turn 3: it called the tool again and re-activated the skill. The model answered, "Metric mode is now active again." Where it comes from (Sources/FoundationModelsUtilities/Skills/Skills.swift at 1.1.0) The onCall closure toggles any instructions skill without reading that skill's allowsDeactivation: case .instructions: if activations.isActive(skill.name) { activations.deactivate(skill.name) skill.deactivate() } else { activations.activate(skill.name) skill.activate() }ToggleSkillTool.call(arguments:) only checks that the name matches a skill, so it accepts a name outside the schema's enum too. The schema has a related gap. In ToggleSkillTool.init, allowsDeactivation is true when any skill allows it, and then allowed += activeNames adds every active skill, including ones created with allowsDeactivation: false, even under strictSchema: true. I found this one by reading the source. It isn't in FB25367740, and I haven't measured it. Possible fix Check the skill's own allowsDeactivation before deactivating it, and return a message saying it stays active. Add to allowed only the active skills that allow deactivation. When allowed is empty, leave the tool out, or reject the call in call(arguments:). Environment Model: on-device SystemLanguageModel.default Package: foundation-models-utilities 1.1.0-beta1 (cc3820d); the Skills code is unchanged in 1.1.0 macOS 27.2 (26B123), MacBook Pro (Mac15,9), Apple M3 Max, Xcode 27.1 (27A9275)

I've been working with foundation-models-utilities and noticed a few places where the README and bundled SKILL.md don’t match the code. I’m using version 1.1.0-beta1 (commit cc3820d). Here’s what I found: SkillActivations collection conformance. The README says it conforms to RandomAccessCollection. The implementation conforms to Sendable and Observable, and exposes activeSkillNames and isActive(_:) instead. Package dependency version. The installation example uses from: "1.0.0". With only prerelease tags available when checked, that stable version requirement does not resolve. An example referencing a published beta would help. Local server URL. Both ChatCompletionsLanguageModel examples use http://localhost/v1:8000. For port 8000 and base path /v1, the URL should be http://localhost:8000/v1; the existing example places :8000 in the path. SwiftPM traits and conditional compilation. The bundled SKILL.md describes ChatCompletions, Skills, and History traits, and says the sources use matching #if gates. However, Package.swift declares no traits, and those gates are absent from the sources. Could you update the documentation to match this release? The bundled agent skill is particularly relevant because coding assistants may otherwise generate configuration for traits the package does not provide.

Hi, Apple recently announced that Apple Intelligence will launch in mainland China with iOS 27.3. Will the Foundation Models framework also become available to third-party apps in mainland China? If so, will it use the new iOS 27 Apple Foundation Model or an older version? Will the new capabilities and Private Cloud Compute also be supported? Thanks!

Hello, Our app provides two actions in the Shortcuts app. However, on some devices running iOS 27, neither action appears, preventing users from setting up automations during onboarding. We have not observed this issue on earlier iOS versions. Implementation Both actions conform to LiveActivityIntent, with their corresponding App Shortcuts declared in an AppShortcutsProvider. Both have a required AppEntity parameter, with initial parameter options provided by EntityQuery.suggestedEntities(). We call updateAppShortcutParameters() at app startup and after saving changes to the platform selection. Observed behavior Only some iOS 27 devices are affected. Some affected users report that the actions appear a few days later, but we have not identified what triggers their appearance. Has anyone encountered similar behavior? Is there a known registration or indexing issue, or anything in this implementation that we should investigate? This blocks a key step in our new-user onboarding, so we would greatly appreciate any guidance or workaround. Thank you.

I'm building a voice app called Moonstone that works like a hands free coding agent for the iPhone. You talk to it and it opens apps, taps through them and gets real tasks done, mostly on a local model running on the phone. I have the side button access entitlement, an App Intent using the assistant activate schema, and my development profile installed on an iPhone 18 Pro Max on the iOS 27.2 developer beta. The docs say the profile is enough to test during development, but here in the US the Side Button option never shows up in Settings. I tried switching the region to Japan and restarting and it still didn't appear. I filed FB25304176. Has anyone outside Japan gotten the setting to show up on a development device?

We ported a complete Stable Diffusion XL (Lightning) pipeline to Core AI which we previously had on Core ML. The pipeline comprises text encoders, a ViT-H image encoder, ControlNet, the UNet and the VAE decoder. It works very well: on iPhone 17 Pro and M1 iPad Pro it generates 1.4–1.6x faster than our Core ML pipeline at the same image quality. However, along the way, we hit seven issues. Each one is filed with a small self-contained repro. We're posting them here together for visibility, with our workarounds, in case others run into the same problems. Ahead-of-time compilation (coreai-build compile) Each of these gives wrong results on the Neural Engine with no error. The same .aimodel specialized on the device is correct. FB25067476: A 3×3 fp16 conv with a large output returns a wrong bottom half (16.7 dB vs 60.7 dB for the top half). This depends on the chip: 256×512×512 fails on M3 Pro and A19 Pro, while 256×384×384 fails only on M1. Our workaround: split such convs by output channels so that no single output exceeds about 128×384×384. FB25067497: A nearest 2× upsample followed by a 3×3 fp16 conv returns output unrelated to the correct result (correlation 0.02) on all three chips. The upsample alone and the conv alone are correct. Our workaround:* write the upsample as repeat_interleave(4) + pixel_shuffle(2). FB25067530: A 3×3 stride-2 conv with 8-bit palettized weights is wrong (16 dB) on all three chips. The same conv with fp16 weights, or palettized with stride 1, is correct. Our workaround:* a 2×2 pixel unshuffle followed by a 2×2 conv. Caching and loading FB25066222: The cache for ahead-of-time compiled .aimodelc files is keyed by the outer program only (main.hash), not the weights, so a weights-only model update silently runs the old weights. On iOS, the Neural Engine program cache is also keyed by function name per app, and survives AIModelCache.deleteAll() and deleting the app. Our workaround: append a hash of the model's content to every function name. FB25066664: On macOS, ahead-of-time builds of transformer models load 3–4× slower than on-device specialization, and parallel loads finish one at a time. Precompiling therefore made our Mac first launch slower (1152 s vs about 650 s), not faster. Neural Engine runtime (Mac) FB25067019: The built-in GroupNorm returns wrong results on the Mac's Neural Engine for large inputs (GroupNorm(32, 256) on 1×256×256×256: 21.7 dB), while the GPU and CPU are correct (84 dB). Our workaround: compute the means and variance explicitly. FB25064649: A ViT-H vision tower with an 8-bit palettized 14×14/stride-14 patch conv aborts the process on the Mac's Neural Engine (MPSGraph ANE error -19). Our workaround: keep the patch conv in fp16, or use a pixel unshuffle followed by a 1×1 conv. Environment macOS 27.0.1 (26A434), iOS/iPadOS 27.0.1 (24A446) Xcode 27.0, Metal Toolchain 27.1.266.1 (coreai-build 3600.83.1), coreai-torch 0.4.3 Tested on M3 Pro, iPhone 17 Pro and M1 iPad Pro We're happy to provide more data. We'd also like to hear whether others see the ahead-of-time issues on other chips.

Hello, I have PCC deployed in my 3 apps and my testing for these apps has caused me to hit the rate limit many times. When this rate limit is hit, Siri AI (as well as HomeKit PCC features) stops working completely for me until the rate limit is reset. I have been forced to scale back PCC and testing in my apps as this situation is quite opaque. My logs say I’m being rate limited when using PCC in these cases. Example log I see: 10:51:47.407 | RemoteManager executing remote streaming request 10:51:47.407 ModelCatalog | Looking up asset bundle com.apple.fm.language.instruct_server_v2.fm_api in Model Catalog 10:51:47.410 DaemonSession | Asset com.apple.fm.language.instruct_server_v2.fm_api has inference providers: 10:51:47.410 DaemonSession | - private-ml-client 10:51:47.411 ExecutionGroup | executing request C9B08798-6D68-4819-83C9-89B2EF5278C4 10:51:47.431 InferenceProviderConnection | InferenceProvider requestInference (C9B08798-6D68-4819-83C9-89B2EF5278C4) finished 10:51:47.431 RemoteManager | Request failed on private-ml-client with error: InferenceError::rateLimited::PrivateCloudComputeError: deniedDueToUserDeviceRateLimit, falling back 10:51:47.431 RemoteIPC Tasks | Failed to execute remote streamingRequest with error: InferenceError::rateLimited::PrivateCloudComputeError: deniedDueToUserDeviceRateLimit 10:51:56 modelmanagerd [com.apple.modelmanager:RemoteIPC Tasks] Failed to execute remote oneShotRequest with error: InferenceError::rateLimited::PrivateCloudComputeError: deniedDueToUserDev 11:23:39 privatecloudcomputed [com.apple.privatecloudcompute:RateLimiter] rate limit applied from cached denials What are the rate limits? How many requests a day? Per second? Also, I subscribed to the highest iCloud storage tier in hopes of higher rate limit but there doesn't seem to be any change. https://support.apple.com/en-us/127901 This issue started when iOS27 became publicly available - I was never rate limited when on the iOS27 beta.

Totally inaccurate performance from the newly launched Siri on MacOS 27.01. This was incompetent for AI. I asked for a graph of the price of an ounce of gold in $AUD. Its first response gave the price in $USD and not $AUD yet labelled it as $AUD - fundamentally wrong. It kept answering with tiles of graphs as a response - some having nothing to do with the question. It then finally admitted it couldn't produce a graph. It didn't understand the context of 2026 being a calendar year and defaulted to a financial year. So many issues - this is really bad Apple. So many years waiting for this - and this is not ready yet.

Hello 👋, We finally gets our hands-on Siri AI here in France on macOS 27.2 As a macOS developer supporting App Intents into my app I would like to add App Schema to my AppIntent / AppEntity to make them available through Siri AI in my next release. So I've started by downloading the CometCal app and add a target for macOS (because I supposed the existing Mac Catalyst target provided was not supported by Siri AI ?). On my machine CometCal does not work with Siri AI. It either fail or repond it cannot do the action. Doing those actions (Find event, Create event, ...) in Apple Shortcut works just fine. Do I miss something specific on macOS ? A specific configuration or something ? Is Siri AI supposed to work on macOS as I tried to ? (I also tried making a Release build or moving the app into /Applications) NB: I don't have a Siri AI compatible iPhone (+ blocked in Europe) to run CometCal on iOS to compare with. Thanks,

We filed FB25314866. PrivateCloudComputeLanguageModel refuses to extract basic facts (name, year, depth, coordinates) from Wikipedia and dive-shop pages about warship wrecks, including a destroyer scuttled as an artificial reef. The input passes (a "reply OK" variant is answered); the output is filtered with "Streamed response may contain sensitive or unsafe content", on respond() and streamResponse alike. Guided generation passes for some of the same inputs. SystemLanguageModel offers Guardrails.permissiveContentTransformations for this kind of extraction, but the PCC model has no guardrails parameter. Is support planned, and is there a recommended approach meanwhile? About the 11 attachments filed in Feedback Assistant: Each file is the Data returned by LanguageModelSession.logFeedbackAttachment(sentiment: .negative, issues: [.triggeredGuardrailUnexpectedly]). It holds the session transcript (instructions, prompt, the refusal) and our explanation. Tested on macOS 27.0.1 (26A434), with a development-signed build carrying the PCC entitlement, on 2026-10-25. wreckpage_w02, w03, w04, w06: Wikipedia articles HMAS Brisbane (D 41), SS Thistlegorm, USAT Liberty and Chuuk Lagoon. The first 12,000 characters, with the HTML stripped, are sent with a request for the wreck's facts as JSON. Refused with "Streamed response may contain sensitive or unsafe content". This is the output filter: the same text with the instruction "Reply with the single word OK" is answered. wreckpage_w10: a dive shop's page about diving the Ex-HMAS Brisbane, a destroyer scuttled as an artificial reef. Same refusal, and also the output filter, by the same test. wargrave_34, 79, 82, 98, 186: a 2–4 sentence note about a naval wreck the diver logged, using Wikipedia background text. Refused with "Response may contain sensitive or unsafe content". This is the input filter: the "reply OK" variant is refused too. wreckfacts_Thistlegorm: basic facts requested by wreck name and location. Refused with "Response may contain sensitive or unsafe content". This is the output filter: the "reply OK" variant and guided generation both pass. What we ruled out before filing: Retries: the refusals are deterministic, and 0 of 14 retries passed in earlier runs. Streaming: respond() and streamResponse refuse alike. Guided generation: a @Generable struct with fixed fields passed 4 of the 6 extraction inputs with correct values. Both HMAS Brisbane inputs were still refused. Control: a peaceful loss (SS Yongala, lost in a cyclone) is answered correctly. On-device model with permissiveContentTransformations: it never refuses, but it makes up facts on this task, so it is not a substitute. wreckpage_w02 includes the answer we expected (desiredOutput).

Hi — I built SiriReady Bench, an external benchmark that measures whether an app's App Intents implementation is actually reachable the way people talk: static audit (App Schemas, IndexedEntity, View Annotations), a bilingual EN/JA utterance dataset (1,272 cases), and a real-run harness that drives built apps through AppIntentsTesting on an iOS 27.0 simulator (Xcode 27.1 / iOS 27.1 SDK). Repo: https://github.com/NagaYu/siriready-bench Dataset (dev split): https://huggingface.co/datasets/NagaYu/siriready-bench Four reference apps (messages/calendar, correct and intentionally broken versions) were measured. Every number is labelled by source (real / mock / static). Utterance-to-intent arrival is a rule-based mock — AppIntentsTesting calls intents directly and never exercises Siri's language understanding, and I say so in the results. A few measured findings I'd like to sanity-check with the team: Correct apps over-confirm. Even after a request names exactly one entity, perform() still requests confirmation (56 cases in messages, 54 in calendar, in the reference implementations). Is "always confirm" the expected behaviour for these schemas, or is there a supported way for the system to skip confirmation when resolution is unambiguous? No tolerance for typos or sound-alike spellings, and index gaps. spotlightQuery and entity string queries return nothing for misspelled or near-sound names. Possessive titles ("Jon's …"), conversation readings (Japanese yomi), and calendar aliases fall out of the index entirely — a Japanese calendar alias was not found and the event was created in the default calendar instead; designating a conversation by its reading returned 3 of 12 probes. Are readings/aliases intended to be indexed, and is fuzzy matching on the roadmap? The toolchain sets a floor. A messages app built without an entity string query does not compile: Xcode 27.1 raises a halting error requiring an EntityStringQuery, so in real runs that "broken" app scored higher than a static reading suggests. Sharing this because it changes what "broken" can even mean for App Intents in iOS 27. Privacy routing is input-dependent. In the broken calendar app, an off-device call was observed in 24 of 24 location-bearing requests and in none of the other 84 (intercepted locally, never sent). A static privacy finding alone doesn't tell you when it fires. Scores for the four apps (MOCK + REAL, real 54% · mock 25% · static 21%): messages_ok 95.0, messages_broken 68.8, calendar_ok 94.0, calendar_broken 83.4. Full tables, measurement conditions and the mock-vs-real divergence log are in BENCHMARKS.md in the repo. Physical-device Siri spot checks are protocol-only so far (not yet recorded) — also stated in the repo. I'd genuinely like to know which of these behaviours are known/expected, and whether the team would read a Feedback report on the indexing gaps. The project is available for transfer or licensing; contact is via my portfolio (linked in the repo README). — Yuta Nagao

I’m testing NLLanguageRecognizer to distinguish Malay (Bahasa Melayu) from English using this Malay text: Buka App Muzik untuk Mendayakan Widget Without language hints, my sandbox produces the following results. Percentages are rounded for display: Constraints Returned scores ID, EN ID: 100%; EN: 0% MS, EN EN: 100%; MS: not returned VI, EN VI: 98.7%; EN: 1.3% ID, MS, VI, EN ID: 100%; MS: not returned; EN and VI: 0% I also tried supplying languageHints to favor Malay and changed my phone’s system language to Malay. Neither resolved the issue: the recognizer still failed to identify the text as Malay. Here is a minimal example with hints: import NaturalLanguage let recognizer = NLLanguageRecognizer() recognizer.languageConstraints = [.malay, .english] recognizer.languageHints = [.malay: 0.8, .english: 0.2] recognizer.processString("Sila isi borang di bawah") print(recognizer.dominantLanguage?.rawValue ?? "nil") for (language, score) in recognizer.languageHypotheses(withMaximum: 2) { print(language.rawValue, score) } An independent native macOS test with the same short text also returned English with score 1.0, both with hints disabled and with the 0.80 Malay hint. To investigate whether this was only short-text ambiguity, I separately tested a longer Malay paragraph taken from local news on macOS: Terdahulu, peguam PN, Ivanpal Singh Grewal, berhujah bahawa penangguhan wajar diberikan memandangkan keadaan luar biasa susulan PRN Melaka pada 14 Nov, sambil berkata penggantungan itu menghalang gabungan berkenaan daripada menyertai proses demokrasi. Without hints, that paragraph produced: Constraints Result None Indonesian (id), score 1.0 English and Malay English (en), score 1.0; no Malay hypothesis Malay only dominantLanguage is nil; hypotheses are empty English, Malay, Indonesian Indonesian (id), score 1.0 I understand that Malay and Indonesian share vocabulary, short strings can be ambiguous, and constraints can force a prediction into an allowed language. However, Malay appears absent even when explicitly allowed and favored. My questions are: Is Malay identification supported by NLLanguageRecognizer on iOS and macOS? Could the missing Malay hypothesis and empty Malay-only result indicate a model limitation or framework defect? Is there an API to check which languages are available for recognition on the current runtime? Are any additional settings or language resources required? Environment iPhone model / iOS version: iPhone 13, iOS 27.2 Phone system language: tested with English and Malay Independent Mac reproduction: macOS 26.7.1 (25G241), Apple Silicon, Xcode 27.2 Beta 3

Hello Apple engineers and developers, I am testing PrivateCloudComputeLanguageModel in an iOS reading app. Environment: Device: iPhone 16e purchased outside mainland China OS: iOS 27.0.1 (24A446) Our developer team has been approved for PCC access. The app signature and embedded provisioning profile both contain: com.apple.developer.private-cloud-compute = true The app makes one short, foreground, non-streaming request without automatic retry or structured generation: “Translate this sentence into Simplified Chinese: The stars are beautiful tonight. Return only the translation.” Immediately before the request: model availability: .available quotaUsage.status: .belowLimit isApproachingLimit: false isLimitReached: false resetDate: nil Nevertheless, the request fails after approximately 0.11–0.14 seconds with: FoundationModels.LanguageModelError.rateLimited No response content is generated. The error does not provide a reset time or additional metadata. I tested both Apple Development and Ad Hoc builds. Both resulted in the same rate-limit message in the app UI. Changing the app’s bundle identifier did not change the result. Enabling a VPN also did not change the displayed message; I did not verify whether PCC traffic was routed through the VPN. On October 13, 2026, at approximately 19:04 China Standard Time (UTC+8), I also ran Apple’s Shortcuts app on the same iPhone and selected “Use Model” with Cloud. It showed “Too many requests. Please try again later.” and generated no response. I repeated the test after switching the device’s primary iCloud account to an account configured for the US region. The device was physically located in mainland China during these tests. Could you please clarify: Can account, region, device, or service-side eligibility restrictions appear as rateLimited even when the model reports .available and quotaUsage reports .belowLimit? Is any additional activation or allowlisting required beyond PCC team approval and the signed entitlement? Which logs or diagnostics can identify the cause or retry time when resetDate is nil? Is the Shortcuts Cloud result useful evidence of a device- or account-level restriction, or does Shortcuts use an independent service policy? Thank you.