I submitted a feedback report: FB25430532 Many thanks for your response and support.

Thanks for the detailed explanation. I don't really think it helps my case, though, because I already follow both recommendations: The models aren't in the app bundle. They're delivered as Apple-hosted Background Assets packs. On first install I copy the compiled models once into Application Support, with isExcludedFromBackup set. I only re-copy when the asset pack itself changes. An app update doesn't touch these files: the path, contents and modification dates all stay the same. I load from that stable location, never from the bundle or the asset-pack delivery folder. I also tried an App Group container as the storage location. The result was the same. The cache still doesn't survive an update. The models stay byte-identical and stay at the same path, and only the build number changes. After the update, the first load re-specializes again. On iPhone 18 Pro Max that takes about 30 seconds, almost all of it in my largest model. Later loads are fast again until the next update. The per-app index under Library/Caches/com.apple.e5rt.e5bundlecache appears to reference compiled Neural Engine programs held by the system (aned), not by the app. So I suspect the cached programs are being discarded when the app is installed or updated, rather than the cache key changing. For now, I do a throwaway warm-up load in the background on the first launch after each update. That hides some of the cost, but on A20 and M6 devices the user still sees a long first load if they start trying to use it right away.

Hope an Apple Engineer can respond someday...

Some further info on M6, (but also expeiencing the same issue on A20): Same issue here on an M6 Mac mini (Mac18,5, Core AI architecture h18g), macOS 27.0 (26A425), Xcode 27.0, so it isn’t limited to A20 Pro. In our case, attention isn’t involved: the slow graphs are long unrolled LSTM recurrences. Model: a music source-separation network split into 22 FP16 Core ML components, loaded with .cpuAndNeuralEngine. MLComputePlan places every device-assigned operation on the Neural Engine. Cold first load on M6, per component (cached reloads are 0.01–0.04 s): 6 stage prefixes (57-step bidirectional LSTM): 12.7–12.9 s each 3 recurrent cells (52 steps): 8.0–8.2 s each 3 recurrent cells (34 steps): 4.9–5.0 s each Conv encoders/decoder: 1.1–3.1 s each Whole model (22 components): about 123–145 s The same compiled .mlmodelc files on M4: An isolated 26-step LSTM: 1.3 s on M4 vs 4.4 s on M6. The 26/17-step variant of the whole model: about 25 s on M4 vs about 103 s on M6. Compile time grows with the number of unrolled steps. For one LSTM: 8 steps 1.2 s, 19 steps 3.1 s, 57 steps 11.7 s. Almost all of it is ANECompilerService CPU time. Loading components in parallel only reduced the total from 145 s to 121 s, because the compiler largely processes them one at a time. Compiler crash: a 338-step LSTM graph that loads in 21 s on M4 crashes ANECompilerService on M6, with “Thread stack size exceeded due to excessive recursion” in SubgraphIdentification::ComputeReachableMap (called from ComputeReachabilityMaps / AddBoundaryTensorsForAcyclicCluster). Core ML retries, caches nothing, and every later load takes about 113 s again. Core AI didn’t help us. For the 57-step prefix component: Core ML: 12.8 s Core AI precompiled with coreai-build compile --architecture h18g --preferred-compute neural-engine: 16.3 s (still runs ANECompilerService on first load) Core AI source .aimodel specialized on device: 161.6 s Just to note, model specialization on an iphone 16 pro max finished in about 30 seconds (iOS 27)

This also happens on M6 devices as well. great job Apple.

Happens to me as well, I opened my thread here: https://developer.apple.com/forums/thread/848590 No response from Apple. But this is definitely confirmed. Not sure how they missed this and didnt bother testing anything coreml related.

Apple has a native way to do this: https://developer.apple.com/documentation/coreml/encrypting-a-model-in-your-app ,but when I try it, my model fails to load. It works fine unencrypted, but encryption breaks it. Seems to be an issue with multi function models.

Is there any update to this? I see Apple did the same for the neural engine now, and I still don’t know what devices actually support background GPU usage. Testing on a 16 pro max and requested resources never contains GPU. I don’t know how Apple treats their developers like this.