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.

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,

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.

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.

What is the best approach to automatically process bank receipt images on iOS while respecting user privacy? I'm exploring ways to automatically extract transaction details from receipt images using on-device OCR. I'd like to discuss which Apple APIs and permission models would be appropriate for this functionality.

We have a standalone reproduction of encrypted Core ML model loading capacity decreasing after the app is terminated during an unfinished load. Feedback ID: FB25001494 The Feedback Assistant report includes a minimal UIKit/Objective-C project, a small model generated entirely from seeded random constants, and 40 standalone experiment logs. Environment iPhone 14 Pro (iPhone15,2) iOS 16.0 (20A357) Both synchronous and asynchronous Core ML loading APIs MLComputeUnitsAll Loading runs on a background worker, with only one outstanding request during each interruption trial No application-level loading timeout Other iOS versions have not yet been verified with this standalone sample. Error NSError domain: com.apple.CoreML Code: 9 The error description contains "Failed to set up decrypt context" and "error:-42905". Reproduction Reboot the device and complete normal model loading/releasing to ensure the encryption key is available. Measure capacity by sequentially loading and retaining encrypted MLModel instances until the first failure, then release all successful instances. Launch a fresh process and terminate it with SIGKILL approximately 50 ms after starting its first model load, before the load completes. Repeat this interruption in five fresh processes. Launch another process and measure capacity again. Observed results Initial capacity: 99, 99 in two measurements. After five interrupted synchronous loads: 94, 94. After five additional interrupted asynchronous loads: 90, 90. After 40 normal asynchronous loads/releases: still 90, 90. After five more interrupted synchronous loads: 85, 85. After at least 60 seconds with no sample process running: still 85, 85. After rebooting the device: 99, 99. Timing matters: five interruptions at approximately 5 ms did not reduce capacity. We do not claim that every interrupted load loses exactly one resource. Controls and interpretation Normal controls and capacity probes release all successfully loaded models before their processes are terminated. Autorelease pools and associated-object deallocation witnesses are used to check model lifetime; these do not directly inspect internal decrypt sessions. The capacity-limit error while deliberately retaining many models is expected. The unexpected behavior is that terminating an unfinished load reduces the repeatable capacity available to subsequent fresh processes. This suggests a cleanup issue across process termination, but the internal cause has not been established. Questions Is this a known issue, and if it has been fixed, which iOS version contains the fix? Is there a supported recovery mechanism that does not require rebooting the device? Is there a recommended loading or lifecycle workaround? Switching between synchronous and asynchronous loading did not eliminate the behavior. Has anyone reproduced this specific interrupted-load behavior on a newer iOS version? Related discussions https://developer.apple.com/forums/thread/740731 https://developer.apple.com/forums/thread/678599 We also reviewed thread 707622, where moving the autorelease pool inside the loop resolved retained-model exhaustion. Our sample includes release controls and specifically tests capacity after termination of an unfinished load.

I'm using Vision framework (DetectFaceLandmarksRequest) with the same code and the same test image to detect face landmarks. On iOS 18 everything works as expected: detected face landmarks align with the face correctly. But when I run the same code on devices with iOS 26, the landmark coordinates are outside the [0,1] range, which indicates they are out of face bounds. Fun fact: the old VNDetectFaceLandmarksRequest API works very well without encountering this issue How I get face landmarks: private let faceRectangleRequest = DetectFaceRectanglesRequest(.revision3) private var faceLandmarksRequest = DetectFaceLandmarksRequest(.revision3) func detectFaces(in ciImage: CIImage) async throws -> FaceTrackingResult { let faces = try await faceRectangleRequest.perform(on: ciImage) faceLandmarksRequest.inputFaceObservations = faces let landmarksResults = try await faceLandmarksRequest.perform(on: ciImage) ... } How I show face landmarks in SwiftUI View: private func convert( point: NormalizedPoint, faceBoundingBox: NormalizedRect, imageSize: CGSize ) -> CGPoint { let point = point.toImageCoordinates( from: faceBoundingBox, imageSize: imageSize, origin: .upperLeft ) return point } At the same time, it works as expected and gives me the correct results: region is FaceObservation.Landmarks2D.Region let points: [CGPoint] = region.pointsInImageCoordinates( imageSize, origin: .upperLeft ) After that, I found that the landmarks are normalized relative to the unalignedBoundingBox. However, I can’t access it in code. Still, using these values for the bounding box works correctly. Things I've already tried: Same image input Tested multiple devices on iOS 26.2 -> always wrong. Tested multiple devices on iOS 18.7.1 -> always correct. Environment: macOS 26.2 Xcode 26.2 (17C52) Real devices, not simulator Face Landmarks iOS 18 Face Landmarks iOS 26

Oldest model of 5.5 with codex is deprecated by chatgpt but I only see 5.5 as the highest available model selectable in the dropdown in intelligence settings in Xcode when selecting codex I have the ChatGPT pro account and login to codex in xcode via email/password and not the API key I have already tried login out, quitting xcode, removing codex agent and reinstalling it, so far nothing works

On iPhone 18 Pro (A20 Pro), the first MLModel load of a model on the Neural Engine can take minutes where an iPhone 17 Pro needs seconds. Cached loads are instant, and once loaded the model runs faster than on the iPhone 17 Pro, so only the on-device specialization is affected. This looks like the same problem as A20 pro devices take too long on CoreML model specialization and iPhone 18 pro takes very long time to load models. The "loading" time there is likely this specialization too: it happens inside MLModel(contentsOf:) for an already compiled .mlmodelc. I can reproduce it reliably with attention in the form Apple recommends for the Neural Engine (split einsum, as in Deploying Transformers on the Apple Neural Engine). In this example most of the extra time comes from the softmax over the key axis, which in that layout is the channel axis. Other ops and model types may well be affected too; this is simply the smallest case we could build that shows the problem clearly. The repro uses four self-attention layers (10 heads × 64, 4096 tokens, fp16) built with coremltools and loaded cold with .cpuAndNeuralEngine. MLComputePlan places every op on the Neural Engine on all three devices. iOS 27.0.1 (24A446) on both iPhones: iPhone 18 Pro iPhone 17 Pro M3 Pro Mac cold predict cold predict cold predict Split-einsum attention, 4 layers 53.4 s 21.6 ms 0.8 s 111.4 ms 1.0 s 105.8 ms Q.K einsum only 5.1 s 24.0 ms 1.2 s 36.8 ms 1.4 s 41.8 ms Q.K einsum + softmax 36.1 s 61.5 ms 1.7 s 141.0 ms 2.0 s 128.3 ms Scores keys-last (softmax last axis) 10.5 s 109.0 ms 0.6 s 198.4 ms 0.7 s 180.2 ms scaled_dot_product_attention 1.4 s 140.4 ms 0.4 s 184.9 ms 0.5 s 148.1 ms Cached loads take 0.01–0.03 s everywhere. What I observed: Compile time grows linearly with the number of attention layers. Every alternative attention layout I tried that compiles quickly runs 5–6× slower on the A20 Pro, so I found no workaround that keeps its speed. During the slow load, ANECompilerService runs almost entirely on the efficiency cores. Requesting a higher QoS, MLOptimizationHints (.fastPrediction, reshapeFrequency), computeUnits = .all and dense instead of palettized weights don't help. Loading several models in parallel additionally gets ANECompilerService killed by jetsam (per-process-limit). The specialization cache doesn't survive reinstalling the app. In our app (Stable Diffusion XL), each UNet chunk with attention takes 110–150 s instead of 6–16 s, so the first launch takes about 25 minutes in the foreground, and in our tests again after every reinstall. The same networks converted to Core AI specialize normally on this device (see our Core AI porting notes). Filed as FB25106520 with a self-contained repro: a coremltools script, an iOS app and a Mac runner, plus results from all three devices. Environment: iPhone 18 Pro (iPhone19,2) and iPhone 17 Pro (iPhone18,1) on iOS 27.0.1 (24A446), M3 Pro on macOS 27.0.1 (26A434), Xcode 27.0, coremltools 8.3.0. Is this a known A20 Pro issue, and is there a recommended way to avoid it until it's fixed? Falling back to the GPU or CPU isn't a good option for us: it avoids the slow load, but gives up the Neural Engine's efficiency, which matters for on-device generation on a phone, and its speed (a full SDXL UNet step on the iPhone 18 Pro takes 509 ms on the Neural Engine vs 1,639 ms with .cpuAndGPU). We'd also like to hear from others which ops their slow first loads involve, to see whether this is specific to attention and softmax or broader.

I'm building an app that uses PrivateCloudComputeLanguageModel as the primary inference tier with SystemLanguageModel as the fallback. The app is entitled (com.apple.developer.private-cloud-compute, granted and provisioned) and generations serve normally. My question is how a client should decide to fall back because in extended measurement, no public signal ever reflects the blocked state I actually hit. What I measured (macOS 27.0 beta, 26A5416b / Xcode 27 beta 27A5237l, entitled signed bundle constructing PrivateCloudComputeLanguageModel directly): Serving stopped mid-run with no leading signal: request N served normally (1.4 s), request N+1 threw LanguageModelError.rateLimited 494 ms later, at cumulative generation 786 for the day. 100% served → 100% refused between consecutive calls. Every quota signal read healthy the entire time: before, during, and after the block. Across 1,517 readings in a single day: quotaUsage.status = belowLimit, isApproachingLimit = false, isLimitReached = false, resetDate = nil, availability = .available. A preflight on these APIs cannot see the condition. The refusal is enforced locally after first contact: rejections return in ~230 ms vs ~0.9–1.4 s for served calls, so the client appears to cache the verdict rather than ask the server per-request. The trigger is a cumulative ledger, not a request rate: 501 generations at 33/min in one 15-minute sitting was fine, and a later arm sustained 39.7/min; two bursts of 16 concurrent at 5.0 and 5.2 req/s served 32/32; the count that tripped survived a process restart and a 4.9-hour idle gap. But it's not a fixed daily number either. 501 fast was fine earlier the same day; the trip came 285 requests later. A rolling window on the order of hours-to-a-day is consistent with this, but nothing here measures its length. Recovery: still blocked at +41 minutes (probes at +1/2/5/10/20/40 min all refused); fully recovered by +20 h with no intervention and no upgrade. Next day served normally from the first request. quotaLimitReached never occurred: not once in ~800 generations plus the blocked period. The wall is typed as the transient error while carrying what the documentation describes as daily quota semantics ("a person either waits for their usage quota to refresh or they upgrade"). limitIncreaseSuggestion is presence-constant: nil at process start, non-nil on every reading after first PCC contact (identical while fully serving and while fully blocked) so its presence can't gate an upsell affordance. The same signals-read-healthy-while-refusing divergence also reproduces against the developer-tool pool (fm serve), which I've reported separately (FB24273854 covers quota exhaustion surfacing there as a generic server_error/500 while /health reports the model available). Questions: Is attempt-and-classify the intended contract? Given that no preflight can observe the blocked state, should a client simply issue the request, treat the typed error as authoritative, and route to SystemLanguageModel? And is the ~230 ms local fail-fast on the blocked path contractual (cheap and safe to probe) or incidental? This is the one that decides how I ship; the rest are diagnostics behind it. What does quotaUsage actually track, and at what granularity? I have driven the entitled app-tier path to a hard block and the developer-tool pool to exhaustion, and no field ever moved. Is there any consumption pattern that moves isApproachingLimit / isLimitReached / resetDate? If the intended answer is "only the per-person daily quota, which these volumes never approached," what is the wall I am hitting at ~786 cumulative, and why does it surface as rateLimited? Should rateLimited and quotaLimitReached drive different client behavior — and which one is the daily allowance in practice? The documentation distinguishes rate limiting ("wait a period and retry") from daily exhaustion ("wait for refresh or upgrade"), but what I observe is the transient-typed error carrying the multi-hour ledger semantics. Concretely: what retry cadence is recommended after rateLimited (my measured recovery horizon was somewhere between 41 minutes and 20 hours. My current design stays on the on-device model and re-probes PCC at a low fixed interval rather than per-request)? And under what condition is resetDate ever populated, given it was nil even while blocked? (Smaller, design guidance): my app can generate a few hundred requests as one feature batch (quiz generation over a user's imported document). Measured: 501 in a sitting was fine, cumulative 786 in a day was not. Since this allowance belongs to the person and is shared with every Apple Intelligence feature, is a several-hundred-request batch a reasonable use of it, or should features like this generate on demand? (I'm aware of the existing feature request for richer quota reporting (FB23378161); this is a narrower design question.) I can attach the measurement driver and timestamped JSONL logs. The divergence is reproducible on a fresh day, though reaching the wall took ~800 cumulative generations.

I'm using the iOS 18+ RecognizedTextRequest, and with no change of code, iOS 27 gives poorer results: lines are dropped, all the text is not recognized it's not my code, because Live Text has the same issue and of course, back to 26 or 18 solves the issue What changed? Only interesting infos I could isolate: The simulator has not the issue Squashing the image horizontally (80% of its width for example) makes the detection significantly better

Hello, With the update from iOS 26 to iOS 27 I have noticed significant regressions and degraded performance when using the Vision Framework for OCR via 'VNRecognizeTextRequest'. The degraded performance is only applicable to the .accurate model, the .fast model is identical between iOS 26 and iOS 27. I have an app that uses this framework extensively for extracting information from the video feed of professional cinema cameras. This runs using en-US, language correction off with a specific region of interest. On iOS 26 everything works reliably as it has for the past few years, with the exact same codebase on iOS 27 many strings that were previously detected are no longer detected, some strings return as if they've been read upside down (ISO1280 is returned as 08ZLOSI) and there are a lot of Cyrillic look alikes mixed into Latin text, there also appears to be a lot more junk characters tacked onto the end of numbers ('12ł' is returned when previously it was just '12'). You often see whole line duplicates too where the same text is recognised twice, once as a single line with all strings combined and once as individual strings. The iOS 27 Simulator doesn't show any of this. I only saw it on real iPads, if you only test in the Simulator you'll miss it. To put numbers on it, I built a test set of about 26,500 frame grabs and ran them through 'VNRecognizeTextRequest' on iPadOS 18, 26 and 27. With the version of my app that's on the App Store today, iOS 26 reads 99.7% of values correctly. On iOS 27 that drops to 65%. I've resolved this issue now and have been able to retain the level of performance that existed on iOS 26, this involves various preprocessing steps to the images as well as a significant amount of validation after the Vision Framework returns its results. These fixes took around 3.5 Days of work which is incredibly frustrating. I would much rather use my time building new features instead of fixing regressions introduced by poorly validated new models that have been shipped in iOS 27. What frustrates me most is this change wasn't announced anywhere and there's no way to opt out. The revision number didn't change so there's no way to keep using the model that worked. If this had shipped as VNRecognizeTextRequestRevision4 apps could have stayed on VNRecognizeTextRequestRevision3 until they'd had a chance to test. Or permanently stayed on 'VNRecognizeTextRequestRevision3' as obviously the new version performs significantly worse. Instead an app that worked fine on iOS 26 now gets wrong text back on iOS 27 with no error, no warning and nothing in the release notes. For a framework people rely on for real work that's a significant regression. It seems that other developers have also come across this issue: https://developer.apple.com/forums/thread/845452 For technical reference, if you diff System/Library/PrivateFrameworks/TextRecognition.framework between iOS 26.5 (23F77) and iOS 27.0 (24A434) you uncover a number of changes. New models on iOS 27 seem to use an '_e5' variant. The text detector in iOS 26 references training run 'yyzn76u6fs' with 88560 iterations, iOS 27 references training run 'hvcthxumvz' with only 10116 iterations. Perhaps an 8x reduction in iterations has something to do with the poor performance in iOS 27? Further, the orientation model changes from iOS 26 'cr_orientation_model_v1' with 1858472 iterations vs. iOS 27 'cr_orientation_model_v1_e5' with 671065 iterations. The Latin and Cyrillic Recogniser changed model entirely from 'cr_tr_model_latincyrillic_v3' on iOS 26 to 'cr_tr_model_latincyrillic_v3_e5' on iOS 27. It seems these 'e5' models are optimised for the neural engine. Is there any way to get the iOS 26 models/behaviour back or plans to back deploy the old model in iOS 27.1 or iOS 27.2? Can future model changes like this come with a new revision number? What testing process does the Vision Team use to validate models as clearly something was missed here? Thanks!

A Core ML model that we used in production on iOS 26 no longer works on iOS 27.0.1. Prediction now fails on every compute unit. Loading it with .all also increases the process footprint by about 2.8 GB, so on 6 GB devices jetsam kills the app shortly after launch (per-process-limit). Environment iPhone 13 Pro (iPhone14,2), iOS 27.0.1 (24A446): the memory spike and the prediction failure both reproduce. The app is killed about 1.5 s after launch. iPhone 15 Pro, iOS 27.0.1 (24A446): the memory spike reproduces (about 3 GB). The app is not killed because this device's limit is higher. macOS 27.0.1 host, small Swift CLI using Core ML: the prediction failure reproduces. The same model and app build worked on iOS 26.x. On an iPhone 15 Pro running iOS 26.6.1, the app peaked at about 570 MiB. Model A compiled .mlmodelc (from an .mlpackage). It is a pipeline of two ML Programs. The input is a fixed-size 640×480 image. model 0: a YOLO-style instance segmentation network converted from TensorFlow. It includes non_maximum_suppression over 1500 candidate boxes. The NMS is followed by range_1d → gather with data-dependent [?] shapes. There is a zero-sized intermediate tensor (tensor<fp16, [1500, 0]>). Results are written with scatter_nd into a fixed-size output [1, 300, 38], plus prototype masks [1, 120, 160, 32]. model 1: post-processing converted from PyTorch. It runs non_zero over the 300 candidates. After that it works on dynamic [?, 1, 480, 640] tensors (upsample_bilinear, greater, cast, mul), then uses tile and reduce_argmax. Symptom 1: prediction fails on all compute units The failure is the same with .all, .cpuAndNeuralEngine, .cpuAndGPU and .cpuOnly, with a real camera image as input: Error Domain=com.apple.CoreML Code=0 "Failed to evaluate model 0 in pipeline" -> "Unable to compute the asynchronous prediction using ML Program. It can be an invalid input data or broken/unsupported model." -> "E5RT: Submit Async failed for [6:1]: Unable to successfully execute plan. @ ExecuteSync (11)" On macOS 27, the following is logged when the model loads: MIL program has non-constant (dynamic) shapes for external input but FlexibleShapeInformation attribute is missing. E5 function will be produced with unknown input shapes and cannot be run without reshaping first. Got input with flexible dimension but no default shapes provided. Will use 1 Symptom 2: about 2.8 GB allocated at load This is phys_footprint right after MLModel(contentsOf:configuration:). The model was loaded alone in a fresh process on an iPhone 13 Pro running iOS 27.0.1. The baseline before loading was 13 MiB. .all: 2858 MiB .cpuAndNeuralEngine: 2857 MiB .cpuAndGPU: 2515 MiB .cpuOnly: 62 MiB The other models in the same app stay under about 520 MiB on iOS 27 (load plus one prediction each). They include object detection, pose estimation and a ViT that runs on the ANE. Another model in the app with data-dependent shapes, a keypoint detector, still loads and predicts correctly on iOS 27, so not every dynamic-shape model is affected. In the field, the JetsamEvent report shows per-process-limit at 3072 MiB. A diskwrites_resource report shows the heaviest stack under Core ML model load → Espresso → MetalPerformanceShadersGraph. Current workaround Loading this model with .cpuOnly on iOS 27 avoids the memory spike, so the app no longer crashes. Prediction still fails, though, so the model can't be used on iOS 27. Questions Is this a known iOS 27 regression in how E5RT handles data-dependent shapes inside ML Program pipelines (NMS, gather, non_zero, zero-sized tensors)? What is the recommended way to export a model like this for iOS 27? Would adding flexible-shape information help, or should NMS and mask post-processing be moved out of the model? Is it expected that unbounded dynamic shapes cause a worst-case allocation of several GB at load time with GPU or ANE compute units? I can't share the model itself, but I'm happy to provide more details (full MIL op listing, logs, sysdiagnose) through Feedback Assistant if that helps.

I think this could be relate to previous post here https://developer.apple.com/forums/thread/848590 But in my testing it seems like most of the time spent was in loading but not compilation. Our app has multiple models but so far it seems like one of them has this issue. The model itself was only 2.2MB, but somehow loading took 50s after compilation? And on 17e it only took 2s to load. But I cannot attach the model here so please advice.