Post

Replies

Boosts

Views

Activity

Reply to popoverTips don't display for toolbar menu buttons in iOS 26.1
The only workaround I’ve found is to use a text-only menu button label. That lets the tip display correctly on iOS 26 (see below). This release has (or had) quite a few toolbar-related bugs and most seem related to icon-only buttons. Along with this issue, here are three others I've reported: issue 1, issue 2, and issue 3. In my app, I've left the icon-only button hoping it gets fixed soon. The actual tip I display is not critical, and a text-only label just looks "off"—especially since Apple officially designates the ellipsis symbol as the standard for More (Apple Design link). Workaround Starting with the code in the first post, just change the Label() in the ToolbarItem to Text() like this: ToolbarItem(placement: .topBarTrailing) { Menu { Button("Dismiss", role: .cancel) { } Button("Do Nothing") { } } label: { Text("More") } .popoverTip(tip) } Screenshot Description: iPhone simulator running iOS 26.1 showing a popover labeled Menu Tip. The popover beak is pointing to a toolbar button labeled More.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Nov ’25
Reply to .disabled() doesn't VISUALLY disable buttons inside ToolbarItem on iOS 26 devices
It looks like it does have to do with how the button's label is declared. Here's my post about another bug where a button's hit target shrinks based on its label declaration: SwiftUI Button with Image view label has smaller hit target So if I change this sample code to use a label: closure with a Label() view, the button does appear gray when disabled. Interestingly though, it still responds to taps with a bounce animation, even though the action isn’t triggered. That’s still inconsistent with how disabled buttons behave outside of a toolbar. Also, the button grows slightly wider when disabled. Code var body: some View { NavigationStack { VStack { Button{ print("Body button tapped") } label: { Label("Body Button", systemImage: "checkmark") } .labelStyle(.titleOnly) .buttonStyle(.borderedProminent) .disabled(isButtonDisabled) Toggle("Disable buttons", isOn: $isButtonDisabled) Spacer() } .padding() .navigationTitle("Device: \(osTitle)") .navigationBarTitleDisplayMode(.large) .toolbar { ToolbarItem { Button { print("Toolbar button tapped") } label: { Label("Toolbar", systemImage: "checkmark") } .labelStyle(.titleOnly) .buttonStyle(.borderedProminent) .disabled(isButtonDisabled) } } } }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Oct ’25
Reply to .disabled() doesn't VISUALLY disable buttons inside ToolbarItem on iOS 26 devices
Thanks for the reply. Even with that button declaration, it still won't work when the label: closure contains a Text() element like this: Code Button { print("Checkmark button tapped") } label: { Text("Checkmark") } .buttonStyle(.borderedProminent) .disabled(isButtonDisabled) Recording As I mentioned in my original post, I already filed this as FB19313064. But I’ll update the report to clarify that it only affects buttons that don’t use the label: closure with a Label() element.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Aug ’25
Reply to .disabled() doesn't VISUALLY disable buttons inside ToolbarItem on iOS 26 devices
Changing to .plain, does make make the .disabled() modifier work on an iOS 26 device (toolbar button visually becomes "grayed out"): But I’m trying to match the behavior of stock iOS 26 apps like Reminders and Calendar, where the checkmark/save button is disabled when there are no changes, then .borderedProminent when there are. What's the best way to do this? 👇 Reminders on iOS 26 Calendar on iOS 26
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Aug ’25
Reply to Verifying braille output in an iOS app without a physical braille device?
@Systems Engineer, I'm willing to drop back to UIKit if it solved the VoiceOver/braille display issues. Any pointers to an example UIKit implementation of AXMathExpressionProvider? There’s not much to go on in that doc or its related topics. I even tried deep-research mode in both Gemini and Claude Opus. Gemini flat-out gave up, while Claude surfaced this after reviewing 297 sources: The AXMathExpressionProvider protocol does not exist in the current iOS/SwiftUI accessibility APIs. After extensive research across Apple’s documentation, developer forums, GitHub repos, and WWDC sessions, there’s no evidence this protocol exists in the current iOS SDK. It may be hypothetical, planned for the future, or confused with other accessibility APIs.
Jul ’25