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.

There seems to be a lack of clarity about how this Siri AI rollout is working. Does the indexing have anything to do with getting taken off the waitlist, or are they completely separate? Also, what is the expected wait time and has anyone gotten the new Siri after the initial wave of approvals (after 4 hours after the keynote)? The waitlist is extremely slow compared to the initial Apple Intelligence waitlist from a couple of years ago.

Its been 3 days since i had requested for Siri AI , still in the waitlist. This is disappointing .

I downloaded the beta iOS 27 and I’m still on the waitlist, as are a whole bunch of other people. Is there like a bug of people not getting past the new Siri waitlist?

I finally installed iPadOS 27 developer beta 1 on my iPad Air (M2), opened Settings app and went to the Siri section. There’s no option to join a waitlist. I had Apple Intelligence enabled on iPadOS 26, but in 27, the “Apple Intelligence & Siri” section simply reads “Siri” now. No mention of Apple Intelligence at all! Has anyone else encountered this? Is it a regional thing? I’m in Canada. EDIT: Ok it was a region thing. I changed my region to US and the waitlist option appeared.

Share your experiences and any problems with Siri AI (iOS27 BETA) in detail. Describe which functions you particularly noticed, which difficulties you had, and in which situations Siri AI helped or disappointed you. Your detailed reports help us to talk about it in a targeted manner and find solutions or tips together.

I just watched the "Build Intelligent Siri experiences with App Schemas" and I'm confused about how to integrate my app with the new Apple Intelligence + Siri in iOS27. I think it mentions specifically that Siri needs to adopt App Schemas, and that just adopting App Intents in my app isn't enough for it to integrate with the new Siri. Is that correct? The 'schemas' seem to be a narrow set of specific activities. What if my app's actions (or intents) don't match closely with it? For example, in my app, I have entities like Tags and Contacts. I can 'create tag' as well as 'add tags to a contact' as 2 different App intents. If I'm using just App Intents on their own, would these not map to the new Siri? I can also add a 'task' to a 'contact'. Would that possibly work with Siri? The videos just don't seem to make an effort to explain what is and what isn't possible.

Okay, so i’ve been on the waitlist since Monday, roughly about 107 hours, and still nothing, i have iPhone 16 pro, and what’s frustrating some people got it like after 2-3 hours, maximum 3 days, but now its getting really frustrating , hope today i will get it!

Hello, the only way to make Siri AI pick up my intent, or action on my intent + entity is that if BOTH use an schema? For example, I have an intent that adopts a schema, but my entity doesn't. That means Siri AI can't do anything with my intent? What if neither use a schema? Siri AI can't do anything with it? I'm asking because schema seems limited to only few domains which I'm not sure how I'll integrate with my apps.

I'm trying to associate a Core Spotlight item with an AppEntity during indexing by calling CSSearchableItemAttributeSet.associateAppEntity(_:priority:). However, every time I do so, I get the following warning in the console: {CSInlineDonation[async]: "my.app.bundle.identifier" add-update-items:1 delete-items:0}: Failed to request donation Error Domain=CSIndexErrorDomain Code=-1000 "Failed to request donation" UserInfo={NSDebugDescription=Failed to request donation, NSUnderlyingError=0x143f54ae0 {Error Domain=com.apple.CascadeSets.Set Code=3 "Access denied (<BMResource: set/App.Intents.IndexedEntity [CCSetDescriptor - key: sourceIdentifier value: my.app.bundle.identifier]>)" UserInfo={NSLocalizedDescription=Access denied (<BMResource: set/App.Intents.IndexedEntity [CCSetDescriptor - key: sourceIdentifier value: my.app.bundle.identifier]>), NSUnderlyingError=0x143f54ba0 {Error Domain=BMAccessErrorDomain Code=11 "Failed to prepare resource" UserInfo={NSLocalizedDescription=Failed to prepare resource}}}}} The relevant code is: let attributeSet = CSSearchableItemAttributeSet(contentType: .audiovisualContent) let appEntity = VideoAppEntity(...) attributeSet.associateAppEntity(appEntity) The Spotlight item itself is indexed successfully, but the associateAppEntity call appears to fail with an "Access denied" error related to App.Intents.IndexedEntity. Has anyone encountered this before? Are there additional entitlements, App Intents configuration requirements, or indexing prerequisites needed for associateAppEntity(_:priority:) to work correctly?

iOS 27.0 beta 24A5355q has a completely unacceptable Settings crash that blocks Wi-Fi Calling activation and E911 emergency address setup. This is not some tiny visual bug. This breaks actual phone service. I cannot activate Wi-Fi Calling, I cannot register my 911 emergency address, and my SIM line is effectively unusable because Apple shipped a broken beta Settings app. Process: Preferences / com.apple.Preferences Device: iPhone16,1 Crash type: NSInvalidArgumentException Reason: -[UIThreadSafeNode _smartReplyUpdateInProgress]: unrecognized selector sent to instance The stack points to Apple’s own code: UIPredictionViewController UIKeyboardImpl TextInputUI UIKeyboardLayoutJapanese50OnFlick I tried Bluetooth keyboard, disabling prediction, removing keyboards, rebooting, and avoiding text input. Nothing works. The Wi-Fi Calling / Emergency Address page crashes on load. This is a stupid, critical Apple bug. Settings should never crash when opening a carrier service page, and it is insane that a broken prediction UI can block emergency-address registration and phone service activation. Please fix this immediately, or provide a way to configure Wi-Fi Calling E911 address without loading the broken TextInputUI / prediction UI path.

Does this API only work for inference running on the GPU? If the inference runs on the ANE, can I still use this API? I noticed that the commandQueue parameter is an MTLCommandqueue? https://developer.apple.com/documentation/coreai/computestream/init(commandqueue:)

What should we know about testing the new Siri and beta software on iPad vs iPhone if we do not have a space 17 PRO device for beta software testing? And can the new Siri AI be activated on an iPad? Any requirements? Any other testing options? Thank you.

I have been waiting for the siri ai and doing everything to try to get it, yet I have been stuck on the waitlist since iOS 27 developer beta released, so please help me out🙏

Hi everyone, I joined the new Siri waitlist on Friday at 7:00 PM IST using a new M4 MacBook running the latest macOS 27 Developer Beta (Build 26A5353q). It has now been over 100 total hours (roughly 52 business hours) and my status is still stuck on "Joined Waitlist." My setup is completely clean: System Language and Siri Language are both set to English (US).My storage shows the 27.69 GB Apple Intelligence bundle is already pre-allocated on my SSD. My physical device region is set to India (outside the EU/China geofence). Unified system logs show isOkayToHaveAsset: True and AvailabilityClient.waitlistStatus connections are establishing perfectly with 0% CPU idle on generativeexperiencesd. I have tried clearing the local cache by toggling Siri off/on and performing a full language-flip reboot cycle, but it drops straight back to "Joined Waitlist" without letting me click the join button again (proving the server recognizes my original Friday timestamp). Is anyone else experiencing a massive weekend-backlog server stall on this specific macOS 27 build? How long did your approval take this week?

I have been waiting since last tuesday for the new siri. My primary device, which is my phone is missing and it is out of battery in my home. I don't know where did my phone go. Still, is it possible to get the new siri? I am waiting on my iPad Pro(M1) 2021 model. Also is it my problem that it is taking so long?