Hi everyone — I’m implementing the new Hearing Device Support API described here: https://developer.apple.com/documentation/accessibility/hearing-device-support I have MFi hearing aids paired and visible under Settings → Accessibility → Hearing Devices, and I’ve added the com.apple.developer.hearing.aid.app entitlement (and also tested with Wireless Accessory Configuration: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.external-accessory.wireless-configuration ). com.apple.developer.hearing.aid.app xxxxx but the app won't even compile with this entitlement Problem NotificationCenter.default.addObserver(...) for pairedUUIDsDidChangeNotification never fires — not on app launch, not after pairing/unpairing, and not after reconnecting the hearing aids. Because the notification never triggers, calls like: HearingDeviceSession.shared.pairedDevices always return an empty list. What I expected According to the docs, the notification should be posted whenever paired device UUIDs change, and the session should expose those devices — but nothing happens. Questions Does the hearing.aid.app entitlement require special approval from Apple beyond adding it to the entitlements file? Is there a way to verify that iOS is actually honoring this entitlement? Has anyone successfully received this notification on a real device? Any help or confirmation would be greatly appreciated.

Is the accessibility feature, voice command recording available on the Apple Vision Pro? It does not start on my device. The Apple Vision Pro is on 26.1. Regular single voice commands work on the Apple Vision Pro. Recording commands worked on other devices. (iPad and iPhone)

Hi everyone, I’ve been analyzing the current state of Sign Language accessibility tools, and I noticed a significant gap in learning tools: we lack real-time feedback for students (e.g., "Is my hand position correct?"). Most current solutions rely on 2D video processing, which struggles with depth perception and occlusion (hand-over-hand or hand-over-face gestures), which are critical in Sign Language grammar. I'd like to propose/discuss an architecture leveraging the current LiDAR + Neural Engine capabilities found in iPhone devices to solve this. The Concept: Skeleton-based Normalization Instead of training ML models on raw video frames (which introduces noise from lighting, skin tone, and clothing), we could use ARKit's Body Tracking to abstract the input. Capture: Use ARKit/LiDAR to track the user's upper body and hand joints in 3D space. Data Normalization: Extract only the vector coordinates (X, Y, Z of joints). This creates a "clean" dataset, effectively normalizing the user regardless of physical appearance. Comparison: Feed these vectors into a CoreML model trained on "Reference Skeletons" (recorded by native signers). Feedback Loop: The app calculates the geometric distance between the user's pose and the reference pose to provide specific correction (e.g., "Raise your elbow 10 degrees"). Why this approach? Solves Occlusion: LiDAR handles depth much better than standard RGB cameras when hands cross the body. Privacy: We are processing coordinates, not video streams. Efficiency: Comparing vector sequences is computationally cheaper than video analysis, preserving battery life. Has anyone experimented with using ARKit Body Anchors specifically for comparing complex gesture sequences against a stored "correct" database? I believe this "Skeleton First" approach is the key to scalable Sign Language education apps. Looking forward to hearing your thoughts.

Hello Albert! I am experiencing some strange bugs around DeviceActivityEvents (part of the DeviceActivity framework) on iOS 26 / iOS 26.1 / iOS 26.2 beta: When creating a DeviceActivityEvent we can assign a threshold and applicationTokens. The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold() is called. The property includesPastActivity is set to false. On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold() is called immediately (after a couple of seconds) instead of waiting for the threshold to be met. Is anyone else seeing similar issues on iOS 26 / iOS 26.1 / iOS 26.2 beta? Only workaround I have found is to ask users to revoke and re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed, so it is not a permanent solution unfortunately. Feedback (incl. sysdiagnoses and sample project) is filed under: FB18061981 FB18927456 One of our users has filed their own feedback request as well: FB20817853 Thanks a lot for any help on this!

Hello! I'm creating a settings page for my app and I want it to look as native as possible. I want to know if it's possible to add constraints that make the second label go to the bottom when the text size gets really large (see Picture1) instead of having to force it to be on the right (see Picture 2). I've left my constraint code for this cell down below, too. I'm still learning constraints and best practices, so if there's any feedback, I'd love to hear it. Thank you! Picture 1 Picture 2 - (void) setConstraints { [NSLayoutConstraint activateConstraints:@[ // Cell Title Label [self.themeColorLabel.leadingAnchor constraintEqualToAnchor:self.contentView.layoutMarginsGuide.leadingAnchor], [self.themeColorLabel.trailingAnchor constraintEqualToAnchor:self.contentView.layoutMarginsGuide.trailingAnchor], [self.themeColorLabel.topAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.topAnchor], [self.themeColorLabel.bottomAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.bottomAnchor], // Selected Theme Color Label [self.selectedColorLabel.trailingAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.trailingAnchor], [self.selectedColorLabel.topAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.topAnchor], [self.selectedColorLabel.bottomAnchor constraintEqualToAnchor: self.contentView.layoutMarginsGuide.bottomAnchor], ]]; }

Context: We are using UIKit to provide accessibility in our app for our iOS users. Our app majorly contains documents/books that user can read. Issue: The issue is VoiceOver is skipping the lines given to it when there are some leading spaces in it. We have observed this issue in different languages. This is only happening for line granularity, other granularities seems to be working as expected. Implementation: We are using below API's to provide line content to voice over. UIAccessibilityReadingContent - accessibilityPageContent - accessibilityFrameForLineNumber - accessibilityContentForLineNumber We are creating UIAccessibilityElement objects to pass to VoiceOver and each UIAccessibilityElement implements UIAccessibilityReadingContent to provide readable content. We also use below APIs to cross element boundaries for all granular navigations. accessibilityNextTextNavigationElement accessibilityPreviousTextNavigationElement We want to know whether skipping the line when provided with leading spaces is expected or a bug in UIKit.

On macOS, I get a system popup when running UI tests in GitHub saying: “bash” is requesting to bypass the system private window picker and directly access your screen and audio. How can I prevent these login and screen access popups from appearing during automated UI tests? Is there an official setup or configuration for running IntelliJ UI tests in CI environments (macOS, Linux, Windows) to avoid such dialogs? My builds run in GitHub Actions VMs, so I can’t manually grant these permissions, and they block the tests.

Hello Apple Developer Support, I’m writing with a mix of enthusiasm and frustration after more than six months of full‑time development on my macOS window‑manager TilesWM (a feature‑rich competitor to Magnet, Divvy, BetterSnapTool, etc.). I have completed the Application, the product page, a knowledge-base with 90+ entries, an in-app onboarding flow, preparing the feedback-hub for submissions, all required marketing assets and finally; signing up for the $99 Developer Program... I am now blocked at App Store Connect validation. What I’m trying to submit App name: TilesWM Bundle ID: dev.steinhorst.tileswm Core functionality: Detect window movement & resize windows, optional global hot‑keys, persistent user settings are stored in a SQLite-DB located at: ~/Library/Application Support/<bundle‑identifier> Privacy: No analytics, no data collection, no runtime downloads. Tested on: macOS 15.6.1 (Apple Silicon M1) & macOS 26.0.1 (M3‑Max). The app works exactly like the existing mainstream window managers: it runs non‑sandboxed and requests Accessibility (AX) permissions on demand to control other windows dimensions and positioning. Validation errors Validation failed Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, key 'com.apple.security.accessibility' in 'dev.steinhorst.tileswm.pkg/Payload/TilesWM.app/Contents/MacOS/TilesWM' is not supported. (ID: 13b13813-edd6-4be6-b392-9db5bddd39a0) Validation failed App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "dev.steinhorst.tileswm.pkg/Payload/TilesWM.app/Contents/MacOS/TilesWM" )] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. (ID: 28aa17e8-e7b2-4f3f-8def-15922c68ec8a) . In short, App Store Connect refuses to accept an app that uses the Accessibility API and is not sandboxed. Yet the same capability is openly used by Magnet, Divvy, BetterSnapTool and other competitors that are currently on the Mac App Store. Why this matters to me I am a full‑stack engineer with 15+ years of enterprise experience; side projects keep my skills sharp and give back to the macOS community. This would be my entry to the software-side of MacOS, the next product-ideas are scribbled already. Over the last six months I have designed, coded, documented, created marketing assets, purchased a domain, paid for hosting, and funded the Apple Developer Program, all in good faith that the app could be submitted. What I need help with Clarification – Is the com.apple.security.accessibility entitlement truly unsupported for macOS distribution, how can Magnet and other competitors exist in that case, shouldn't they be able to receive competition? Guidance – If sandboxing is mandatory (even though the competition doesn't use it either, looking at their entitlements with codesign -d --entitlements :-<path>). What is the recommended way to retain full window‑management functionality while remaining within Apple’s policies, I tried sandboxing it, but the only app I was able to "resize" was TilesWM (my App) itself. Additional resources A "basic"-demo video, feature comparisons, FAQ & knowledge-base as well as the feedback hub: https://www.tileswm.app I appreciate any insight you can provide. My goal is to bring a polished, useful tool to the Mac App Store while fully respecting Apple’s security requirements, without having to discard months of work or resort to an external distribution model. Thank you for your time and assistance. Best regards, Denis Steinhorst Full‑Stack Engineer – macOS enthusiast Bundle ID: dev.steinhorst.tileswm

In the example below, VoiceOver (in both iOS 18 and 26) reads the text contained within the image after the .accessibilityLabel, introduced by a “beep.” VoiceOver: Purple rounded square with the word 'Foo' in white letters. Image [beep] foo. I’d like it to only read the accessibility label. As a developer focused on accessibility, I make sure every image already has an appropriate label, so having iOS read the image text is redundant. Sample Code import SwiftUI struct ContentView: View { var body: some View { Image("TextInImage") .resizable() .scaledToFit() .frame(width: 64, height: 64) .accessibilityLabel("Purple rounded square with the word 'Foo' in white letters.") } } Sample Image Drop this image in to Assets.xcassets and confirm it's named TextInImage.

I would like to propose a design enhancement for future iPhone models: using the existing bottom-right antenna line (next to the power button area) as a capacitive “volume control zone” that supports swipe gestures. Today this line is a structural antenna break, but it is also located exactly where the thumb naturally rests when holding the phone in one hand. With a small embedded capacitive/force sensor, the user could slide their finger along this zone to control volume without reaching for the physical buttons. Why this makes sense: • Perfect ergonomic thumb position in both portrait and landscape • One-handed volume adjustment becomes easier for large-screen devices • Silent and frictionless vs. clicking buttons (useful in meetings / night mode) • Consistent with Apple’s recent move toward contextual hardware input (Action Button, Capture Button, Vision Pro gestures) The interaction model would be: • Swipe up → increase volume • Swipe down → decrease volume • (Optional) long-press haptic = mute toggle This could also enhance accessibility, especially for users with reduced hand mobility who struggle to press mechanical buttons on tall devices. Technically, this would be similar to the Capture Button (capacitive + pressure layers), but linear instead of pressure-based. It does not replace physical buttons, it complements them as a silent gesture-based alternative. Thank you for considering this as a future interaction refinement for iPhone hardware design.

Hello, Whenever I put accessibility focus on an image and if image has some text in it, voiceover reads that text along with image's accessibility label. Is there a way to programmatically turn off text recognition on images for accessibility? I couldn't find any relevant accessibility API's that could help here. Thanks!

We've identified a regression in iOS 26.0 and 26.1 Beta 4 where AVSpeechSynthesisVoice(language:) no longer respects user-selected voices from Accessibility settings. Issue: When users select a specific voice in Settings → Accessibility → Spoken Content → Voices, calling AVSpeechSynthesisVoice(language:) returns the system default voice instead of the user's selection. This worked correctly in iOS 18.6.2. Particularly affects: Third-party speech synthesis voices (CereProc, Grammatek, etc.) Apps relying on automatic voice selection based on user preferences Example: // User selected CereProc Heather for en-GB in Accessibility settings let voice = AVSpeechSynthesisVoice(language: "en-GB") print(voice?.name) // iOS 18.6.2: "HEATHER", iOS 26: "Daniel" (system default) Interesting observation: The new Accessibility Reader feature in iOS 26 correctly uses the user-selected voice, but Tap to Speak and the API both ignore the setting. Tested methods: AVSpeechSynthesisVoice(language:) AVSpeechUtterance auto-selection Reflection for new APIs All return the system default voice, not the user's preference. Filed: FB[20271264] Has anyone else encountered this? Any known workarounds to programmatically access the user's preferred voice selection?

Hello! My question is about 1) if we can use any and or all accessibility features within a sandboxed app and 2) what steps we need to take to do so. Using accessibility permissions, my app was working fine in Xcode. It used NSEvent.addGlobalMonitorForEvents and localMoniter, along with CGEvent.tapCreate. However, after downloading the same app from the App Store, the code was not working. I believe this was due to differences in how permissions for accessibility are managed in Xcode compared to production. Is it possible for my app to get access to all accessibility features, while being distributed on the App Store though? Do I need to add / request any special entitlements like com.apple.security.accessibility? Thanks so much for the help. I have done a lot of research on this online but found some conflicting information, so wanted to post here for a clear answer.

When building with the iOS 26 SDK (currently beta 4), the navigation title is often illegible when rendering a Map view. For example, note how the title "Choose Location" is obscured by the map's text ("South America") in the screenshot below: This screenshot is the result of the following view code: import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } I tried using the scrollEdgeEffectStyle(_:for:) modifier to apply a scroll edge effect to the top of the screen, in hopes of making the title legible, but that doesn't seem to have any effect. Specifically, the following code seems to produce the exact same result shown in the screenshot above. import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .scrollEdgeEffectStyle(.hard, for: .top) // ⬅️ no apparent effect .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } Is there a recommended way to resolve this issue so that the navigation title is always readable?

Feedback number: FB20451665 When building with Xcode 26, Voice Over is reporting an extra tab when swiping through tabs. Please see the sample project below: /* This is a Sample project to show that I believe there is a Voice Over bug in iOS 26. When swiping through tabs with Voice Over active, there always appears to be an extra tab. Here I have 5 tabs, when on tab one VO reads out tab 1 of 6, then tab 2 of 6, all the way to the last tab, when voice over reads out tab 5 of 6. Never tab 6 of 6. Is there a possibility that voice over is picking up the underlying `more` tab and reading that out? This has also been reportedly found in the Files app here: https://www.applevis.com/comment/195441#comment-195441 */ struct ContentView: View { var body: some View { TabView { /// Activating this has Voice over telling us there are 6 Tabs. Tab(RootTab.home.title, systemImage: "circle.fill") { Text("This is the \(RootTab.home.title.capitalized) screen") } .accessibilityLabel("\(RootTab.home.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.home.title.capitalized) tab") Tab(RootTab.diary.title, systemImage: "circle.fill") { Text("This is the \(RootTab.diary.title.capitalized) screen") } .accessibilityLabel("\(RootTab.diary.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.diary.title.capitalized) tab") Tab(RootTab.meals.title, systemImage: "circle.fill") { Text("This is the \(RootTab.meals.title.capitalized) screen") } .accessibilityLabel("\(RootTab.meals.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.meals.title.capitalized) tab") Tab(RootTab.knowledge.title, systemImage: "circle.fill") { Text("This is the \(RootTab.knowledge.title.capitalized) screen") } .accessibilityLabel("\(RootTab.knowledge.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.knowledge.title.capitalized) tab") Tab(RootTab.profile.title, systemImage: "circle.fill") { Text("This is the \(RootTab.profile.title.capitalized) screen") } .accessibilityLabel("\(RootTab.profile.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.profile.title.capitalized) tab") /// Activating this also has Voice over telling us there are 6 Tabs. // ForEach(RootTab.allCases, id: \.self) { tab in // // Text("This is the \(tab.title.capitalized) screen") // .tabItem { // Label(tab.title.capitalized, systemImage: "circle.fill") // } // .accessibilityLabel("\(tab.title.capitalized) tab") // .accessibilityHint("Double tap to open the \(tab.title.capitalized) tab") // } } } enum RootTab: CaseIterable { case home case diary case meals case knowledge case profile var title: String { switch self { case .home: "home" case .diary: "diary" case .meals: "meals" case .knowledge: "knowledge" case .profile: "profile" } } } } I'm curious if anyone else can see this issue, or if anyone knows of a workaround for it.

Hello all 👋 We're developing an app for families with neurodivergent members (primarily autistic children) and have run into a critical reliability issue with silent push notifications that breaks core functionality. Our current implementation: When a caretaker updates the person's daily routine/schedule in our system, we send a silent push notification to the user's device. The app wakes, connects to our server, downloads the updated schedule, and creates/updates local notifications for upcoming activities. The problem: Because the app is rarely/never directly interacted with by the end user (the child doesn't open the app - caregivers configure it on their behalf), silent push notifications get progressively throttled and eventually stop being delivered entirely. This means schedule changes made by caregivers never reach the device, breaking the app's core value proposition. Uninstalling and reinstalling doesn't reset the throttling state Questions: Is there any way to reset or mitigate throttling for devices that legitimately need background updates but have low or no user interaction? This is an accessibility use case where the end user (child) doesn't interact with the app, but the app must reliably receive updates. Would switching to regular (visible) push notifications avoid this throttling even if the app is not interacted with? We already have Critical Alerts entitlement, but for regular updates we're worried that the "CRITICAL ALERT" banner will be too upsetting for the child. Is there any exception process for accessibility apps to change the way Critical Alerts are presented? For neurodivergent individuals, predictable routines are essential. When schedule updates don't reach their device, it can cause significant distress. This is a genuine accessibility need, not a "nice-to-have" feature. Any guidance from Apple engineers or developers who've solved similar challenges would be greatly appreciated. Thank you!

Hello, In our app we provide a button that initiates a phone call using tel://. For normal numbers, tapping the button presents the standard iOS confirmation sheet with Call and Cancel. If RTT is enabled on the device, the sheet instead shows three options: Call, Cancel, and RTT Call. However, when dialing a national emergency number, this confirmation dialog does not appear at all — the call is placed immediately, without giving the user the choice between voice or RTT. Is this the expected system behavior for emergency numbers on iOS? 
And if so, how does RTT get applied in the emergency-call flow — is it managed entirely by the OS rather than exposed as a user-facing option? Thanks in advance for clarifying.

Accessibility Voiceover is not treating navigation bar left button as first focused element. If we navigate from A->B then the focus is going to first element inside the B view not to the back button or B view's navigation title. If we post accessibility notification, in onAppear of B, focus is not shifting. but it will read back button first, and then read the B view's content item. it does't focus to back button in swiftUI. how should I do? if I want to focus on the navigation item back button or navigation title. my understanding is the system prioritizes the first focusable element in the view hierarchy. but The navigation bar (including the close button and title) is managed separately by the system. It is not part of the main view hierarchy, so it does not automatically receive focus unless explicitly set. if my thoughts are right, it seems a little strange. Why did you design it this way? Can you tell me your thinking? Thanks

I wrote this in the regular forums and they deleted it and told me to write it here because it was dealing with unreleased software. I read that Launchpad is disappearing in Tahoe and I have real concerns about that. For me, that is an accessibility issue. I have both memory problems and scanning problems. So having my apps organized into categories is extremely important to me. Just today I needed to find an app that I didn't remember the name of and I rarely use, but when I need it, it is important to me. Just to see if I could find it without launchpad, I scanned my applications folder and I couldn't find it. I went to launchpad and to the category I knew it was in and it was right there, easy for me to find. Please don't take away our organization options.

Is it possible to create a sandboxed app that uses accessibility permission? And if so, how do I ask the user for that permission in a way that is allowed by the App Store? Im creating a small menubar app and my current (rejected) solution is to create a pop-up, with link to Security &amp; Privacy &gt; Accessibility and the pop-up asks the user to manually add the app to the list and check the checkbox. This works in sandbox. Reason for rejection: "Specifically, your app requires to grant accessibility access, but once we opened the accessibility settings, your app was not listed." I know it's not listed there and it has to be added manually. But its the only solution I've found to this issue. Is there perhaps any way to add the app there programmatically? Im a bit confused since I've seen other apps in App Store that work the same way, where you have to add the app to the list manually. Eg. Flycut. :man-shrugging: I know about this alternative solution, and it's not allowed in sandboxed apps. It also adds the app to the accessibility list automagically: func getPermission() { AXIsProcessTrustedWithOptions([kAXTrustedCheckOptionPrompt.takeUnretainedValue():true] as CFDictionary). } Does anyone have a solution for this? Best regards, Daniel