iOS26系统使用系统键盘录音转文字会造成整个音频模块不能用，其他的app播放视频没有声音。复现概率非常高，请问有解决的办法么？

Hello, After a recent iOS update, I was going through my settings to set restrictions on apps installed on my device, and I noticed this option on each app's page: Learn from this App: "Allow Siri to learn from how you use [App Name] to make suggestions across apps." I turned it off right away, but it left me with several questions. In 2026, Siri has received major updates, including new AI features, and it now communicates with me much more often. Before I decide whether to turn this setting back on, I'd like to understand: What data does Siri collect from each app? For example, does it look at which apps I open and when, what I do inside them, or the content I view? How is that data used to improve suggestions? What does Siri actually do with what it learns? Where is this data processed and stored? Does it stay on my device, or is it sent to Apple's servers or synced through iCloud? How is my personal information protected? Is it linked to my Apple Account, and is it shared with app developers or third parties? How is the content I watch or read used across apps? Could something I view in one app affect suggestions in another app? Can I see or delete what Siri has already learned? If so, how? I know Apple takes privacy and security seriously, so I'm not too worried. But this is one of those features Apple didn't really talk about on stage, so I'd appreciate a clearer explanation of how it works. Thanks!

I have been trying to create snippet views for my AppShortcuts which fill the full width of the container. Doing this via either .frame(minWidth: 0, maxWidth. infinity) or .containerRelativeFrame() work perfectly fine when my snippet is presented from Shortcuts.app (though sometimes the wrong color scheme is displayed), but when I invoke my AppShortcut from Siri AI and it presents the snippet there, it's offset on the trailing side by sometimes up to over 30 points, which has frustrating effects on the UI I am trying to implement. I've noted the insets are different too depending on whether the snippet is presented from what AppIntents method invokes it requestConfirmation or .result respectively. Here's some screenshots showing the issue. All these use the exact same snippet view, but all have different results in how they look and are inset. In App (how I want it to look) In Shortcuts (fine I guess) And finally, in the Siri app. I have reproduced this is issue and distilled it in a sample project. Please ensure this routes to the correct team: FB25164368. Thanks!

I have created a Personal Voice and have selected it in my AI app. It sounds awful. Why? Can I continue to train it until its sounds more like me? Why not? When should I expect a Personal Voice Upgrade.

Policy or no policy I think its clear if Apple wants to have a premium SiriAI experience its gonna need to allow apps to use the Siri AI Voice engine Developers like me want the privacy/no cloud voice engine service that a SiriAI Voice would provide Seemless conversations with versions of SiriAI Voices let's users know they're still in the SiriAI ecosystem but engaged with a developer app The "hey Siri, ask LinkedIN Hoffman to .." is stunningly haphazard moat gate that Apple can resolve and still keep control with a simple App License so it know every app that uses a SiriAI Voice App engine. I've been waiting over a year for Apple to figure this out. This is an unforced error. This is not a threat its an opportunity for Apple ? Is this a Driver or CoreOS issue? WTF?

I need a supported way for Dutch Siri to invoke Elegant Cook's built-in grocery actions directly, without requiring users to create personal shortcuts. The installed TestFlight version is 1.5.3 (32), on an iPad Air (5th generation). The owner reports iPadOS 26.6.1; the diagnostic archive identifies build 23G83. Siri is Dutch, with nl_BE runtime assets. Use with Siri is enabled and spoken responses are preferred. The main app uses App Intents and AppShortcutsProvider with three actions: add a grocery, read the list, and check off a grocery. The voice actions use scalar String parameters with requestValueDialog and return ProvidesDialog results. The phrases use the applicationName token and have packaged English and Dutch localizations. We do not register Notes or Home intents. Observed behavior: “Hé Siri, voeg boodschappen toe in Elegant Cook” and “Hé Siri, lees mijn boodschappenlijst in Elegant Cook” ask whether to use Elegant Cook or Notes. After selecting Elegant Cook, adding and reading work by voice. “Hé Siri, vink een boodschap af in Elegant Cook” and the registered app-name-first equivalent “Hé Siri, Elegant Cook boodschappen afvinken” instead produce the instruction to download Apple's Home app to use Intercom. “Hé Siri, open Elegant Cook” opens the installed app correctly. The signed build contains extracted App Intents metadata, compiled Dutch/English nlu.appintents assets and successful phrase-training output. These build checks do not establish successful device routing or App Shortcuts Preview validation. For one captured check-off invocation, local diagnostic analysis identified this sequence: the recognized utterance includes the correct app name; App Shortcuts are enabled; the intended CheckElegantCookGrocery action is a Siri candidate; app disambiguation then fails and explicitly redirects to Home/Intercom before the grocery operation. This trace covers check-off only. It does not prove that the add/read chooser has the same cause, or establish a definitive Apple framework bug. The private bug report is FB25058524. It includes selected evidence and source code. A full sysdiagnose has not been uploaded, and the isolated Swift example is not a compiled or validated reproducing Xcode project. We develop on Windows and use EAS cloud builds, so local Xcode App Shortcuts Preview is unavailable. The code-level support form currently directs us to this forum when we cannot provide a test project demonstrating the issue. Could an App Intents/DTS engineer advise: Which supported registration or metadata correction should we check when Siri identifies an explicitly named App Shortcut but chooses another domain before perform()? What targeted diagnostic evidence can distinguish an app configuration problem from a Siri routing defect without local App Shortcuts Preview? Is there a supported workaround for direct Dutch voice invocation on this OS build, without personal shortcuts or private system settings? We can prepare an isolated native sample project if required, but will clearly distinguish source preparation, cloud compilation and actual device reproduction. We do not want to claim a reproduction that has not been verified.

I'm investigating a Siri invocation failure with an explicitly declared App Shortcut phrase. The same underlying App Intent works when run directly in Shortcuts and when invoked by the name of a saved personal shortcut. Environment: iPhone 17 Pro Max, iOS 27.2 beta (24B5099f), clean restore without a backup. iPhone and Siri languages: Italian. Standard Siri, no Siri AI. Xcode 27.2 (27B5028f), iphoneos 27.2 SDK. Italian App Shortcut phrase and app metadata. PetroCheck 1.3 (637), already open during the failing invocation. The published phrase is “Trova carburanti vicini con PetroCheck”, declared using \(.applicationName). This is a phrase-based App Shortcut; the intent does not adopt an App Schema. What I observe: Saying the App Shortcut phrase produces a generic Siri error: “mi dispiace, ma si è verificato un errore”. Running the action directly in Shortcuts succeeds and records execution in the app's intent journal. Saving a personal shortcut named “Diagnostica Petro” with just that action, then saying “Esegui Diagnostica Petro”, also succeeds and records execution. Returning only a minimal Text snippet from the original intent does not resolve the phrase invocation failure. For two captured failing phrase invocations, the device logs show BackgroundShortcutRunner failing to resolve the workflow reference: -[WFWorkflowDatabaseRunDescriptor(Conversion) workflowReferenceWithDatabase:error:] Couldn't find shortcut with descriptor: <private> reason: unable to resolve workflow reference from descriptor The first of these attempts has no new entry at the recorded start of perform(). The descriptor itself is redacted, so I cannot identify which reference Siri selected. A subsequent attempt also contains these assistantd messages shortly before the descriptor error: Found no AppShortcutTargets! Could not cast to VoiceCommand task to create AppShortcut invocation AppShortcuts enablement result=false I am including these as observations, without interpreting them as proof of a disabled setting. Calling updateAppShortcutParameters() at launch did not resolve the failure. I checked the compiled device bundle's App Intents metadata: the action is discoverable, its fuel parameter is optional, and the declared shortcut points to the correct intent. The Italian training metadata contains the phrase and the application name PetroCheck. This verifies the compiled metadata, not the device's registration database. I then built a separate app, “Prova Petro”, with a different bundle identifier, a fresh phrase, one intent with no parameters, and a dialog-only result. It has no location, networking, snippet or dependencies from the original app. The Siri phrase fails in this app too. I have not yet captured its intent diary or host logs, so I cannot claim that the minimal app fails at exactly the same stage. These are the core declarations from the compiled minimal project; the sample's journal calls are omitted here: import AppIntents struct RoutingProbeIntent: AppIntent { static let title: LocalizedStringResource = "Verifica collegamento Siri" static let supportedModes: IntentModes = [.background] func perform() async throws -> some IntentResult & ProvidesDialog { return .result(dialog: "Il comando Siri ha raggiunto Prova Petro.") } } struct ProbeShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut( intent: RoutingProbeIntent(), phrases: ["Verifica Siri con \(.applicationName)"], shortTitle: "Verifica collegamento Siri", systemImageName: "checkmark.circle" ) } } The minimal app's display name is Prova Petro, and the spoken phrase is “Verifica Siri con Prova Petro”. Its App.init() calls ProbeShortcuts.updateAppShortcutParameters(). The extracted metadata confirms one shortcut, zero parameters, dialog-only output, and the Italian application name and phrase. Has anyone reproduced this difference between an App Shortcut phrase and a named personal shortcut on iOS 27.2 beta, particularly with Italian phrases? Feedback Assistant: FB25077916. The complete minimal Xcode project and scoped diagnostics are attached to the report. Is there anything missing from this setup, or a supported way to diagnose the unresolved shortcut reference? Comparisons with other OS builds, languages or devices would be useful. I have not yet established a regression against a stable OS release. Prova Petro minimal source and Siri routing logs

When navigating web components (such as accordion containers or form card containers) using Safari with VoiceOver Hints enabled, VoiceOver inappropriately prefix-announces "list item" prior to speaking form field labels ( or aria-label). Inspection of the rendered DOM confirms there are no list elements (, , ) or list ARIA roles (role="list", role="listitem") anywhere in the element hierarchy or parent container. This behavior is reproducible on native/standard web components across multiple domains, including non-Salesforce test sites such as WebAIM.org. Environment & Configuration Operating System: macOS Sonoma / Sequoia (or iOS 17 / iOS 18) Browser: Safari (Latest Stable & WebKit Nightly) Assistive Technology: VoiceOver Required VoiceOver Settings: VoiceOver Utility > Verbosity > Hints → Enabled Steps to Reproduce Enable VoiceOver (Cmd + F5 on macOS). Ensure VoiceOver Hints are turned ON under VoiceOver Utility > Verbosity > Hints. Open Safari and navigate to any standard web container containing a form field (e.g., an accordion element or card container wrapping standard text inputs). Use VoiceOver navigation key commands (VO + Left/Right Arrow or Tab navigation) to place focus onto a form field label or text input inside the container. Listen to the VoiceOver speech output string. Expected Behavior VoiceOver should announce only the accessible name/label, input role, and state. Example: "First Name, edit text" Actual Behavior VoiceOver speaks "list item" prior to reading the label and role. Example: "List item, First Name, edit text" Code / DOM Verification To verify that this is an accessibility tree/rendering engine misinterpretation rather than a markup bug, the target container was inspected: HTML

Since I updated to this os 27 in my iPhone 16 plus the siri ai and Apple Intelligence is got freeze in “ Adding support for Siri is in progress. Siri will be unavailable until the update is complete. “ I updated on 21/09/2026 today date is 30/09/2026 I tried all troubleshooting methods and watch a bunch of YouTube videos, but still stuck in the same position. I contacted Apple support. But , they also do nothing. Please anyone help me to how to get siri ai beta @appleindia @applesupport

Why is the new Siri on iPhone 18 so bad? A simple request to play a song on Spotify is constantly met with something completely random. Not to mention the constant lagging on Apple CarPlay!

I’m looking for clarification on what iOS currently allows third-party apps to do in these areas: Siri integration and background voice activation: Can an iOS app implement a custom voice assistant that responds to a wake phrase such as “Hey Nowa” and performs app tasks through voice commands? Could it listen while the app is terminated or the iPhone is locked, similar to Siri? Call recordings: Is there a supported way for an iOS app to access recordings of phone calls made on the user’s iPhone and make them available within the app? I couldn’t find documentation for an API that provides access to these recordings. SMS access: Is there a supported way for an iOS app to access and fetch all SMS and iMessage conversations stored in the user’s Messages app, so they can be viewed within our app? As far as I understand, iOS may not allow these capabilities for third-party apps, but I’d appreciate clarification. If any are supported, could you please point me to the relevant Apple documentation?

Hello fellow developers, I’ve been working with the CallKit framework in iOS, specifically handling incoming calls. One issue I’ve encountered is that Siri when "read caller name" is enabled announces the caller name/surname set via localizedCallerName and then reads the generic handle value (usually alphanumeric) too! Has anyone encountered a similar situation or if there’s a solution to prioritize the localizedCallerName over the generic handle value without using CXHandleType.emailAddress? Alternatively, any insights or workarounds you know would be greatly appreciated. TLDR: even when I correctly configure the localizedCallerName property, Siri persists in reading the CXHandleType.generic. The original Implementation with CXHandleType.generic: The issue arises when using CXHandleType.generic for alphanumeric IDs (or even URLs as stated by documentation https://developer.apple.com/documentation/callkit/cxhandle). Despite correctly setting the localizedCallerName, Siri continues to announce the generic handle value. Expected Behavior: Siri should read only the localizedCallerName when set and ignore the generic handle value when announcing incoming calls. Workaround: Currently, the only workaround is to use CXHandleType.emailAddress for alphanumeric IDs. However, this is not ideal since it repurposes an email-related handle type for a different purpose. Steps to Reproduce: Create a CallKit app that handles incoming calls (example app from documentation can be used too). On incoming call create CXCallUpdate object Create a CXHandle with CXHandleType.generic and an alphanumeric value (e.g., “ABC123”). Pass the CXHandle to the CXCallUpdate objects' remoteHandle. Set the localizedCallerName property of the CXCallUpdate object with a custom caller name/surname. Report the call with reportNewIncomingCallWithUUID Observe that Siri reads both the localizedCallerName and the generic handle value during call announcements. While we are here a Feature Request: Developers should be able to provide a user-friendly caller name without resorting to workarounds like using CXHandleType.emailAddress. I kindly request that Apple consider enhancing Siri’s behavior in the following ways: Allow developers to suppress the reading of generic handle values while still using the correct handle type. Introduce additional type options for call announcements that don't read the generic value. Both of the above. Thank you for your help! 🙌

I am unable to dismiss Voice Control Siri AI bubble when enabling Voice Control in iOS 27. Can someone from accessibility team provide guidance on how to dismiss without touching the screen in the activation flow? Siri bubble remains on screen... Thank you, and appreciate all the work you do. Voice Control is an amazing capability system wide.

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 want to share a Siri / Apple Intelligence issue I have been troubleshooting since the iOS 27 beta cycle, together with the configuration that finally resolved it. The issue started during iOS 27 beta, continued across multiple beta builds, and was still present after I updated to the official iOS 27 release. Updating iOS alone never fixed it. The main problem was that Siri / Apple Intelligence repeatedly failed to complete activation. Settings would remain stuck on: “Adding support for Siri is in progress” The Siri app would sometimes show: “Siri is not available” Siri also frequently fell back to the older floating-sphere interface instead of using the newer glowing-edge interface. Sometimes the new Siri interface would suddenly appear and work normally, but later it would fall back again. The most repeatable symptom involved charging. When the iPhone was connected to power, Siri sometimes appeared to finish downloading and would temporarily work normally. After disconnecting the charger, Siri could become unavailable again or the system would behave as though Siri resources still needed to be downloaded. Connected to power → Siri sometimes worked normally Disconnected from power → Siri could return to downloading / unavailable There was also a difference between Wi-Fi and cellular data. On cellular data, iOS sometimes said Wi-Fi was required to continue downloading Siri resources. After connecting to Wi-Fi, it would return to “Adding support for Siri is in progress” and still fail to finish. Apple Intelligence storage also behaved abnormally. At one point, iPhone Storage showed approximately 7.37 GB in use. Later, the Apple Intelligence entry disappeared and storage usage decreased, then reappeared after changing language settings. Before finding the working configuration, I had already tried restarting, Reset All Settings, Recovery Mode update, multiple iOS 27 beta builds, the official iOS 27 release, different Wi-Fi networks, cellular data, disabling VPN/proxy, changing languages, removing additional languages, switching between old and new Siri, and leaving the phone on Wi-Fi and power for long periods. None provided a permanent fix. After repeated testing, the issue appeared to involve network transport, routing consistency, Siri language / voice configuration, Siri AI authorization, and local asset refresh. My final working setup was: System language: English (United States) Region: United States Siri language: English (United States) Siri voice: American Apple Intelligence enabled Proxy environment: Shadowrocket Proxy transport My proxy node uses an AnyTLS-based configuration. Previously, UDP traffic was enabled. During troubleshooting, some Apple / iCloud requests appeared unreliable when using UDP / QUIC through this node, with timeouts, resets, or repeated retries. I changed the node transport to TCP only while keeping TLS enabled: TCP + TLS After this change, Apple-related authentication and asset requests appeared much more stable. Routing rules This was one of the most important changes. I use split tunneling so that Chinese apps can remain DIRECT while selected traffic uses the proxy. However, some Apple traffic was being matched by broader fallback rules such as: apple.com,DIRECT GEOIP,CN,DIRECT This meant some Siri / iCloud / Apple Intelligence requests could use the proxy while related requests went directly through the local connection. I added these high-priority rules and moved them above broader Apple / DIRECT / GEOIP rules: DOMAIN-KEYWORD,gateway,PROXY DOMAIN-KEYWORD,probe,PROXY DOMAIN-KEYWORD,gdmf,PROXY DOMAIN-KEYWORD,guzzoni,PROXY DOMAIN-SUFFIX,iphone-ld.apple.com,PROXY Rule priority was important. If broader DIRECT rules were above these entries, the specific traffic could still bypass the proxy. After moving these rules to the top, the relevant Apple traffic consistently followed the same network path. Split tunneling still worked normally, and apps such as WeChat, Alipay, Meituan, and Xiaohongshu could remain DIRECT. Language and Siri configuration I standardized the Siri environment: System Language: English (United States) Region: United States Siri Language: English (United States) Siri Voice: American I selected an American Siri voice, such as Voice 4. After changing everything to the same English (US) environment, asset loading became more consistent. Enable Siri AI I manually selected: Try Siri AI (Beta) and completed the authorization process. I also temporarily disabled “Require Face ID” for the standalone Siri app while troubleshooting. I cannot confirm that this directly affected the download, but it removed an extra authentication layer while testing. Refresh local language assets I opened Apple’s built-in Translate app, deleted the downloaded English (US) language package, and downloaded it again. My goal was to refresh the local language / MobileAsset download state. I cannot confirm that Translate directly controls Siri’s generative models, but this appeared to help clear the remaining stuck asset state. Final installation step After making all of the above changes, I connected the iPhone to Wi-Fi and power, locked the screen, and left the device idle for approximately 10–15 minutes. After this, the Siri / Apple Intelligence state finally changed and remained stable. Current result: Siri consistently uses the full-screen glowing-edge interface Type to Siri works correctly Siri no longer falls back to the legacy floating-sphere interface “Siri is not available” no longer appears “Adding support for Siri is in progress” is no longer permanently stuck Apple Intelligence remains active Siri continues working after disconnecting the charger Split tunneling still works normally Most importantly, the previous charging-related behavior is gone. Before: Connected to power → Siri temporarily worked Disconnected from power → Siri failed again Now: Siri continues to work normally whether or not the device is connected to power. I am not claiming that Apple has officially documented every domain or internal process above as the root cause. These findings are based on repeated troubleshooting and network behavior observed on my own device. However, this issue persisted from the iOS 27 beta cycle through the official iOS 27 release, and standard system updates alone did not resolve it. In my case, the successful fix only came after correcting the combination of: TCP transport + consistent Apple routing + English (US) system / Siri configuration + Siri AI authorization + local asset refresh. If anyone else is experiencing “Adding support for Siri is in progress,” “Siri is not available,” repeated fallback to the legacy Siri UI, Apple Intelligence storage disappearing / reappearing, or Siri working while charging but failing after unplugging, I would be interested to know whether the same configuration also resolves the issue on other devices.

I had a complete voice-only experience working with AppIntents and AppShortcuts on iOS 27.0 prior to enabling Siri AI. Once I enabled Siri AI, Siri refused to recognize any of the donated phrases in one particular AppShortcut. It still worked for several others. For the AppShortcut that no longer works, Siri responds to some of the phrases claiming the app doesn't support that action through Siri, and Siri responds to some of the phrases telling me I need to open the app to do that. FB24854409 includes a Sysdiagnose file. Note that I'm aware of App Schemas, but none apply well to my app.

I’m seeing a reproducible UI bug with Spotlight on macOS 27 RC (26A428). The issue has been present since at least build 26A5416b (Developer Beta 6 / Public Beta 4), persisted through subsequent beta releases, and is still reproducible on RC 26A428. When I open Spotlight using the new Search or Ask interface and begin typing, the entered query text can become completely invisible from approximately the second character onward, even though Spotlight continues searching and displaying results normally. The interesting part is that the issue seems tied to Spotlight updating its search results. For example: Open Spotlight. Type a character that quickly matches something on the Mac. Continue typing. Once the results update, the query text becomes invisible. If I type random characters extremely quickly, before Spotlight has time to return a result for the first few characters, the text may remain visible. Another useful detail: after the query text disappears, pressing Delete/Backspace causes it to become visible again. The search itself is still functioning, the problem appears to be with rendering or state updates in the new Siri-integrated Spotlight query field, rather than with Spotlight search/indexing itself. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by user preferences, caches, login items, or third-party software. I submitted a screen recording through Feedback Assistant that clearly shows the text disappearing as results update. Feedback: FB24462893 Is anyone else seeing this on the RC? The correlation between the text disappearing and the results UI updating makes me suspect a rendering/state-update issue in the new Spotlight interface.

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

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

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