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.

We found an apparent iOS 27 WorkflowKit bug when implementing: @AppIntent(schema: .photos.editAsset) with an entity conforming to: @AppEntity(schema: .photos.asset) Despite Apple’s general guidance that schema entity types may be renamed, Siri only worked when our entity’s Swift type was named exactly AssetEntity. Controlled on-device results: AssetEntity — works PhotoAssetEntity — fails FooAssetEntity — fails For the failing names, neither the entity query nor perform() was reached. WorkflowKit logged: Failed to retrieve entity metadata Error Domain=WFActionErrorDomain Code=6 Siri responded: Unable to retrieve the data information to process. The generated App Intents metadata was internally consistent, and the issue persisted across clean installs and a device restart. Current workaround: name the .photos.asset entity type exactly AssetEntity. Tested with Xcode 27.0 beta (27A5252f) and iPadOS 27.0 (24A5423a). Filed with Apple as FB24604095 for anyone from Apple investigating this behavior.

I’m building Summon (https://github.com/NakliTechie/summon), an open-source native macOS launcher that uses the on-device SystemLanguageModel. Summon creates a fresh LanguageModelSession for each query and attaches only the read-only tools relevant to that query. It currently calls prewarm() after the first keystroke using a temporary session, then creates a different session for generation. The documentation describes prewarm(promptPrefix:) as loading the resources required “for this session.” I would value guidance on four points: Is the prewarming benefit scoped to that exact LanguageModelSession instance? Does a later session using the same SystemLanguageModel receive any benefit? For an ephemeral launcher, is retaining one session preferable to creating a fresh session per query? Which Foundation Models Instrument signal identifies an ineffective prewarm or cache invalidation? Thank You Chirag

I’m trying to understand the intended relationship between IndexedEntity.attributeSet, defaultAttributeSet, and displayRepresentation. For example: struct TrailEntity: IndexedEntity { var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "(trail.name)", subtitle: "(trail.location)" ) } var attributeSet: CSSearchableItemAttributeSet { let attributes = CSSearchableItemAttributeSet() attributes.keywords = trail.keywords return attributes } } Should attributeSet instead be initialized with defaultAttributeSet and then have the additional attributes assigned to it? var attributeSet: CSSearchableItemAttributeSet { let attributes = defaultAttributeSet attributes.keywords = trail.keywords return attributes } The documentation says defaultAttributeSet contains values derived from displayRepresentation, but it also describes precedence between displayRepresentation and attributeSet, which suggests Spotlight reads them separately during indexing. So what is the intended pattern? Does overriding attributeSet require including defaultAttributeSet to preserve title/subtitle/image metadata, or is attributeSet only meant for additional Core Spotlight metadata? If the latter, what is the intended use case for overriding or directly using defaultAttributeSet?

皆さん、はじめまして。プログラミングに対する知識がないので、AIを使いながらiPadでTelloのドローンを操縦できるアプリを作っています。このアプリはシミュレーション飛行とドローンの実機飛行ができるアプリにしたいのですが、ドローンの実機飛行を行うためのWi‐Fi接続ができません。（iPadでのシミュレーション飛行が可能です）iPadの基本的な設定はAppleに教えていただき、設定変更を行いましたが、どうしても接続できないので、わかる方法を教えていただけると嬉しいです。 コードを添付いたしますので、ご教示ください。 ドローンアプリコード

I am developing a macOS developer tool that uses Apple Foundation Models, including the Private Cloud Compute (PCC) model. On macOS 27, the Foundation Models CLI provides fm serve, which exposes a local Chat Completions API, including: POST /v1/chat/completions My application communicates with this local API on the user's own Mac to provide agent-style development features. The Foundation Models CLI Legal Notice states: “You are also agreeing to not programmatically access or use Apple models through Apple software or services except as expressly permitted.” I would like to confirm whether using the local API intentionally exposed by fm serve from a third-party macOS application distributed to users is considered an expressly permitted use. The application would: use only the interfaces and endpoints officially exposed by the fm CLI; run fm serve locally on the user's Mac; use the user's own Foundation Models / PCC availability and quota; not bypass quota limits; not use private or undocumented APIs; not reverse engineer Apple services. Is this use of fm serve permitted for a distributed third-party macOS application? If so, are there any additional requirements or restrictions that developers should follow when distributing an application that integrates with fm serve in this way? Thank you.

I would like to understand the foundations of connecting my apps api structure to corporate reporting in regards to textile manufacturing. utilizing the core ML and vision through smartphone to link raw data capture and strategic execution.

I'm looking for a supported way to read intermediate tensors from a model executing on the Apple Neural Engine - specifically the output of an individual node in the compiled graph, rather than only the final output. What I'm trying to do: validate a from-weights reimplementation of a model against the real thing, layer by layer. Comparing only the final output tells me the reimplementation is wrong but not where; a per-layer comparison would localise it immediately. What I've established so far: A compiled ANE program can be executed unprivileged through the public graph API, and the final readout matches, so the execution path itself is reachable. Intermediate activations don't appear in host memory during normal operation, which is expected since the scheduler keeps them in accelerator-local storage. Requesting a per-node output appears to hit a kernel-side check that an ordinary process doesn't satisfy. Questions: Is there a supported API for retrieving per-node outputs from an ANE-scheduled graph - a debug or instrumentation mode, an Instruments template, or a Core ML compute-plan facility that surfaces them? Failing that, is there a supported way to make a specific node materialise its output to a host-visible buffer - for example by splitting the graph, marking an intermediate tensor as a model output, or compiling with that node as a terminal operation? I'm aware this may change scheduling and defeat the purpose, but I'd like to know whether it's the intended approach. If neither exists, is that a deliberate design boundary rather than a gap? A clear "no" is a useful answer and I'll stop looking. I'm not asking about any particular shipped model, and this isn't a request to bypass anything - the question is whether the platform exposes per-node observability for ANE execution at all, and if so what the supported entry point is. Thanks.

I’m evaluating a third-party Swift-based “orchestration layer” for enterprise AI workloads on Apple Silicon — it claims to handle job queuing, scheduling, batching, memory management, monitoring, auditing, and failover on top of on-device inference. Given the Core AI framework’s device-specialization step and InferenceFunction pipeline (and MLX’s unified-memory model), how much of this kind of orchestration is already handled natively versus something a developer would still need to build themselves? Specifically: 1. Does Core AI’s inference pipeline provide any built-in job queuing/batching across multiple concurrent requests, or is that entirely app-side? 2. Is there native failover/monitoring tooling for on-device inference, or would a developer need to build that themselves (e.g., via os_log, MetricKit, custom retry logic)? 3. For memory management across CPU/GPU/ANE, does unified memory in MLX/Core AI eliminate most of the manual management a custom orchestration layer would otherwise need to solve? Trying to understand what’s genuinely differentiated in a third-party layer versus what Apple’s stack already provides out of the box. Appreciate any insight from folks who’ve built with Core AI/MLX in production.

import Playgrounds import FoundationModels #Playground { do { let session = LanguageModelSession() let response = try await session.respond( to: "Explain SwiftUI in one sentence." ) print(response.content) } catch { print("Error: \(error)") } }``` I tested Foundation Models with this simple code, and it generated this error: "Error Domain=ModelManagerServices.ModelManagerError Code=1026 \"(null)\" UserInfo={NSMultipleUnderlyingErrorsKey=(\n)}" I tried restarting my Mac and Apple Intelligence, but that didn't work. What did work was updating Xcode and the simulators to the latest possible version.

Hi all, I’m seeing what looks like a bug with AppShortcutParameterPresentation and the Shortcuts app. Any time I provide an OptionsCollection to a shortcut so I can give it a nice category name and symbol in Shortcuts, it hides all other existing app shortcuts that my app has from the UI. I have created a sample that illustrates the problem. My app provides two App Shortcuts: A simple shortcut with no parameters. A shortcut with two parameters. Its Destination parameter uses AppShortcutParameterPresentation to generate “Home” and “Office” options in a separate section. When the second shortcut is present, the first parameterless shortcut disappears from the Shortcuts app. If I comment out the shortcut containing parameterPresentation, the parameterless shortcut appears again. Before commenting out: After commenting out the second shortcut: Here's the code: import AppIntents struct ParameterlessIntent: AppIntent { static let title: LocalizedStringResource = "Parameterless Intent" static let description = IntentDescription("Runs without asking for any parameters.") func perform() async throws -> some IntentResult { .result() } } struct ParameterizedIntent: AppIntent { static let title: LocalizedStringResource = "Parameterized Intent" static let description = IntentDescription("Runs with a destination and a copy count.") // The same provider is used by this parameter and by ParameterPresentation below. @Parameter( title: "Destination", optionsProvider: DestinationOptionsProvider() ) var destination: String @Parameter(title: "Copy Count", default: 1) var copyCount: Int static var parameterSummary: some ParameterSummary { Summary("Send \(\.$copyCount) copies to \(\.$destination)") } func perform() async throws -> some IntentResult { .result() } } nonisolated struct DestinationOptionsProvider: DynamicOptionsProvider { func results() async throws -> [String] { // Each generated App Shortcut option is a value for the Destination parameter. ["Home", "Office"] } } struct BugReproductionShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { // This parameterless shortcut should always appear in the Shortcuts app. AppShortcut( intent: ParameterlessIntent(), phrases: [ "Run the parameterless shortcut with \(.applicationName)" ], shortTitle: "Do I exist?", systemImageName: "1.circle" ) #warning("The presence of this shortcut causes the top one no longer appear in Shortcuts.app") AppShortcut( intent: ParameterizedIntent(), phrases: [ "Run the parameterized shortcut with \(.applicationName)" ], shortTitle: "Parameterized Shortcut", systemImageName: "2.circle", parameterPresentation: ParameterPresentation( for: \.$destination, summary: Summary("Send to \(\.$destination)") ) { // This title and symbol create a separate section in Shortcuts. OptionsCollection( DestinationOptionsProvider(), title: "Destination Shortcuts", systemImageName: "mappin.and.ellipse" ) } ) } } This code and reproduction is as of Xcode 27 Beta 6 and happens on older versions as well. Is there a known limitation with this or is this somehow expected behavior? If so, how can I mitigate this issue and provide a nice title for another shortcut, while keeping the old parameterless shortcuts present? Thanks!

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 developing a factual snooker application using the on-device SystemLanguageModel on the current iOS 27, Xcode and macOS betas. The app allows someone to ask questions about professional snooker players. A tool searches my server and returns verified player data such as the player’s ID, name, nationality and date of birth. I have encountered a reproducible false-positive guardrail violation when the user asks about the professional snooker player Judd Trump. For example: Tell me about Judd Trump With the default model configuration, the request fails because the input or output is classified as potentially sensitive or unsafe. Using permissive content transformations solves the problem when generating a normal String: let model = SystemLanguageModel( useCase: .general, guardrails: .permissiveContentTransformations ) let session = LanguageModelSession( model: model, tools: [FindPlayerTool()], instructions: """ Answer factual questions about professional snooker players. Always use the supplied tool and only use verified tool data. Names returned by the tool are names of real snooker players and should be treated only as sporting entities. """ ) let response = try await session.respond( to: "Tell me about Judd Trump" ) This successfully calls the tool and produces a factual string response. However, I need guided generation because the model should be able to choose a combination of predefined UI components, such as: A player card A match card An event card A rankings table Explanatory text A simplified response type looks like this: @Generable struct CueQueryReply { let blocks: [ReplyBlock] } @Generable enum ReplyBlock { case playerCard(PlayerCardBlock) case text(TextBlock) } @Generable struct PlayerCardBlock { let playerId: Int let name: String let nationality: String let born: String } @Generable struct TextBlock { let text: String } The guided request is: let response = try await session.respond( to: "Tell me about Judd Trump", generating: CueQueryReply.self ) This reproduces the guardrail violation, even though the model is configured with: guardrails: .permissiveContentTransformations I understand that the documentation says permissive content transformations apply to string generation and that guided generation behaves like the default guardrails. However, this creates a difficult limitation for legitimate factual applications. “Judd Trump” is the real name of a professional snooker player, and the data is coming from a controlled, verified API. Renaming, removing or concealing the player is not a viable product solution. My questions are: Is this specific “Judd Trump” behaviour considered a guardrail false positive that should be reported through Feedback Assistant? Is there any supported way on iOS 27 to use permissive content transformations with guided generation? Can Dynamic Profiles, Dynamic Generation Schemas or another Foundation Models API change the guardrail behaviour for a controlled guided-generation request? Is there a recommended architecture for producing typed UI instructions while retaining the permissive behaviour available to string responses? Would generating only component types and verified IDs—for example .playerCard(playerId: 12)—be the recommended approach, provided the actual player data is resolved and displayed by SwiftUI? I understand the need for safety guardrails and am not attempting to disable the model’s underlying safety behaviour. I am trying to process a harmless, factual sporting name while using Foundation Models’ typed output features. The on-device model otherwise appears capable of handling this use case well, and keeping the experience on-device, private and free of external API dependencies is an important part of the product. I would appreciate any guidance from the Foundation Models team about whether this is expected behaviour, a beta issue, or something for which there is an intended iOS 27 solution.

Hey everyone, hoping to compare notes on something we have been chasing since beta 5. We have a Mac app that uses FoundationModels with @Generable types for structured output. Starting with macOS 27 beta 5, guided generation requests began logging tokenizer errors and our longer structured requests slowed from seconds to minutes. We are still seeing the same thing on beta 6 and beta 7. We filed it as FB24310823 on August 11 with a sysdiagnose and log captures. The signature is easy to check if you want to see whether your machine does it too. Stream the log while your app generates: log stream --predicate 'subsystem == "com.apple.tokengenerationcore"' --style compact On our 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 Some numbers from beta 7 today: 9,008 of those pairs in about five and a half minutes. The errors start about one second into the first request after a fresh app launch. 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 structured content they return looks degraded to us. 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 seeing a reproducible difference in Foundation Models behavior between an iPhone 16 and iPhone 17 Pro Max, both running iOS 27.0 beta 6. My pipeline is roughly: Input → model generation → tool call → validation/correction → structured output Each test starts with a fresh model session. I run the same 50-case dataset on both devices with the same app build, prompt, tool, data, and execution order. The main difference is not just speed: the iPhone 16 consistently makes many more tool calls, which causes the session context to grow until some runs exceed the available context window. Both devices report a context size of roughly 4,096 tokens. Metric iPhone 16 iPhone 17 Pro Max Completed 30/50 49/50 Total tool calls 222 67 Mean calls/run 4.44 1.34 Max calls/run 22 2 Verified outputs 75.1% 91.0% The pattern is very consistent across repeated runs. On the 17 Pro Max, most requests converge after 1–2 tool calls. On the iPhone 16, some requests enter longer tool/correction loops and eventually fail because the context grows too large. I can probably mitigate this by limiting tool calls or changing the prompt, but I'd like to understand the underlying behavior. Is this difference expected across supported devices even on the same OS version? In particular: Can different on-device model variants be used depending on hardware? Is there a way to determine which model/profile a SystemLanguageModel session is using? Should tool-selection behavior be expected to remain reasonably consistent across devices? Would this be worth filing as a Foundation Models regression during the beta?

Environment iOS 27 Developer Beta iPhone17,3 Siri language: English Apple Intelligence availability/configuration differs depending on account/region state Observed behaviour Siri appears to expose behaviours normally associated with the newer intelligence architecture even when the Apple Intelligence experience is not fully enabled. Examples observed include: contextual follow-up questions across multiple turns; responses maintaining the subject of the previous request; different Siri visual/pulsing states depending on input; ChatGPT hand-off through Siri while preserving the original request; UI/settings references related to newer Siri intelligence capabilities; changes in Siri-related UI depending on Apple Account configuration. Reproduction example Invoke Siri. Ask a location/weather question. Ask follow-up questions without repeating the location or subject. Siri continues using the previous conversational context. Similar continuity can be observed across other queries. I have also observed differences in Siri UI and available settings after changing Apple Account configuration, while remaining on the same device and OS build. Question Is the contextual Siri architecture being deployed independently from the full Apple Intelligence feature set in iOS 27, or is this behaviour expected as part of the current beta implementation? I am particularly interested in understanding whether Siri’s contextual/runtime components and Apple Intelligence availability are now intentionally decoupled.

Está indexando en segundo, plano, pero no me aparece el 100, para Inhabilitar el software que se quede atrás, para evitar el cidrado extremo, no tengo la membresia debido a que estoy dado de alta como como Desarrolador, y Siri es la que encripta mis datos en la nube, con Intelligence, como mi teléfono está intervenido, es imposible que se libere el Xcode, sin embargo necesito el rotor del segundo plano, ya que la programación funcionó, y El sistema está trabajando al cien, solo necesito acceder al rotor del segundo plano

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