I'm seeing what appears to be different UISceneAppIntent behavior between iOS and Designed for iPad on macOS, and I'd like to confirm whether this is expected. I'm working on an iOS app that defines an AppIntent conforming to UISceneAppIntent from the AppIntents framework. The intent is handled by a scene delegate conforming to both UIWindowSceneDelegate and AppIntentSceneDelegate. On iOS, everything works as expected: If the app is launched for the first time from Shortcuts, the intent is available via connectionOptions.appIntent in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is called. However, when running the same iOS app on macOS in Designed for iPad mode, the behavior is different: If the app is launched from Shortcuts, connectionOptions.appIntent is always nil in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is never called, even though the application is successfully activated. Is this expected behavior? I noticed that the AppIntents framework explicitly marks both AppIntentSceneDelegate and UISceneAppIntent as unavailable on macOS: @available(iOS 26.0, tvOS 26.0, *) @available(macOS, unavailable) @available(watchOS, unavailable) public protocol AppIntentSceneDelegate : UISceneDelegate Since the app is running on macOS in Designed for iPad mode and still uses the iOS binary, I wasn't sure whether these scene-based APIs are expected to work in this environment or whether they are intentionally unsupported. Has anyone from Apple or the community been able to confirm whether this behavior is by design, or whether it should be considered a bug? I'd appreciate any clarification.

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?

Actually trick to change language to English UK, restart and change back to English US worked for me. After this in an hour notification showed up and Siri AI was ready.

I live in Canada and I called apple support, they said the new Siri ai isn’t available in some parts of Canada. I’ve changed my region to united states and now it’s just a waiting game. If i now get it fast and quick I’ll let u guys know

In my app, I adopt ‘App Intents’ and ‘App Entities’ for various items and actions in my app. These work in the Shortcuts app, and users can use Find Intents to lookup information or use the intents to act up on them, even though they don’t map on to any of the specific App ‘Schemes’ and ‘Domains’ that are listed. If I'm using just App Entities and Intents on their own, would these participate with the new Siri AI, without any additional work? For example, in my app, I have entities like Contacts, Tags, and ‘Visit Logs’. I have intents for 'create tag’, ‘add tags to a contact’, add a ‘Log’ to a 'contact' etc. These are specified in the AppShortcutsProvider list, but I have more than 10 intents. How would these work with the new Apple Intelligence and Siri? Or does Siri integration require AppSchema adoption?

When importing FoundationModels in watchOS 27 Beta 2 this error appears: /Applications/Xcode-beta.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS27.0.sdk/System/Library/Frameworks/FoundationModels.framework/Modules/FoundationModels.swiftmodule/arm64e-apple-watchos.swiftinterface:6:15 Unable to resolve module dependency: 'CoreImage' Does anybody else have this issue?

I’ve been experimenting with Foundation Models and built a small Swift package that wraps LanguageModelSession with simple context management. The current approach checks the transcript token count using tokenCount(for:), compacts the transcript when it reaches a threshold, and retries once if exceededContextWindowSize is thrown. I’d appreciate feedback on whether this is a sensible use of Foundation Models APIs, especially around rebuilding a session from a compacted Transcript. GitHub: https://github.com/ricky-stone/FoundationContext

Unless I'm missing something, it seems like the quota usage information for the Private Cloud Compute model is too limited. You can tell if you've reached your quota or are below it. If you are below your quota, you can tell if you're approaching the limit, but what does this actually mean? Am I over 50%, 90%, 99%? It would be nice to have actual numbers in the quota. For example, I can see my token usage for a session. If an app could keep track of that versus the quota, you could come up with something way more useful for the user. Example: You have 100,000 tokens per month, this app has made 4 requests, that used a total of 5,000 tokens. If the user has used on 95,000 tokens of their quota so far, they know they can maybe make ~4 more requests from the app before the limit is reached, so they know to be careful with their usage. If they've only used 10,000 tokens of their quota so far, they know that have some breathing room and can use the feature more freely. The way the current system is designed, you have no idea at all. Adding real numbers (even percentages – if we can get usage percentages for the app as well), would really help in giving useful feedback to the user on their usage of PCC. Right now, everything is too vague.

I had a great run in the first decade of iOS development. Not so much since. I had 180k downloaded units in the last year - but I'm excluded from foundation models because I did well before 2015. That seems like an odd policy. Apart from anything else - it explicitly punishes long-term accounts... Lifetime downloads...

I’m going on 2 1/2 days waiting on the indexing and still on the wait list is there something I am missing or should I just wait it out

Hello, I have an AppEntity with an EntityQuery that conforms to EnumerableEntityQuery by providing an allEntities() method. This creates a default "Find" action in the Shortcuts app for that entity, including automatic filtering on primitive properties such as dates and numbers. The entity has an AppEnum property. However, the "Find" action returns zero results when filtering by that property – even though the enum value is correctly displayed when using the "View" action on the same entity. Conforming to EntityPropertyQuery and manually defining comparators does fix the enum filtering, but it replaces all of the system-generated filtering, requiring me to reimplement comparators for every property I want to remain filterable. Is this the intended behavior, or is automatic filtering on AppEnum properties something that should be supported out of the box? Sincerely, Holger

I found a UI/error-handling issue involving Siri AI where a raw/internal-looking error code is shown directly to the user instead of a user-friendly message. Environment: Device: iPad Pro 11-inch (M4) iOS/iPadOS version: 27.0 Siri / Apple Intelligence enabled: Yes App involved: Files & PDF Expert UI/context: Siri AI interaction with a document from Files File type: .doc Observed behavior: I asked Siri AI to create a new note inside a document through the app integration. Instead of completing the request or showing a user-friendly failure message, iOS displayed this raw error notification: “From PDF Expert: The operation couldn’t be completed. (TypedValueToContentGraphResolutionErrorDomain error 4.)” Expected behavior: Siri AI should handle this failure gracefully and explain that it could not create a new note in the document, instead of exposing the raw error domain and error code to the user. Screenshot:

My phone no longer shows the waitlist for Siri and has the option to "Try New Siri." I select it, continue, continue and the settings change to "Siri (Beta)" and the waitlist option is no longer there, but when using Siri it's the old pre-Apple Intelligence Siri that activates (little bubble at the bottom) and it does not work. Going to Safari and typing "Siri://" opens the New Siri App, but it says "Siri Update in Progress; Adding support for Siri hasn't completed. Open Settings to check the status." The app does not show up in Spotlight. My phone is done Indexing and all signs point to my phone being enrolled to use the New Siri, but it isn't working at all and still has not shown up. I've tried restarting a few times. Anyone experiencing this too?

I conform to @AppEntity(schema: .photos.album). I'm curious if I can steer how Siri thinks of these entities when the user speaks about them. While my app contains groups of images, they are not presented to the user as "albums". In fact "albums" from PhotoKit are used when creating these galleries. This distinction is important. The user is most likely to say "I want to open a gallery in " rather than "I want to open an album in " Is it possible to steer Siri into thinking of these AppEntities as galleries rather than albums? Similar to how IndexedEntity contains a CSSearchableItemAttributeSet ?

In visionOS 2, the system search displays the icon of each App Entity registered. It used to work up to visionOS 26 beta 7. But since visionOS 26 beta 8, visionOS 26.x , and still in the current visionOS 27 Beta 2 the system search no longer display the right icon. Instead it displays the icon of an AppShortcut declared by the source code which uses the AppEntities. This does not help the users to find the right AppEntity in a search with multiple results as they all have the same AppShortcut icon. This "bug" also make the search result differ from the experience with iOS and iPadOS which display each AppEntity icon. You can use the Apple sample to see this bug on visionOS 27 Beta 2 and 26. Accelerating app interactions with App Intents AppEntities are an important part of Apple Intelligence, the system integration is really important for a great user experience. FB19915478

I have an app on the App Store that takes user content and creates a Generable struct out of it. In the last couple weeks I have started getting complains from my users that the part of the app leveraging FoundationModels isn't working properly. In my testing I noticed that the same request that would've worked a couple weeks ago is now getting errors with guardrails violation. I'm initializing my model this way LanguageModelSession(model: SystemLanguageModel(guardrails: .permissiveContentTransformations)) // I'm aware that .permissiveContentTransformations does not apply to Generable, but I'd really really really really love it, if it did!. This started around the iOS 26.5/macOS 26.5 releases and I wonder if there's a way to fix it.

I wonder how to apply multiple schemas to the same entity. Just to give an example: Let's say we have a typical shoebox application for note taking. Notes can be organized in hierarchical folders. For notes the note entity schema makes obviously sense. And for folders we need to apply the schema notes.folder, so this entity type can be used with the createNode and updateNote intent schemas. But, it would also make sense to use the file schema for folder entities, as it allows me to use the createFolder intent schema or deleteFile. Unfortunately, I can only apply one schema to one entity. So I can't declare a folder as note.folder and file.file simultaneously. I thought about using multiple entity types for the same entity to have somewhat multiple representations, but I can only assign a single app entity identifier to a view.

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?

Dears, I have reached out to Apple Research and Apple Security but this is NOT really for them. This is a developer topic !! Apple Research and Security are trying to find a malicious code, bugs ect, but what I am whitnessing is different and much much deeper into the code. Apple Intelligence in Slovakia is much more limited then in other countries. A specific security configuration due to EU regulations in combination with Siri NOT able to speak or understand Slovak. At low level this combination with a small PUSH with good timing, makes the devices to completely strip themselves off, of all security and trust certifications. What follows is a blank completely from scratch processed reinstall, where the attacker only prepares the "CORRECT" files and information and all the work is done by Apple system itself !!! The result is a complete domination of hardware using the NPU (ANE) chip, which does all the job. And I mean each pixel, sound, connection ect... What is the MOST ALARMING is that due to the proud declaration of customer data privacy this is the exact spot where if something like this happens, Apple will NOT be able to see it. The Customer is then in an extreme situation, where he knows that the devices, accounts, keychain, bank account, each app, each picture or sound.... Everything is compromised, but online help and the retailers are too short for this and further to this Apple DONT HAVE AN OFFICE in Slovakia. Only thing left are the contracted service (repair) shops, which are capable to perform a DFU Restore, which does NOT help. I have requested DFU Restore approx 15x in the last 9 months. Once you turn on and you only pick the language, there is a GLITCH and you know this is back again. A very quick and not too detailed process: It is a very silent and extremely sophisticated takeover without an ovious crash at the beginning. Using various tools, which I can describe and present examples. One variation is a HTML code a DOM which is recursive, calling functions and cancelling. Too many functions with offset which results in a graphics freeze, overload or similiar.. The object itself is not frozen and it is carefully prepared !! It will mostly copy and clone the target and NEST inside without knowing. What happens here is that this recursive DOM was applied and therefore the SHUTDOWN MONITOR LOG occured. This froze also mds index which blocked the mounting and unmounting of Volumes.... This is ofcourse carefully instrumented not to raise any attention. Same structure can be used in any code, any language, pdf, it can be nested in a wallpaper or a standard image, library, anywhere ... I can provide a proof and a functional script... The install log is showing - Untracked client connected - RemoteManagement which REINSTALLED the OS. After that Launchd skipps almost all tasks on the next run .... After this mounting volumes block, the system will not restart as standard, insted forced to early boot as possible which starts with PKI TRUST and SIRI UNDERSTANDING ... The PKI TRUST is manipulated and prepared and Siri is not called by the system as Apple Inteligence. So with reinstalled and carefully prepared OS, Launchd who skipped most tasks at the start and without proper encryption. There is a direct open path to Siri and her ASR HAMMERING.... I have personally checked almost 10 different electronics shops and checked the console on each Macbook that was free to try. In each of them these four Protolol logs were the exact same !!!! But after that a brutal iphone reinstall and even over lockdown mode reinstall will follow... Can also provide logs and information... And there is a SIMPLE LOGIC PARADOX with HUGE impact. Any document can be signed by Apple in a second. That is how the PKI TRUST was manipulated without any problem. That is also extremely important ... I can present this, but I must know that somebody is listening.... otherwise the only way is press... Apple Research and Security is blind here and I simply cannot get any answer.... If you know anybody in Slovakia, tell them to go to check this out !!! Get this information to Somebody who could just check it please .... This is probably the largest Supply Chain Attack ever ... And all it takes is a phone call to iStores to Slovakia so they can check for you ... From what I can see, now an update is prepared for Siri. It is based on Ruby but mostly Nokogiri and Gumbo. It will be presented as a 8 bit range training for local LLM, as super fast, but really it will be a combination of Hohner Electric Piano from the 70s with 8 bit sound which will use DTrace and its ROOT privileges. The sound is a square frequency which can be used to hide communication or something we dont know yet. And it does not matter anymore... With a direct connection to GitHub or just the internet ... Any code can be signed and stored anywhere .... The codename is ELECTRA, from what I know this tag was used for jailbreak of Siri in the past. So I belive this will be the final act ... Is there somebody to whom I can speak to about this ?? No generic mails ... THX Mike

Hey, Running iOS 27 beta and have App Intents working in the shortcuts app. When I ask the exact query via Siri it seems to say it can't do that and asks me to open the app to do it manually. Is this expected behaviour? A bug? Anything I need to double check? The app doesn't map to a schema directly.