Lately I am getting this error. GenerativeModelsAvailability.Parameters: Initialized with invalid language code: en-GB. Expected to receive two-letter ISO 639 code. e.g. 'zh' or 'en'. Falling back to: en Does anyone know what this is and how it can be resolved. The error does not crash the app

Has anyone else hit this? We have a Mac app that uses FoundationModels with @Generable types for structured output. Starting with macOS 27 beta 5 every guided generation request began logging tokenizer errors and long structured requests slowed from seconds to minutes. Beta 6 and beta 7 both still have it. Filed as FB24310823 on August 11 with a full sysdiagnose and log captures, and we have appended evidence from each beta since. The signature is easy to check. Stream the log while your app generates: log stream --predicate 'subsystem == "com.apple.tokengenerationcore"' --style compact On an affected machine the inference service (TGOnDeviceInferenceProviderService, category guided) prints these two lines in matched pairs, thousands of times: Generated an empty mask at recognizer index N allowedTokenIDs is empty. Something is likely wrong with the tokenizer What we measured on beta 7 today: 9,008 of those pairs in about five and a half minutes of scanning. The errors start about one second into the first request after a fresh app launch, so it needs no warmup. Requests that normally finish in 4 to 12 seconds take 77 to 170 seconds or longer. On beta 5 we measured decode at roughly 0.3 tokens per second on the worst requests. Short requests still finish at normal speed but they emit the same errors while they run, and the quality of the structured content they return is degraded. On betas 5 and 6 we also saw repeated asset release errors for instruct_300m.tokenizer and the instruct_3b tokenizer saying the asset is not marked as in use. For what it is worth, a build that ran clean on beta 4 shows the same behavior on beta 5 and later with no app changes, and the same @Generable schema drives both the fast and the slow requests. But we know that does not rule out something on our side, and we would honestly be happy to learn this is our own bug since that would mean we can fix it. So two questions. Is anyone else seeing this since beta 5? And if you spot something we might be doing wrong on our end, sessions we should be recreating, schema patterns that stress the constrained decoder, anything at all, we would really appreciate the feedback. If it does turn out you are hitting the same thing, a Feedback referencing FB24310823 would help a lot. Thanks!

I'm distributing an encrypted .mlpackage to my app and want to load it entirely in memory without ever writing decrypted weights to disk. I tried MLModelAsset(specification:blobMapping:) as the path to achieve this, but ran into a significant inference performance gap compared to the compiled code path. What I'm trying to do The encrypted .enc file is a serialized FileWrapper of the full .mlpackage, sealed with AES-GCM. At runtime I decrypt it in memory, deserialize the FileWrapper, extract the spec and weight blob, and load via MLModelAsset: static func loadEncryptedPackage(url: URL, configuration: MLModelConfiguration) async throws -> MLModel { // AES-GCM decryption → decryptedData (full serialized .mlpackage) guard let wrapper = FileWrapper(serializedRepresentation: decryptedData) else { throw ... } guard let (specWrapper, specParent) = findSpecWrapper(in: wrapper), let spec = specWrapper.regularFileContents else { throw ... } var blobs: [URL: Data] = [:] collectBlobs(in: specParent, relativePath: "", excluding: specWrapper, into: &blobs) // keys built as URL(fileURLWithPath: rel), e.g. "weights/weight.bin" let asset = try MLModelAsset(specification: spec, blobMapping: blobs) let model = try await MLModel.load(asset: asset, configuration: configuration) // See observation #3 below — must retain these for the model's lifetime objc_setAssociatedObject(model, &retentionKey, Retainer(spec: spec, blobs: blobs), .OBJC_ASSOCIATION_RETAIN) return model } What I observed Predictions are accurate. The blobs are found, weights are applied, and the model produces correct results. Inference is drastically slower than the compiled code path. The same model loaded via MLModel.compileModel(at:) + MLModel.load(contentsOf:) runs inference much faster on the same device with the same MLModelConfiguration (computeUnits = .all). With MLModelAsset the slowdown is consistent across every prediction call, not just the first one. The spec and blob Data objects must stay alive for the model's lifetime. Without retaining them via objc_setAssociatedObject, inference produces NaN outputs or crashes. This suggests Core ML holds a reference back into those Data buffers beyond the load() call, rather than copying them into its own memory during loading. Using the exact blob URI from the spec as the blobMapping key triggers a compilation error. The spec (inspected via strings on the .mlmodel protobuf) stores blob references as @model_path/weights/weight.bin. When I key the blobMapping with URL(string: "@model_path/weights/weight.bin"), MLModel.load(asset:) throws: compiler error: Encountered an error while compiling a model: validator error: The in-memory ML Program must not have a blob file reference but found a reference to mem://weights/weight.bin. With other key formats (e.g. URL(fileURLWithPath: "weights/weight.bin")), this error does not appear — the model loads and predictions are accurate, but inference is slow as in observation #2. The working alternative (which I want to avoid) Decrypting to a temporary directory, calling MLModel.compileModel(at:), loading from the compiled .mlmodelc, then deleting the temp files produces fast inference. Same model, same device, same configuration. The only difference is the compilation step — and the fact that decrypted weights touch disk, which I want to avoid for security reasons. Questions Is MLModelAsset(specification:blobMapping:) expected to produce inference performance equivalent to loading from a compiled .mlmodelc? If not, is the performance gap fundamental to the API or something that can be addressed? Is there any supported way to load an mlprogram model with external weight blobs entirely in memory and achieve inference performance comparable to the compiled code path — i.e. without writing decrypted model data to disk at any point? The validator error "in-memory ML Program must not have a blob file reference" is a hard block when Core ML successfully resolves the blobs and attempts mlprogram compilation. Is this an intended constraint, and does it mean MLModelAsset(specification:blobMapping:) is not the right API for this use case?

I developed a conversational agent using Gradium and it worked fine using the iPhone's built-in speaker on iOS 18.7 and iOS 26.6. I developed similar conversational agent using the Gemini stack and it also worked fine using the iPhone's built-in speaker on iOS 18.7 and iOS 26.6. Now on iOS 27.0, we hear crackling in the transcripts and responses, with both stacks.

Process: MagiMir2 [5177] Path: /Applications/MagiMir2.app/Contents/MacOS/MagiMir2 Identifier: com.magic.magimir Version: 2.0.2 (2.0.2) Code Type: ARM-64 (Native) Role: Foreground Parent Process: zsh [3124] Coalition: com.apple.Terminal [1945] Responsible Process: Terminal [2656] User ID: 501 Date/Time: 2026-09-16 01:16:23.1769 +0700 Launch Time: 2026-09-16 01:16:21.1311 +0700 Hardware Model: Mac16,7 OS Version: macOS 27.0 (26A428) Release Type: User Thread 19 Crashed:: Dispatch queue: com.apple.coreml.MLModelAssetResourceFactory.modelLoadQueue 0 libsystem_platform.dylib 0x18e1bba50 __bzero + 32 1 libc++.1.dylib 0x18e0beca8 std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>::append(unsigned long, char) + 156 2 CoreML 0x199be7d50 operator>>(IArchive&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>&) + 64 3 CoreML 0x199b57fd4 -[MLLoaderEvent extractAndSetModelDetailsFromArchive:] + 336 4 CoreML 0x199b27c88 +[MLLoader _loadModelFromArchive:configuration:loaderEvent:useUpdatableModelLoaders:error:] + 96 5 CoreML 0x199b25938 +[MLLoader _loadModelFromAssetAtURL:configuration:loaderEvent:error:] + 280 6 CoreML 0x199b256c0 +[MLLoader loadModelFromAssetAtURL:configuration:error:] + 112 7 CoreML 0x199a6f18c -[MLModelAssetResourceFactoryOnDiskImpl modelWithConfiguration:error:] + 120 8 CoreML 0x199bd29b4 __60-[MLModelAssetResourceFactory modelWithConfiguration:error:]_block_invoke + 72 9 libdispatch.dylib 0x18e00a5a0 _dispatch_client_callout + 16 10 libdispatch.dylib 0x18e000490 _dispatch_lane_barrier_sync_invoke_and_complete + 56 11 CoreML 0x199bd287c -[MLModelAssetResourceFactory modelWithConfiguration:error:] + 284 12 CoreML 0x199be8ae8 -[MLModelAssetModelVendor modelWithConfiguration:error:] + 156 13 CoreML 0x199b04a78 -[MLModelAsset modelWithConfiguration:error:] + 116 14 CoreML 0x199b89e94 +[MLModel modelWithContentsOfURL:configuration:error:] + 176 15 MagpieMobile 0x1026dd974 0x10213c000 + 5904756 16 MagpieMobile 0x102710d28 0x10213c000 + 6114600 17 magic_flutter_plugin_magpie 0x100e5c40c closure #1 in MagicFlutterPluginMagpiePlugin.preloadModels(result:) + 192 18 magic_flutter_plugin_magpie 0x100e56134 thunk for @escaping @callee_guaranteed () -> () + 28 19 libdispatch.dylib 0x18dff0a34 _dispatch_call_block_and_release + 32 20 libdispatch.dylib 0x18e00a5a0 _dispatch_client_callout + 16 21 libdispatch.dylib 0x18dff8fc0 _dispatch_lane_serial_drain + 744 22 libdispatch.dylib 0x18dff9abc _dispatch_lane_invoke + 392 23 libdispatch.dylib 0x18e003f58 _dispatch_root_queue_drain_deferred_wlh + 284 24 libdispatch.dylib 0x18e00385c _dispatch_workloop_worker_thread + 720 25 libsystem_pthread.dylib 0x18e1adf9c _pthread_wqthread + 292 26 libsystem_pthread.dylib 0x18e1acce0 start_wqthread + 8

While I am liking Siri AI I find that it sometimes will just end a conversation. I can be going back and forth on a topic, and suddenly the input field is gone, and at the bottom of the window it says "Siri ended the conversation". Why does it do this? Once it has, the conversation is just an archive, there is no way to continue the conversation. Starting a new conversation of course forgets everything that came earlier so is pretty useless. I can not understand why Apple would make it work this way. The end point seems random, sometimes it is very quickly after a conversation starts, sometimes it never happens even after days go by.

Device: iPhone 15 Pro iOS: 27.0 beta 4 (same issue on beta 3) Related Feedback: FB23788932, FB23961529 (both marked "More than 10 similar reports", still Open) Siri AI / Apple Intelligence never activate. Extensive testing rules out account/region as the cause — this looks like a broken asset delivery / enrollment pipeline. Symptoms: Console (subsystem com.apple.GenerativeModels) shows repeated calls: isUseCaseAccessNotGrantedSecure: user=501, input=["com.apple.Siri.EnhancedSiriDisablement"] isUseCaseAccessNotGrantedSecure: returning granted (false); no pendingEnrollment for any of [...] ["com.apple.Siri.EnhancedSiriDisablement"] -> false This is consistent across hundreds of calls — the system never attempts enrollment, it just returns false immediately, every time. Settings > General > iPhone Storage shows 3.38GB already allocated to "Apple Intelligence," but the feature never activates — suggesting an incomplete/corrupted asset set rather than missing data entirely. Toggling Wi-Fi off prompts a ~9.5GB "intelligence tools" download. Confirming it produces no progress and no result. Siri language pack downloads get stuck at 100% and never proceed to activation. Search and Siri Suggestions indexing (Settings > Siri & Search) initially shows no percentage, disappears, then reappears days later with a percentage stuck for 24+ hours despite "Last updated: X minutes ago" continuing to refresh — suggesting the background worker is alive but stuck, possibly hitting the same broken asset service. Region-dependent behavior (most useful clue): in a region NOT eligible for Siri AI (Ukraine), legacy Siri (old interface) responds normally to "Hey Siri." In a region eligible for Siri AI (US — tested with a brand-new Apple Account, region set to US, no data restored from backup), "Hey Siri" activates (wake word detection works) but the request hangs indefinitely with no response, and legacy Siri does not answer either. This suggests the system correctly detects eligibility, but there is no fallback to the legacy Siri response pipeline when the region is eligible yet the new Foundation Models assets fail to finish downloading/activating. Already tried (no effect on any of these): Reset Network Settings Reset All Settings Multiple restarts, multiple Wi-Fi networks, cellular data Changing device Language & Region to US Fresh Apple Account created with US region, Payment Method: None, signed in clean (no backup restore) — identical isUseCaseAccessNotGrantedSecure: false result, legacy Siri also silent under this account Steps to reproduce: Update iPhone 15 Pro to iOS 27 beta 3 or 4 via Software Update (not clean install). Settings > Apple Intelligence & Siri — no functional enrollment progress. Toggle Wi-Fi off — download prompt appears, confirming does nothing. Say "Hey Siri" — activates, no response. Has anyone else on iPhone 15 Pro hit this specific isUseCaseAccessNotGrantedSecure / no pendingEnrollment pattern? Any word on whether this is a known/tracked issue for beta 5?

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

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

I'm trying to understand the intended relationship between OpenIntent and the new .system.open App Intent schema introduced in iOS 27. From the documentation: OpenIntent (available since iOS 16) is described as an intent that opens an associated item. iOS 27 introduces the .system.open schema, which also appears to represent opening an entity or piece of app content. My questions are: For an app that supports iOS 27+, is .system.open intended to replace OpenIntent, or do the two serve different purposes? For apps that support both iOS 26 and iOS 27+, is the recommended approach to have two structs that implement the same opening logic, one with @AppIntent(schema: .system.open) and the other implementing the OpenIntent protocol? Thanks! References: open protocol OpenIntent

I’m developing an independent project in Scotland called Isla Watson. The architecture is built around a simple principle: the model is replaceable; the identity is not. Long-term memory, persistent internal state and identity are designed to remain outside the foundation model, allowing local models to act as replaceable reasoning and language components without resetting the companion. I’m now exploring whether Apple Silicon and MLX could provide the long-term local compute platform for the system — including specialist Mac nodes for reasoning, memory, speech and perception, with distributed inference when larger models are required. A particular area of interest is whether multiple Macs can be used in two complementary ways: as independent specialist agents during normal operation; and as a distributed MLX inference group when a larger model exceeds the capacity of one machine. The first technical study I’d like to establish is a reproducible 1-node → 2-node baseline, measuring model capacity, unified-memory use, time to first token, generation throughput, power consumption, agent concurrency and distributed scaling efficiency. The wider research goal is to keep persistent identity and state independent from whichever foundation model is currently providing language and reasoning. I’d particularly value guidance from anyone working with MLX distributed inference, Thunderbolt/RDMA multi-Mac setups, or local agent architectures. I’ve also posted an architecture-level overview in the MLX GitHub community and have a one-page public brief available for anyone interested in the wider design. https://github.com/ml-explore/mlx/discussions/4482

I am using an iPhone 16 Pro with iOS 27 Public Beta. In the Netherlands, the Apple Intelligence option has disappeared from the settings.

I am getting FoundationModels.LanguageModelError error -1 when trying to use Foundation Models on the visionOS 27 simulator. It works on the iOS 27 simulator. Is this a bug with the visionOS 27 simulator specifically?

I would like to raise a platform-level question about the future relationship between Apple Intelligence, App Intents, iOS permissions, and third-party AI systems. I have been deeply invested in the Apple ecosystem for many years. One of Apple's greatest strengths is that iPhone, iPad, and Mac work together with very little friction. The other major strength is Apple's strong privacy and security model. Generative AI is now creating a new tension between those two strengths. On the Mac, users can explicitly grant AI tools relatively broad access to files, folders, and, in some cases, application controls. This has changed what non-technical users can accomplish. I am not a software developer, but with AI assistance I can now design workflows, create automation, work with structured data, and build tools on my Mac that would previously have required professional knowledge. In other words, AI has not merely made the Mac more efficient. It has expanded the capabilities of the user. This makes the restrictions on iPhone increasingly noticeable. The issue is not the computing power of the iPhone. Modern iPhones are extremely capable devices. The issue is that third-party AI systems cannot yet work with the user's personal context, application data, and device capabilities with the same degree of flexibility, even when the user explicitly wants to grant such access. My question is: Could iOS evolve toward a more general, user-controlled permission architecture for third-party AI agents? I am not suggesting unrestricted access to the device. I am suggesting a system in which users can explicitly grant narrow and persistent permissions to an AI provider or AI agent. For example: Allow read-only access to a specific folder. Allow search access to selected Notes or note categories. Allow access only to a particular Photos album. Allow calendar read access but not modification. Allow an AI to search Photos but never delete them. Allow routine read/search operations automatically, while requiring confirmation before modification, deletion, sending, purchasing, financial activity, or other sensitive actions. From a platform-design perspective, this could potentially be implemented as multiple layers: iOS defines the maximum permitted scope. The user explicitly chooses the resources and capabilities available to the AI. The AI provider is expected to operate within the minimum necessary scope. Sensitive or destructive actions require an additional confirmation boundary. Access can be reviewed, reduced, or revoked centrally by the user. This seems consistent with Apple's existing security philosophy rather than opposed to it. The goal would not be to give an AI "full access." The goal would be to create an OS-level capability model in which the user can safely delegate specific access and actions to AI. App Intents already provides a structured way for applications to expose actions and entities to the system. Apple Intelligence is also increasingly able to work with application capabilities and user context. The question is whether this model could eventually be extended into a broader framework for third-party AI systems. For example, rather than allowing ChatGPT, Claude, Gemini, or another model to directly inspect the device, iOS could remain the trusted intermediary. The AI could request a capability or a piece of context. iOS could evaluate: Which data is being requested? Has the user authorized this category? Is the request read-only or destructive? Does the request require confirmation? How much context should be disclosed? Should the AI receive raw data, structured data, or a filtered result? This would allow Apple to remain the security and permission authority while still letting users benefit from advanced external AI models. I believe this distinction is important. Apple does not necessarily need to expose raw device access to third-party models. Instead, Apple could expose a secure capability layer controlled by the OS and the user. This also raises a broader architectural question about Siri and Apple Intelligence. Does Siri itself need to become the most capable general-purpose AI model? Perhaps not. A possible architecture would be: Siri / Apple Intelligence understands user intent, manages personal context, controls permissions, identifies the appropriate application or data source, performs local or private operations where appropriate, and delegates advanced reasoning when needed. Third-party AI models provide advanced reasoning, planning, interpretation, generation, or domain-specific intelligence. iOS remains the trusted security boundary between the AI model and the user's personal environment. In such a system, Apple would not need to sacrifice privacy in order to support highly capable AI. It could instead become the platform that provides the safest interface between powerful AI systems and a user's personal digital environment. From a user-experience perspective, I believe this is becoming increasingly important. AI has made my Mac substantially more useful because it allows me to accomplish tasks that were previously beyond my technical ability. I would like that same expansion of capability on the iPhone. Today, the Apple ecosystem is seamless at the data and device level, but less seamless at the AI capability level. Mac can increasingly function as an AI-enabled working environment, while iPhone remains much more restricted. That difference may become more significant as AI agents become more capable. So my main request is: Please consider allowing iPhone users to grant third-party AI systems broader but carefully scoped access to device data and application capabilities. Not unrestricted access. Not a bypass around Apple's privacy model. Rather: user-controlled, granular, revocable, OS-mediated AI permissions. If Apple can provide that securely, I believe it could significantly improve the usefulness of iPhone while preserving the privacy and security principles that make the Apple ecosystem distinctive. I would be very interested to know whether App Intents, Apple Intelligence, or another future framework is intended to evolve in this direction.

Filed as FB23652582. In Xcode 27 beta, this no longer compiles when the deployment target is below iOS 27: @available(iOS 18.0, *) @AppEntity(schema: .photos.asset) struct AssetEntity: IndexedEntity { ... } // error: 'asset' is only available in iOS 27.0 or newer The identical source compiles under Xcode 26. It looks like the @AppEntity(schema:) macro now resolves .photos.asset to a declaration annotated for iOS 27, whereas in Xcode 26 it resolved to the (now-deprecated) iOS 16 declaration. What seems off: the .photos.album entity in the same domain still builds fine at an iOS 18 deployment target — only .asset requires iOS 27. That asymmetry is what makes me think it may be an unintended availability change rather than a deliberate one. Has anyone else hit this? And is this intended — i.e. is .photos.asset now meant to be iOS 27+ only, or should it still be usable from apps that deploy to iOS 18?

Regarding the 'weight list' of Siri: can you all provide technical specifics on how a model qualifies for this list, and can a developer-supplied model/adapter ever handle requests that originate from the system-wide Siri interface?

I am trying to build the example on device model example in video WWDC26/241 (What’s new in the Foundation Models framework). I have included the coreai-models package from GitHub but the build still fails with; What’s new in the Foundation Models framework Suggestions appreciated!

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

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

I am developing a third-party macOS application that uses Apple Foundation Models, including Private Cloud Compute (PCC). I would like to confirm the supported distribution requirements for this use case. Specifically: Can a third-party macOS application use Apple Foundation Models / PCC as part of its application functionality? Is PCC usage supported when the macOS application is distributed outside the Mac App Store using Developer ID signing and Apple notarization? Are there any additional entitlements, distribution requirements, or restrictions for PCC when distributing outside the Mac App Store? I intend to use only Apple's documented and supported APIs and will not attempt to bypass PCC availability, quota, entitlement, or other platform restrictions. Thank you.