still no sign of the new siri no app no nothing im on the ios 27 beta 2 and iphone 15 pro max what is this apple

I am currently on Apple's Dev Beta V4 for iOS 27. The first version I installed was the Dev Beta V2, I am desperate to try out the new Siri AI Beta, but it's just not installing for me. I have the ability to "turn siri off" then "on again" and find I get the 2024 Apple Intelligence version fine. But if I choose to try out the new AI Beta, I'm left with "Adding support for Siri is in progress. Siri will be unavailable until the update is complete." It's been in that state for over 48 hours in Beta 4 and I'm left with the OLD OLD Siri globe from pre-Apple intelligence. Am I being too keen and just not leaving it long enough? Or is there a genuine issue at Apple's end, in regard to getting the new Siri to actually fully install?

So I'm having an issue with the FoundationModels framework but idk if this is just my feeling or not, the issue comes up after I updated my Mac into 26.6 the code was very simple actually: #Playground { let model = SystemLanguageModel.default let session = LanguageModelSession(model: model) print(model.availability) var query = "How to hide button" Task { do { let response = try await session.respond(to: query) print(response.content) } catch { print("\(error)") } } } the code works before I updated the version, but then after I updated the version it says: Error Domain=FoundationModels.LanguageModelSession.GenerationError Code=-1 "The operation couldn’t be completed. (FoundationModels.LanguageModelError error -1.)" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=FoundationModels.LanguageModelError Code=-1 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=(\n "Error Domain=ModelManagerServices.ModelManagerError Code=1026 \"(null)\" UserInfo={NSMultipleUnderlyingErrorsKey=(\n)}"\n)}" ), NSLocalizedDescription=The operation couldn’t be completed. (FoundationModels.LanguageModelError error -1.)} this is runned in Xcode 26.6, additional information I have also coder 27 beta 4 installed in my Mac, is this problem occurring because the Xcode 26.6 and Xcode 27 beta 4?? can u guys help me

Hi guys, I'm testing the Foundation Models Framework with the on-device model in iOS 27 (beta 4) and macOS 27 (beta 4) and is completely failing to respond. There are many errors. For starters, the model doesn't respond to prompts directly, you need to specify instructions, otherwise it refuses to provide an answer. It is always looking for tools, even when no tool has been provided, and returns an error saying that it couldn't find the tool. Then, when it produces a response, it shows all the thinking process first, which completely ruins the response. Most of the time, the response begins with all the JSON code. And when I try to have a long conversation, it just says "I cannot write content or generate text." I wonder if someone is experiencing the same issues or maybe the way to implement this model changed and I'm missing something? Here is a screenshot of one of my interactions when I asked the model to describe a unicorn. It tried to access a tool that doesn't exist. (the app just prints the value of the content property) Here is the code. It is performing a simple request. struct ContentView: View { @State private var response = "" var body: some View { VStack { Button("Send") { let prompt = "Write a paragraph describing a unicorn" let session = LanguageModelSession { "Respond to the user's request. Never acknowledge the request, add preamble, or comment on what you are about to write." } if !session.isResponding { Task { do { let answer = try await session.respond(to: prompt) response = answer.content } catch { response = "Error accessing the model: \(error)" } } } } .buttonStyle(.borderedProminent) Text(response) .font(Font.system(size: 18)) .padding() Spacer() } .padding() } }

On macOS Golden Gate Developer Beta 4 the following code: import CoreSpotlight import FoundationModels let tool = SpotlightSearchTool() let session = LanguageModelSession(tools: [tool]) let response = try await session.respond(to: "What hikes have I gone on?") , returns the following error: Model Catalog error: Error Domain=com.apple.UnifiedAssetFramework Code=5000 "There are no underlying assets (neither atomic instance nor asset roots) for consistency token for asset set com.apple.modelcatalog" UserInfo={NSLocalizedFailureReason=There are no underlying assets (neither atomic instance nor asset roots) for consistency token for asset set com.apple.modelcatalog} , although the model is available in general and can return responses without using the tool. The code: print(SystemLanguageModel.default.availability) returns 'available'. What am I doing wrong?

We recently had to change our MLModel's architecture to include custom layers, which means the model can't run on the Neural Engine anymore. After the change, we observed a lot of crashes being reported on A13 devices. It turns out that the memory consumption when running the prediction with the new model on the GPU is much higher than before, when it was running on the Neural Engine. Before, the peak memory load was ~350 MB, now it spikes over 2 GB, leading to a crash most of the time. This only seems to happen on the A13. When forcing the model to only run on the CPU, the memory consumption is still high, but the same as running the old model on the CPU (~750 MB peak). All tested on iOS 16.1.2. We profiled the process in Instruments and found that there are a lot of memory buffers allocated by Core ML that are not freed after the prediction. The allocation stack trace for those buffers is the following: We ran the same model on a different device and found the same buffers in Instruments, but there they are only 4 KB in size. It seems, Core ML is somehow massively over-allocating memory when run on the A13 GPU. So far we limit the model to only run on CPU for those devices, but this is far from ideal. Is there any other model setting or workaround that we can use to avoid this issue?

We're implementing the App Intents Phone schema domain in our app to enable Siri to initiate calls to our contact entities via our voip. We've implemented a .phone.startCall intent and registered our entities as .phone.phonePerson. The intent provides both the required destination and audioVisualMode parameters, and the perform() method is implemented to handle the call. However, the perform() method is never invoked. Instead, Siri either: Says that the phone number is not linked, or Announces that it is calling, but our app intent is never executed. Anybody implemented this Phone schema domain and it s working successfully ? Sample Code: struct StartCallIntent: AudioRecordingIntent, AudioPlaybackIntent { var destination: CallDestination var audioVisualMode: CallAVMode init(contact: ContactEntity, mode: CallAVMode = .audio) { self.destination = .phonePerson(contact) self.audioVisualMode = mode } func perform() async throws -> some IntentResult { print("Call Initiating to contact") return .result() } @AppEnum(schema: .phone.audioVisualMode) enum CallAVMode: String, CaseIterable { case audio case video } @UnionValue enum CallDestination: Sendable { case phonePerson(ContactEntity) case group([ContactEntity]) } @AppEntity(schema: .phone.phonePerson) struct ContactEntity: IndexedEntity { static var defaultQuery = ContactEntityQuery() let id: UUID var person: IntentPerson }

While building with Apple's Foundation Models, I kept running into a workflow problem before the app code itself. The hard part was not only calling LanguageModelSession. It was figuring out the shape of the interaction: What should be in the system prompt? What should stay in the user input? What output is actually usable by the app? How much instruction is too much? How do I test the same prompt repeatedly without creating another small Xcode project? I ended up building a small macOS tool for myself, LocalLM Lab, mainly to speed up that loop. The first use case was a Prompt Playground: system prompt, user input, model output, and a repeatable way to compare results before moving the workflow into app code. The current version also experiments with connector-style context, such as system clock, weather, reminders/calendar, contacts, and a scoped filesystem folder. That has made the prompt design problem more interesting, because the question becomes: what context should the model see, and how should the app frame that context so the output is useful? I am curious how other developers are handling this while building with Foundation Models. Are you mostly iterating inside Xcode playgrounds? Are you building small internal test harnesses? Are you separating system prompts and user inputs during testing? How are you evaluating whether the output is reliable enough for the app workflow? For reference, this is the tool I have been using for my own experiments: https://thisbrain.ai/locallm I would be especially interested in any patterns people have found for designing and testing prompts before committing them to app code.

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?

Can anyone please tell if a M5 Pro Macbook Pro can connect to a M3 ultra Mac studio over thunderbolt 5 using RDMA for LLM inference? Thanks

Hi everyone, I’m testing the latest iOS 27 beta and I’ve noticed an issue with the new Siri. When I ask very simple questions that should be handled locally or through basic reasoning, Siri consistently responds with: “Uh oh, something went wrong.” For example, asking: “When is the next Friday the 13th?” results in the error message instead of an answer. I’ve reproduced this multiple times and it seems to happen with other straightforward informational queries as well. I’ve already tried restarting the device and checking my network connection, but the issue persists. Has anyone else experienced this behavior with the new Siri in the iOS 27 beta? If so, were you able to find a workaround or identify what’s causing it? Any help or confirmation would be greatly appreciated. Thanks!

We have an app that supports iOS 18+ We have a couple of AppEntity(s) that we are keen to make work with the new schemas along with several AppIntent(s). We cannot increase our floor to iOS 27 for obvious reasons. All the documentation suggests using the macros, e.g. @AppEntity(schema: .audio.song) struct SongEntity { ... } This refuses to compile below iOS 26. It's possible to add availability checks, e.g. @available(anyAppleOS 27, *) @AppEntity(schema: .audio.song) struct SongEntity { ... } But then the whole entity becomes unavailable on pre-27 OSes. So I tried moving the macro onto an extension, e.g. struct SongEntity { ... } @available(anyAppleOS 27, *) @AppEntity(schema: .audio.song) extension SongEntity { ... } But this results in a compiler error: 'extension' macro cannot be attached to extension (extension of 'SongEntity') One other option is to create a new entity with a totally different name and mark it as isAssistantOnly but this has a lot of quite negative downstream effects that make it unworkable. For example: a lot of code duplication duplication in search indexes if we index both sets of entities awkwardness trying to use NSUserActivity when we have 2 different entity types pain in downstream AppIntent arguments which would require duplicating every AppIntent which has more cascading effects The same issues are present in AppIntent schemas too where even trying to add the most basic @AppIntent(schema: .system.open) to our existing OpenIntent doesn't seem possible for all the same reasons. I am really struggling with how to structure code so we can support schemas, currently I don't really see a path forward here until our floor raises to iOS 27. Is there a way to make this work nicely with the current APIs? What are others doing here? How can apps can ship in September and support both this and pre iOS 27 cleanly? Thinking about solutions here, my ideal would be that the macros are improved to either: be able to be applied to an extension rather than the structure itself. expand in such a way that they still build the core AppEntity / AppIntent on pre 27 OSes but then add the iOS 27 schema additions behind @available internally so they can be used with older targets as essentially no-ops on the current definitions.

I’m seeing a major change in reported memory usage (and eventual termination due to memory pressure) when running a Core ML workload built with Xcode 27 on iOS/iPadOS 27. The source code, model files, and MLModelConfiguration are unchanged. Only the Xcode/SDK version used to build the app differs. On the same iPad running iPadOS 27: Xcode 26 build: model loading and prediction complete normally, with a relatively small reported application footprint. Xcode 27 build: the application footprint grows continuously as models are loaded and can exceed 5 GB. The app is eventually terminated unless models are unloaded very aggressively or the increased-memory-limit entitlement is used. I also tested an Xcode 27 build on a device running iOS 26. Its reported peak was only around 300 MB. This suggests the change requires both an Xcode 27-linked binary and the iOS 27 runtime. The workload consists of several compiled Core ML models using .cpuAndNeuralEngine. Loading models sequentially instead of concurrently does not materially change the final footprint. Releasing each MLModel after use does reduce it, so this appears to be model or Neural Engine residency being charged to the application rather than a conventional heap leak. I noticed that the iOS 27 release notes mention Neural Engine memory now being attributed to the application instead of the system. However, I’m unclear about the practical consequences of that change. If the same Neural Engine resources were already physically resident on iOS 26, I would have expected them to contribute to system memory pressure even when they were not attributed directly to the application. Instead, the older configuration runs comfortably, while the Xcode 27/iOS 27 combination approaches or crosses the application’s per-process memory limit. A few additional observations: The problem is more likely to occur after Core ML has already compiled and specialized the models. Cached model loading is much faster and the footprint grows quickly. The first uncached run can survive model preparation because specialization spaces the loads farther apart. Under Instruments, the app often does not terminate, presumably because profiling slows the workload enough to change the peak. os_proc_available_memory() decreases in line with the newly reported footprint. With the increased-memory-limit entitlement, the workload completes, but the reported footprint still reaches several gigabytes. Has anyone else observed a large Core ML memory increase specifically with an Xcode 27 build running on iOS 27? In particular, I’m trying to understand: Is this purely a change in how existing Neural Engine memory is accounted for, or does the new runtime also retain or allocate more memory? Is the new accounting used for the application’s jetsam/per-process memory limit? Is this behavior intentionally gated by the linked SDK version? That would explain why an Xcode 26 build behaves differently on the same iOS 27 device. Should applications now treat the Neural Engine residency of every loaded MLModel as part of their process-memory budget and unload models accordingly? Are there recommended APIs or Core ML loading strategies for controlling this residency? Any confirmation that others are seeing the same Xcode 27/iOS 27 behavior—or clarification of the intended memory-accounting model—would be very helpful.

We have a list app that implements INAddTasksIntent so users can add items to our app with Siri. We're now working on implementing an App Intent for the .reminders.createReminder schema for iOS 27. Our app still supports iOS 18, so it implements both INAddTasksIntent and the .reminders.createReminder schema. Observed behavior (iOS 27 beta 4): When we say "Siri, add eggs to my grocery list in AppName", Siri routes the request to the legacy INAddTasksIntent handler in our SiriKit extension. Our new CreateReminderIntent is never invoked. I confirmed this with breakpoints and logging in both handlers. The CreateReminderIntent does seem to be set up correctly, because it appears in the Shortcuts app and I can invoke it via AppIntentsTesting. Also, after using the above phrase, I was able to say "Siri, add cookies to my grocery list" and the item got added to my app via the INAddTasksIntent, even though I didn't specify the app name in the request. This also worked with a version of our app that does not contain CreateReminderIntent running on iOS 26.5. Isn't the app name normally required for INAddTasksIntent to be invoked? Questions: Is Siri activating the INAddTasksIntent instead of the new CreateReminderIntent expected behavior? Are users on iOS 27 going to have a worse experience adding items to our app with Siri if we support both INAddTasksIntent and the new CreateReminderIntent? If so, how do you recommend we proceed? Thank you for any guidance you can provide.

I wanted to activate the new Siri AI on my iPhone 12 running iOS 27 Developer Beta 4. I knew it didn't support Apple Intelligence features, but I switched the language to English anyway—and then I ran into this bug: I went into the Siri tab and saw this.

I wanted to activate the new Siri AI on my iPhone 12 running iOS 27 Developer Beta 4. I knew it didn't support Apple Intelligence features, but I switched the language to English anyway—and then I ran into this bug: I went into the Siri tab and saw this.

As a user from Bulgaria, I would also like to suggest a possible approach that could benefit both Apple and users in the European Union. Even if the new AI-powered Siri becomes available in the EU in the future, it is unlikely to support every European language immediately. For example, Siri AI does not currently support Bulgarian, which means many users like me would still be unable to use its full capabilities in our native language. Because of this, I believe users should have the option to choose their preferred AI assistant as the system assistant—for example Siri, ChatGPT, Gemini, or another approved assistant. From my perspective, this could also align well with the goals of the Digital Markets Act (DMA). If Siri in the EU is required to have the same level of system access and permissions as third-party assistants, then all assistants would operate under the same rules, with the same privacy protections and the same limitations regarding access to system resources. This would create a level playing field while still allowing users to decide which assistant best meets their needs. For users like me, this would be especially valuable because I could choose an assistant that supports Bulgarian, while still enjoying the privacy and security standards that Apple is known for. I understand that this is only one possible approach, and there may be technical or regulatory challenges that I am not aware of. Nevertheless, I believe giving users more choice could be beneficial for both Apple and its customers across the European Union. I would be interested in hearing what other developers and Apple engineers think about this idea.

Gerstart Apple inteligente

I have a Core AI model export — a bundle folder (.llmasset, containing multiple .aimodel subfolders plus metadata/tokenizer resources) — added to my app target as a folder reference. Rather than treating the bundle as one opaque resource and copying it into the app bundle as-is (the way .xcassets, .bundle, or any other folder reference behaves), Xcode reaches into it, finds the individual .aimodel subfolders, and adds each one to Compile Sources. When it compiles them there, it's for my build machine's specific chip only — I can't find any setting (Build Settings, scheme, target picker) to compile for multiple architectures/platforms, the way a universal binary would work. Question: Is there a way to make Xcode treat a .llmasset bundle as an atomic resource — copied wholesale, not decomposed into individual .aimodel compile targets? Or is reaching into the bundle and AOT-compiling its components for the active build architecture the intended behavior here, and if so, what's the recommended way to make sure the result works across the actual range of devices the app ships to?

Dear Apple Support, I would like to report a long-standing issue affecting Khmer text recognition in Live Text (Vision Framework/OCR). Based on my testing, this issue has persisted for more than two years, from iOS 17 through iOS 27 Beta 3, and is also reproducible on iPadOS and macOS. I would appreciate clarification on the following questions: Is Apple aware of an issue where Live Text (OCR/Text Recognition) incorrectly recognizes Khmer script as Thai script, causing copied text to become Thai characters instead of Khmer? Has this issue been officially logged as a bug within the Vision Framework or Live Text team? Since this behavior has remained reproducible from iOS 17 to iOS 27 Beta 3, why has it not yet been resolved? Is the problem caused by: automatic language detection, the OCR recognition model, the Vision Framework, or another component of Apple's AI pipeline? Does Apple currently have a dedicated OCR and language recognition model for the Khmer script, or is Khmer being inferred through another language model? Is there an estimated timeline for improving Khmer OCR and preventing Khmer text from being misidentified as Thai? Can Apple confirm whether this issue affects all products using Vision Framework, including: Live Text Photos Preview Screenshot OCR APIs provided to third-party developers? How can Apple work with the Khmer technology community to improve OCR accuracy and language support for Khmer? This issue is more than a simple OCR bug. When Khmer text is automatically converted into Thai characters, users lose access to the original text, developers receive incorrect OCR output, and it negatively impacts the digital representation of the Khmer language. For reference, I have documented the issue in detail here: https://app.notion.com/p/Inaccurate-OCR-Language-Inference-Khmer-Script-Misidentified-as-Thai-in-Vision-Framework-2d8a24f4ee6680fcbc49d989f8bb606f I hope Apple can investigate this issue and prioritize improving Khmer language support across Vision Framework and Live Text. Thank you.