I find the inspector, file navigator, issue navigator, etc. all hard to read. Is there a way to increase the size of these texts without changing all of the text on my machine?

Hi, I want to detect if there is a fullscreen window on each screen. _AXUIElementGetWindow and kAXFullscreenAttribute methods work, but I have to be in a non-sandbox environment to use them. Is there any other way that also works? I don't think it's enough to judge if it's fullscreen by comparing the window size to the screen size, since it doesn't work on MacBook with notch, or the menu bar is set to 'auto-hide'. Thanks.

User might be caught in a Guided Access page with error like this when they trying to leave Guided Access. Please pardon me for shotting a photo with phone to show this condition, because I can't even get a screenshot with home button and power key pressed together. I can't lock the screen with power key or by the magnet sensor, can't get back home page with home button. The ways to exit is waiting for the exit button might could use, or the screen shutdown, or enforce the device to shutdown. After exit the Guided Access without rebooting the system, the Guided Access would be freezed for minutes, noticing the Guided Access can't be used. In iPadOS 26, since, I can prove confidently, 26.5beta1 even earlier, could discover that issue. The problem could happen several times in a day. I have raised that issue since April 25th and the ID is FB22608734, which has more than 10 similar reports. To say something beyond the issue, actually I guessed that my device, iPad mini 5th, might can't get the update of iPadOS 27, so I hoped that Apple Developer Teams could at least fix those annoying problems. Actually there is a long list in Chinese with problems summarised by some Chinese User I waited for a long time for a miracle in WWDC 27. But that's a miracle.

Environment: Xcode 26.5, macOS Tahoe 26.5.1 (MacBook Pro, Apple M4 Max). As a blind developer working in Xcode with VoiceOver only, I'd like to report accessibility issues that make it hard to complete properly signed and entitled apps using VoiceOver alone. Issue: The "Signing & Capabilities" tab is not directly accessible. The "Signing & Capabilities" tab in the target editor is central to app configuration (team selection, capabilities, provisioning profiles), but there is no dedicated keyboard shortcut to reach it. The path requires many steps: Cmd+1 to focus the navigator, selecting the project file with the arrow keys, activating it with Return, switching to the central editor area, selecting the target, and finally locating the tab in the top bar. Specific VoiceOver problems: When the project file is activated with VoiceOver, focus often lands inside the inline rename field instead of opening the project editor as expected. The toolbar containing the editor tabs (General, Signing & Capabilities, Resource Tags, Info, Build Settings, Build Phases, Build Rules) cannot reliably be focused with VoiceOver, which prevents direct tab switching from the keyboard. Impact: A routine task such as adding a capability requires a long VoiceOver sequence that must be repeated on every visit, plus the cognitive load of remembering the exact tab order. Suggested improvements: Provide a direct keyboard shortcut for the "Signing & Capabilities" tab, and ideally for each target editor tab (for example Cmd+Option+1 through Cmd+Option+7). Ensure that activating the project file in the navigator opens the project editor by default; renaming should require an explicit second key press (Return on an already selected item, consistent with Finder). Ensure the editor tab bar can be reached and traversed with VoiceOver, for example via Tab or Ctrl+Tab.

On tvOS, third-party apps cannot read number key presses from a connected keyboard or remote (except inside a text field). There is also no HDMI-CEC API. Because of this, a live-TV / IPTV app cannot let the user simply type a channel number to change channels. This excludes a large group of users, especially older people. They have used numbered channels for their whole lives — they remember that a given number is a specific channel and just want to press that number to get there. It is the simplest and most familiar way for them to use a TV. Making them navigate an on-screen grid with the Siri Remote instead is much harder and unfamiliar for them. Please give apps a way to support numeric channel entry on tvOS — for example by letting apps receive number key presses (0–9) from a connected Bluetooth keyboard/keypad without forcing a text field, or by exposing the numeric keys from the TV's own remote via HDMI-CEC. Other TV platforms already pass number keys from the remote to apps, so this works for them today. tvOS does not, which leaves these users without a basic, expected way to use their TV.

I would like to implement a focus-based Menu-Bar command in my SwiftUI iPadOS app, or react to key command while certain elements are focused. Traditionally, this requires using @FocusedValue and focusable() and focused, however, it appears that setting a @FocusState on macOS will work, but setting a @FocusState on iPadOS will never work. How can this API work and support MenuBar commands and keyboard inputs? It kind of has an accessibility impact as well. Not all users are going to know, or want to turn on "full keyboard control" for basic interactions. Here's a small sample that doesn't appear to focus on iPadOS: struct FocusableTestView: View { @FocusState private var isRectFocused: Bool var body: some View { VStack { // This text field should focus the custom input when pressing return: TextField("Enter text", text: .constant("")) .textFieldStyle(.roundedBorder) .onSubmit { isRectFocused = true } .onKeyPress(.return) { isRectFocused = true return .handled } // This custom "input" should focus itself when tapped: Rectangle() .fill(isRectFocused ? Color.accentColor : Color.gray.opacity(0.3)) .frame(width: 100, height: 100) .overlay( Text(isRectFocused ? "Focused" : "Tap me") ) .focusable(true) .focused($isRectFocused) .onTapGesture { isRectFocused = true print("Focused rectangle") } // The focus should be able to be controlled externally: Button("Toggle Focus") { isRectFocused.toggle() } .buttonStyle(.bordered) } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center) } }

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected — calling AXIsProcessTrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvent.tapCreate(tap: .cgSessionEventTap, place: .headInsertEventTap, options: .listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list 3. Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preference.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15 (Sequoia), signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable — this is for audio, not HID). Question: Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected - calling AXIsProcesstrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvet.tapCreate(tsp: .cgSessionEventTap, place: .headInsertEventTap, options: listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preferences.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15, signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable). Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

Our app supports Full Keyboard Access. When an element is focused, the system-drawn FKA focus indicator (the ring/overlay) sits over the UI component. This overlay drops the content's colour contrast below the WCAG 2.1 minimums — 4.5:1 for text (1.4.3) and 3:1 for UI components and focus indicators (1.4.11) — causing the focused state to fail accessibility audits. Is there a supported way to completely remove this focus overlay on a view without breaking FKA keyboard navigation or VoiceOver?

On iOS 26 (26.0–26.5), a rectangular region in the lower half of the screen sometimes does not render while the content underneath remains laid out and interactive — scrolling works, hit testing succeeds, and rows visibly emerge from behind the floating tab bar as you scroll. This is a render-server / compositor gap, not a layout or safe-area issue. We see it on both UIKit and SwiftUI scroll surfaces inside the same UITabBarController: UIKit: UICollectionView with UICollectionViewFlowLayout (sectionInsetReference = .fromSafeArea) SwiftUI: List(.plain) nested in TabView(.page) inside a UIHostingController Confirmed on iPhone 16 Pro, iPhone 17 Pro, iPhone 13 Pro Max. Community threads (linked below) report the same symptom in Messages, Notes, Safari, Mail, and the App Store. Questions for Apple Is this acknowledged as an OS-level regression, and is a fix targeted for an upcoming iOS 26.x release? Is there a deterministic repro? We've tried background/foreground cycles, push notifications mid-scroll, tab switches during inertia, lock/unlock, orientation flips, simulated memory warnings, layout-invalidation storms, and trait-collection cycles — none reliably trigger it on our test devices. Is there a developer-side mitigation (e.g. avoiding specific UIVisualEffectView / Glass configurations, opting out of a rendering optimization) until a system fix lands? Is there a runtime signal on CALayer or UIScrollView we can inspect to detect this gap state and force a recovery (tile redraw, backing-store discard, etc.)? Notes We cannot reproduce locally. Affected users hit it organically; once it appears it persists across re-layout until the view controller is torn down. Community reports consistently mention Reduce Transparency being enabled on affected devices, and toggling it off clears the issue for many. In our own testing, RT alone is not sufficient to trigger the bug — it appears to be a contributing condition rather than the trigger. References: Apple Discussions: https://discussions.apple.com/thread/256182149 Reddit r/ios (multiple system apps): https://www.reddit.com/r/ios/comments/1nlzn7f/some_apps_cutting_off_half_the_display/ https://www.idownloadblog.com/2026/03/23/webpage-content-cutting-off-safari/

input[type=number] mapped to AXTextField instead of AXIncrementor/UIAccessibilityTraitAdjustable in Safari (macOS and iOS). According to ML-AAM 1.0, <input type="number"> is required to map to the ARIA spinbutton role, but it is not being mapped as expected on WebKit (macOS and iOS) to the platform accessibility APIs: the element is reported as AXTextField on macOS and lacks UIAccessibilityTraitAdjustable on iOS. As a consequence, VoiceOver announces the element as a textfield rather than a spinbutton, does not increment with arrow keys on macOS, and does not respond to the swipe up/down gesture on iOS. This affects every <input type="number"> on the web (quantity steppers, age inputs, year pickers, etc). Authors are currently forced to work around it by reimplementing the spinbutton with role="spinbutton", which force the authors to emulate the native HTML solutions with JavaScript, contradicts the First Rule of ARIA Use and presents another interaction issues in WebKit (will create an issue about this and update this post later). References: HTML-AAM 1.0, input type=number: https://www.w3.org/TR/html-aam-1.0/#el-input-number ARIA 1.2, spinbutton role: https://www.w3.org/TR/wai-aria-1.2/#spinbutton First Rule of ARIA Use: https://www.w3.org/TR/using-aria/#firstrule Reproduction: https://codesandbox.io/p/sandbox/beautiful-hofstadter-vn7nj3 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8" /> <title>spinbutton techniques</title> </head> <body> <main> <h1>Spinbutton pattern</h1> <section aria-labelledby="html-solution"> <h2 id="html-solution">HTML solution: spinbutton</h2> <label for="qty">Quantity</label> <input id="qty" type="number" min="0" max="10" value="1" /> </section> </main> </body> </html> Expected behavior: AX role on macOS: AXIncrementor (mapped from spinbutton) AX trait on iOS: UIAccessibilityTraitAdjustable VoiceOver on macOS announces "[value], [name of the input], stepper" and then "you are currently on a stepper. To begin interacting with this stepper, press Control-Shift-Down Arrow", after pressing the combo should announce "in stepper" and inmmediately should announce "you are currently in a stepper. To decrease this value, press Control-Option-Down Arrow. To increase this value, press Control-Option-Up Arrow. to exit this stepper, press Control-Option-Shift-Up Arrow" One-finger swipe up/down on iOS increments/decrements the value Actual behavior on Safari: AX role on macOS: AXTextField AX trait on iOS: standard textfield, no Adjustable VoiceOver announces "[value], insertion at the beginning/end of the text, [name of the input], number field" and then "you are currently on text field. To enter text in this field, type". Omitting the native functionality of a spinbutton One-finger swipe up/down on iOS does nothing Cross-platform comparison (same HTML, same spec): Firefox + NVDA on Windows: Chrome + NVDA on Windows: same as Firefox Safari + VoiceOver on macOS: broken as described above Safari + VoiceOver on iOS: broken as described above Environment: macOS: maOS Tahoe 26.4.1 Safari: 26.4 (21624.1.16.11.4) iOS: iOS 26.4.2 Device: iPhone 15 VoiceOver: default settings

I am developing an iOS app using ActivityKit Live Activities with interactive buttons based on LiveActivityIntent. The implementation works correctly: LiveActivityIntent.perform() executes correctly. The Live Activity updates visually. MediaPlayer actions are triggered successfully. The app does not open when tapping the buttons. Repeated taps correctly update the Live Activity state. However, I observed a behavior difference on the Lock Screen: Now Playing controls keep the Lock Screen awake while interacting repeatedly. Apple Stopwatch/Timer controls also keep the Lock Screen awake while interacting. My app’s Live Activity fades to black after around 5–7 seconds even while the user continues tapping the Live Activity buttons. I also tested a third-party timer app with Live Activity buttons and observed the same fade-to-black behavior. I additionally tested: repeated Activity.update(...) calls after each tap; visual state updates after every interaction; multiple consecutive interaction updates. None of these prevented the Lock Screen from dimming/fading to black. So my question is: Is this expected behavior for third-party Live Activities using LiveActivityIntent? Or is there any recommended way to keep the Lock Screen interaction session active while the user is continuously interacting with Live Activity buttons? I am especially interested from an accessibility perspective, because short interaction windows can make repeated Lock Screen interactions more difficult for users with motor impairments or slower interaction patterns.

I have already filed a bug report with a sample project via Feedback Assistant: FB22760723 When presenting a UIViewController using UIModalPresentationFormSheet alongside UISheetPresentationController with a small custom detent (e.g., around 300pt height), VoiceOver spatial swipe navigation breaks. The user is unable to swipe left or right to navigate sequentially through the accessible elements inside the sheet. Accessibility Inspector reveals that the focus seems to get trapped by the background layer (UIDimmingView / "dismiss popup"). If the sheet is taller (e.g., 600pt), the issue does not occur and swipe navigation works as expected Steps to Reproduce: Run the attached sample Objective-C/UIKit project. Turn on VoiceOver. Tap the “Open transparent modal” button to present the modal with UIModalPresentationOverFullScreen presentation. Tap the "Open form sheet" button to present the sheet (configured with a custom 300pt detent). Attempt to swipe right using VoiceOver to navigate to the next element (e.g., from the title label to the buttons). Expected Results: VoiceOver should smoothly navigate through the sequential accessibility elements inside the sheet's view hierarchy, respecting the bounds of the modal sheet. Actual Results: VoiceOver gets stuck. The swipe right/left gestures fail to move focus to the next element inside the sheet. Instead, focus often escapes to the background or doesn’t change completely.

I found difficulty interacting with close button on placement inside Health app on newest iOS. Steps to reproduce: Open Health app Scroll to "Get more from health" Try to focus on close button on any box like "Set Up your medical ID" Focus is on the whole box and there is now way to move to close button. After hitting space it opens next screen. Solving this issue might help with similar issue in our app.

When using Full Keyboard Access some content in Reminders app is not accessible. Steps to reproduce: Open Reminders app Open one of the lists with few (ex. 4) records. Try to check reminder. Issue: Navigating with keyboard focuses on whole row, using arrows left/right doesn't move to check control. Using space on whole row activates textfield, then still left/right arrow does not move outside textfield. Tested on iPhone 13 mini with iOS 26.4 using Magic Keyboard. Solving this issue might help with similar issues in our app.

When using Full Keyboard Access on iPhone in Photos app some interactive content is not available to enter. Steps to reproduce: Open Photos app Go to Collections tab Go to memories Try to select any memory playlist Whole scroll view is selectable as one element and using space is not making any difference. Using tab goes to navigation controls. Tested on iPhone 13 mini with iOS 26.4 using Magic Keyboard.

Hello, i'm currently working on improving accessibility in my app using the built-in Xcode tool, Accessibility Inspector. For the most part, it works well — it correctly displays warnings about missing button labels or insufficient touch target sizes. However, it does not seem to handle certain cases properly, particularly dynamic fonts. Here is the approach I’m using for dynamic fonts: static func getDynamic(font: FontType, size: CGFloat, textStyle: UIFont.TextStyle) -> UIFont { let customFont = UIFont(name: font.rawValue, size: size)! return UIFontMetrics(forTextStyle: textStyle).scaledFont(for: customFont) } label.adjustsFontForContentSizeCategory = true My labels are configured with: numberOfLines = 0 no fixed height constraints This allows them to expand as needed without clipping. I have tested this visually on multiple devices, and everything appears to work correctly — fonts scale as expected, and text is not truncated. However, Accessibility Inspector still reports issues related to dynamic type and, in some cases, text clipping. On iOS 18, approximately 40% of the fonts configured this way still trigger warnings about missing dynamic type support, even though they scale correctly. On iOS 26+, the issue becomes consistent — every font in the app triggers this warning. There are no cases where the inspector passes without reporting a problem, despite the UI behaving correctly in practice. So my question is: Is there a known way to resolve this? Could this be an issue with Apple's tools? If so, is there any information on when it might be fixed?

I'm developing an iOS application that relies on peer-to-peer discovery and connection using Bluetooth. The expected behavior is: Two iOS devices with the application installed. Both users marked as "visible". When within Bluetooth range, the devices should discover each other and establish a connection. However, the problem occurs when: The application is in the background (minimized) OR The device is locked (screen off). In these states: The devices can no longer be detected. The search returns no nearby devices. Connection could not be established. ChatGPT: What you want to do probably runs into a structural limitation of iOS — it's not a bug. And iOS: severely limits background BLE scanning. reduces advertising frequency. may even stop completely depending on the state (lock screen). In other words: 👉 iPhone was not designed to function as a "continuous radar" between background apps. Apps that do something similar (like AirDrop or Find My): use Apple's private or privileged APIs or combine BLE + Wi-Fi + Ultra Broadband. i need help : /

When applying the .accessibilityIdentifier(_:) modifier to a SwiftUI TextField, the identifier is correctly added to the SwiftUI Accessibility Tree (visible in Accessibility Inspector), but it is not assigned to the accessibilityIdentifier property of the underlying UITextField instance. This causes issues for developers who monitor global notifications, such as UITextField.textDidChangeNotification. When a notification is received, the object (the UITextField) has a nil identifier, making it impossible to programmatically determine which specific text field triggered the event. Steps to Reproduce: Create a SwiftUI view containing a TextField. Apply .accessibilityIdentifier("TargetTextField") to that TextField. Set up an observer (via NotificationCenter or onReceive) for UITextField.textDidChangeNotification. Run the app and type into the text field. Inspect the accessibilityIdentifier property of the UITextField object provided by the notification. Expected Result: The UITextField.accessibilityIdentifier should be "TargetTextField". Actual Result: The UITextField.accessibilityIdentifier is nil.

[Submitted as FB22200608] With Increase Contrast turned on, the selected row highlight in a List behaves inconsistently between light and dark appearance on iPad. In light appearance the blue selection highlight correctly becomes darker, but in dark appearance it becomes lighter instead. The text contrast ratio drops from about 3:1 to about 1.5:1, well below accessibility guidelines. This reproduces both in the simulator and on a physical device. The sample uses a standard SwiftUI List inside NavigationSplitView with built-in selection styling. No custom colors or styling are applied. REPRO STEPS Create a new Multiplatform project. Replace ContentView with code below. Build and run on iPad. Select an item in the list. Turn on Dark appearance (Cmd-Shift-A in Simulator). Turn on Increase Contrast (Cmd-Control-Shift-A in Simulator). Observe the selected row highlight. ACTUAL In light appearance, the blue selection highlight becomes darker when Increase Contrast is on, improving contrast as expected. In dark appearance, the blue selection highlight becomes lighter when Increase Contrast is on, reducing contrast between the selection background and the white text. EXPECTED Increase Contrast should consistently increase contrast. In dark appearance, the selection highlight should become darker—or otherwise increase contrast with the foreground text—not lighter. SAMPLE CODE struct ContentView: View { @State private var selection: String? var body: some View { NavigationSplitView { Text("Sidebar") } content: { List(selection: $selection) { Text("Item One") .tag("One") Text("Item Two") .tag("Two") } } detail: { if let selection { Text(selection) } else { Text("Select an item") } } } } SCREEN RECORDING CONTACTS The Contacts app behaves correctly. When Increase Contrast is turned on, the selection blue becomes darker, improving contrast. PASSWORDS The Passwords app, however, exhibits the issue. With Increase Contrast turned on, the selection blue becomes lighter instead of darker, reducing contrast.