Allow the user to add their own tags to the default emoji tags. For instance, this emoji, for me, is nonna: 🤌🏻. My efficiency would improve immensely if I could search for it as the “Nonna” emoji, rather than searching for nonna, remembering it doesn’t exist, trying the search for other things it might be called, realising I don’t know what it is, then having to scroll through all the hand emojis twice to find it. 🤌🏻🤞🏼👌

Over the years apple y'all have continued to improve iOS adding many new features and I’m very impressed with the new ai features however there’s one thing that yall haven’t added for some reason and it’s a clear all tabs button. It would make things so much easier instead of swiping up on all those tabs you can you just press a button and everything’s reset. I don’t know if y'all have a reason for not adding the button yet but just putting it out there.

When My Usb interface working on recording， the sync is not good work. I found every IO will in_io_buffer_frame_size is same， it is not sync to UpdateCurrentZeroTimestamp. So The Audio driver Kit Read opration is not same like Write? What is the way sync with Usb in data? If only play audio with UpdateCurrentZeroTimestamp, it working fine. Thanks!

Triple tap for screenshot->notification->triple tap detected becomes a part of the screenshot and obscures the top part of screenshot. Thanks

I have an application that binds a menu item to trigger on ⌘]. When I set the US input source, I press ⌘] in order to trigger that item. However, when I switch the input source to QWERTZ (German), the trigger changes to ⌘Ä automatically by the OS. It seems to translate keystrokes for different input sources. The problem is that I also render the keybindings in a window in my application, and my application is not aware of this translation. Furthermore, I have other key shortcuts in my application which are not bound to menu items, and I want to make sure those get translated too. Does AppKit expose a way to lookup what a keystroke will be when MacOS translates it, i.e. lookup ⌘Ä from ⌘] when the current layout is QWERTZ? I can't find anything in Apple's docs. I tried converting a character to virtual key code based on the US layout and then mapping it back to a character based on the QWERTZ layout. That doesn't seem to be the same b/c that ends up converting ] to + instead which seems to be based on physical key location, different from how the keybindings are handled. Update: I notice similar behavior for VS Code's menu bar, e.g. in their "Terminal" menu. Switching to German changes some bindings. This does not occur at all in iTerm's menu bar, I suspect b/c their menu items are specified in a different way, xib files with hard-coded key equivalents

VoiceOver reads out all visible content on the screen, which is essential for visually challenged users. However, this raises a privacy concern—what if a user accidentally focuses on sensitive information, like a bank account password, and it gets read aloud? How can developers prevent VoiceOver from exposing confidential data while still maintaining accessibility? Are there best practices or recommended approaches to handle such scenarios effectively?

I am developing an app using DeviceActivity. let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour : 0, minute : 0, second: 1), intervalEnd: DateComponents(hour : 23, minute : 59, second: 59), repeats: true ) I found that on the second day, intervalDidStart(for: DeviceActivityName) gets called multiple times. I also tried let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour : 0, minute : 0, second: 1), intervalEnd: DateComponents(hour : 23, minute : 59, second: 59), repeats: false ) and started monitoring for the next day in the intervalDidEnd(for: DeviceActivityName) method. but ， intervalDidStart(for: DeviceActivityName) still gets called multiple times. How should I resolve this issue?

Hi, On iOS, I'd like to mark views that are inside a LazyVStack as headers for VoiceOver (make them appear in the headings rotor). In a VStack, you just have add .accessibilityAddTraits(.isHeader) to your header view. However, if your view is in a LazyVStack, that won't work if the view is not visible. As its name implies, LazyVStack is lazy so that makes sense. There is very little information online about system rotors, but it seems you are supposed to use .accessibilityRotor() with the headings system rotor (.accessibilityRotor(.headings)) outside of the LazyVStack. Something like the following. .accessibilityRotor(.headings) { ForEach(entries) { entry in // entry.id must be the same as the id of the SwiftUI view it is about AccessibilityRotorEntry(entry.name, id: entry.id) } } It kinds of work, but only kind of. When using .accessibilityAddTraits(.isHeader) in a VStack, the view is in the headings rotor as soon as you change screen. However, when using .accessibilityRotor(.headings), the headers (headings?) are not in the headings rotor at the time the screen appears. You have to move the accessibility focus inside the screen before your headers show up. I'm a beginner in regards to VoiceOver, so I don't know how a blind user used to VoiceOver would perceive this, but it feels to me that having to move the focus before the headers are in the headings rotor would mean some users would miss them. So my question is: is there a way to have headers inside a LazyVStack (and are not necessarily visible at first) to be in the headings rotor as soon as the screen appears? (be it using .accessibilityRotor(.headings) or anything else) The "SwiftUI Accessibility: Beyond the basics" talk from WWDC 2021 mentions custom rotors, not system rotors, but that should be close enough. It mentions that for accessibilityRotor to work properly it has to be applied on an accessibility container, so just in case I tried to move my .accessibilityRotor(.headings) to multiple places, with and without the accessibilityElement(children: .contain) modifier, but that did not seem to change the behavior (and I could not understand why accessibilityRotor could not automatically make the view it is applied on an accessibility container if needed). Also, a related question: when using .accessibilityRotor(.headings) on a screen, is it fine to mix uses of .accessibilityRotor(.headings) and .accessibilityRotor(.headings)? In a screen with multiple type of contents (something like ScrollView { VStack { MyHeader(); LazyVStack { /* some content */ }; LazyVStack { /* something else */ } } }), having to declare all headers in one place would make code reusability harder. Thanks

I am trying to implement voice over to my game, and have encountered an issue where a static text will take focus of all other interactions. I have a tutorial scene where I have one short "static text" accessibility node, but rest of gameplay is without such. This static text field occupies small part of screen and works fine, but I am not able to click on anything else, including any of my gameplay elements, wherever on the screen I click, it just re-highlights that static text. It there a requirement for all elements to use Accessibility Nodes and can't have mixed setup with some not having them ? How can I get around it? Question number 2: What decides which Accessibility node gets selected when entering a new UI screen, I have multiple buttons and am observing rather random behaviour, every time different button is highlighted first. Question number 3: The plugin documentation mentiones runtime support in play mode, are there any specific steps for this to work as I can't seem to be able to. I have VoiceOver enabled on macOS unity is on macOS (also tried iOS) platform but it doesn't seem to do anything. Note my buttons and label accessibility nodes work correctly on iOS build. Thanks in advance for any help

I’ve noticed that the writing tools frequently display content warnings for certain topics, often more than seems necessary, and I would love to see a way to disable them in my app. Specifically, I have encountered many situations where mentioning LGBTQ topics triggers a content warning and temporarily blocks the user, while similar mentions of heterosexual topics do not. For example: Triggers Content Warning: “I’ve been listening to this song on repeat yesterday and today haha. It’s really nice that it’s about being homosexual ~u~” “I’ve been listening to this song on repeat yesterday and today haha. It’s really nice that it’s about being *** ~u~” Does Not Trigger Content Warning: “I’ve been listening to this song on repeat yesterday and today haha. It’s really nice that it’s about being heterosexual ~u~” “I’ve been listening to this song on repeat yesterday and today haha. It’s really nice that it’s about being straight ~u~” This inconsistency not only introduces unnecessary friction when discussing diverse topics but may also inadvertently suggest that LGBTQ topics are inappropriate or immoral. Such an implication could be harmful to many users, especially young adults, by reinforcing negative perceptions of LGBTQ issues. I believe it’s important for the AI writing tools to handle all topics equitably to promote inclusivity and diversity. And would love to be able to disable these warnings in my app. here’s a video showcasing the example prompts above: https://share.icloud.com/photos/0bdGPxy2xmGZT2ildAU4ThERQ

When turning VoiceOver ON, GCController does not send button press events for "Button A" and "Button Center". This happens when using Siri 2nd generation remote (with dedicated arrow buttons on the circle around center button) and also when using iOS remote. I didn't test it on old Siri 1st generation with touchpad without arrow buttons. Example: gameController.microGamepad?.allButtons.forEach { button in button.valueChangedHandler = { [weak self] _, _, _ in self?.buttonHandler(gameController: gameController, button: button) } private func buttonHandler(gameController: GCController, button: GCControllerButtonInput) { print("BUTTON: Pressed \(button.description) isPressed=\(button.isPressed) isTouched=\(button.isTouched)") } #endif VoiceOver ON (incorrect behavior): BUTTON: Pressed Direction Pad Left (value: 0.030, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Direction Pad Down (value: 0.079, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Direction Pad Left (value: 0.000, pressed: 0) isPressed=false isTouched=false BUTTON: Pressed Direction Pad Down (value: 0.000, pressed: 0) isPressed=false isTouched=false VoiceOver OFF (correct behavior): BUTTON: Pressed Direction Pad Left (value: 0.137, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Direction Pad Up (value: 0.078, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Button A (value: 1.000, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Button Center (value: 1.000, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Button A (value: 0.000, pressed: 0) isPressed=false isTouched=false BUTTON: Pressed Button Center (value: 0.000, pressed: 0) isPressed=false isTouched=false BUTTON: Pressed Direction Pad Left (value: 0.000, pressed: 0) isPressed=false isTouched=false BUTTON: Pressed Direction Pad Up (value: 0.000, pressed: 0) isPressed=false isTouched=false I could use for detection Direction Pad Left/Right/Up/Down and detect position between -0.7 and +0.7 and handle it as center button press, because I use that on old Siri remote where I need to distinguish center button and arrows (for switching TV channels by Up/Down and Skip forward/back by Left/Right arrows), but for new Siri remote it would be unnecessary workaround. Does anybody know why the center/select button is not detected when VoiceOver is ON. Is there another way of detecting it using GCController? I don't want to use SwiftUI onTapGesture for this one particular case. Is it an unexpected bug in tvOS APIs or is there some specific reason why center button is not handled by GCController when VoiceOver is ON? Thanks.

In our application we are using a pop over view and we have enabled the accessibility VoiceOver, When user navigating inside the popover and reached to the last element that time with the right swipe we need to dismiss the popover.

I have a stackview which have 2 labels class TextView: UIView { @IBOutlet private weak var stackView: UIStackView! { didSet { stackView.isAccessibilityElement = true stackView.accessibilityLabel = label1.text + label2.text } } @IBOutlet private weak var label1: UILabel! { didSet { label1.accessibilityIdentifier = "label1" } } @IBOutlet private weak var: UILabel!{ didSet { label2.accessibilityIdentifier = "label2" } } } My goal here is to have a combines accessibility label for the stackview and yet able to access the accessibilityIdentifier of child elements for automation.

since having updated my iPad with subject title update, I can no longer type French accents with my magic keyboard. The toggle between English and French is there, the actual key type is no longer available.

I want to expose few elements for accessibility alone and other for automation alone. But I can only accessibility elements in Accessibility Inspector but can't see Automation Elements self.view.accessibilityElements = [loginButton as Any, registerButton as Any, closeButton as Any] self.view.automationElements = [claimLabel as Any, loginButton as Any, registerButton as Any, intoductionImage as Any, closeButton as Any])

I'm developing a document editor for macOS using AppKit, which supports structured content such as titles and multiple heading levels—similar to what you see in the Pages app. I'm looking for a way to programmatically mark a specific substring within an NSTextView as a heading, so that VoiceOver can recognize it and announce it appropriately (e.g., by saying “heading” before reading the text). This would be similar in spirit to how NSAccessibilityLinkTextAttribute works for links. Is there an existing accessibility text attribute or recommended approach to achieve this behavior for headings? If not, I’d appreciate any guidance or suggestions on how best to implement this in a VoiceOver-friendly way. Thank you in advance for your help! Best regards,

Currently i am using an iphone 15 pro which is just 7 months old but it was good till this month it was at 97% even after using more than 6 months, but in recent fews days it is regularly dropping by 1% every day and now it is at 89% only with 10 to 12 days it dropped by 8% . Is my battery defective or something is wrong with my phone . bcoz of this i am very upset because of this bad decrease of battery health . i have heard it is normal to degrade by 1% monthly but mine is dropping daily its soo frustrating. and if my battery reaches under 80% within the warrenty period? will get a free battery replacement from apple or not ? I don’t have apple care+ . But its under 1 year standard warrenty . please reply apple as its soo frustrating

I'm trying to validate my app's handling of voiceover accessibility when using VoiceOver hotspots. What I'm doing: Set a hotspot Validate hotspot references correct control within the hotspot chooser set another hotspot Validate hotspot references both correct controls within the hotspot chooser Try to use one of the hotspots Result: The hotspot has changed to some other control in the app (usually one of the window buttoms (close, minimze, full screen) but at other times are one of the menus or a completely different control in the window. My question is how I can debug what might be going on in the app when the hotspots are resolved and invoked. I'm assuming I have some accessibility property set improperly for these controls that are causing incorrect resolution of the hotspots.

addition of Central Kurdish language support for Text-to-Speech (TTS) and VoiceOver functionality on Apple products. Our TTS model boasts an impressive 99.9% accuracy, making it a highly reliable tool for this purpose. This initiative would bring meaningful benefits to over 10,000 visually impaired and more than 40,000 illiterate individuals in the Kurdistan Region of Iraq, empowering them to access digital information, navigate devices, and perform tasks more independently. The integration of Central Kurdish VoiceOver support would make a significant difference in improving accessibility and quality of life for these individuals, promoting inclusivity and digital literacy in the region.

Hi, I’ve been reviewing the Apple Wallet provisioning documentation (Getting Started with Apple Pay In-App Provisioning_ Verification_Security_Wallet Extensions )and had a few questions regarding the color path recommendation (Green, Yellow, Orange, Red) returned during the in-app provisioning flow: Who determines the color path—is it Apple directly, the Payment Network Operator (PNO), or both? What criteria are used to determine the color path (e.g., device info, Apple ID reputation, past provisioning attempts)? At what point in the provisioning flow is the color path recommendation received? Is it included in the response after the PKAddPaymentPassRequest is submitted? Is it accessible through any specific property or callback in the delegate method? Additionally, for Orange Path with Reason Code 0G, I understand that in-app verification is not allowed and must be handled via tenured channels (e.g., SMS/email). Can you confirm if this logic still applies for requests initiated from within the issuer's iOS app? Would appreciate any clarification or pointers to related documentation.