Looping back to mark this as resolved. Not sure when it was fixed, but it doesn't repro on iOS 26.2.1 (23C71).

Since I hadn’t received replies yet, I did some additional research. I had Gemini do a deep dive based on my original post and it suggested that StoreKit 2 might support a cleaner time-limited trial → one-time purchase flow without the $0 IAP step. Here's the (lengthy) report, including proposed solution towards the end: https://gemini.google.com/share/099cf0140311 That initially seemed promising, but App Store Review Guideline 3.1.1 still explicitly calls out the $0 non-consumable “XX-day Trial” approach. While the StoreKit 2 method seems to follow the spirit of the guideline (if clearly communicated), it’s not clear whether it’s actually allowed—and I’m not willing to risk App Review rejection after investing significant work. So I’m hoping for clarification from Apple: Is the $0 non-consumable IAP still the recommended approach in 2026? Are alternative StoreKit 2–based trial → one-time purchase flows allowed? Would really appreciate updated guidance here. 🙏

@DTS Engineer Thanks for the suggestion. I did try hiding the system back button and replacing it with a custom toolbar button. However, that disables the left-edge swipe gesture, which felt like a worse tradeoff. Most people expect swipe-to-go-back, so a mismatched toolbar button seemed like the lesser issue. Unless there’s a way to preserve the swipe gesture while using a custom back button, I’ll just hope for a fix.

This seems to have been fixed in macOS 26.2 (25C56)! 🙌

@DTS Engineer Thanks for letting me know! In the meantime I found this workaround: custom SF symbols will center correctly when the button label is declared like this: ToolbarItem { Button(action: { }) { Label { Text("More") } icon: { Image("ellipsis.badge.90.10") } } } But that’s a bit cumbersome. It’d be better if worked with any valid button declaration.

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.

BTW, if anyone knows how to force a specific size for an inline image in a post, I’d love to know! Whenever I include high-DPI images, I set the width and height so they don’t display huge like the ones above—but it never seems to work. Is this a forum software bug, or am I missing something?

Turns out that there's a setting to turn this off, so probably something that shouldn't be suppressed by the developer. The setting can be found in: Settings › Accessibility › VoiceOver › VoiceOver Recognition › Text Recognition Screenshot

Thanks @Etresoft, that's good to know! Though it’s a bit disappointing that we have to rely on a third-party tool for this. I filed FB20741470 in hopes they eventually fill in the missing availability. 🤞

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) } } } }

As a workaround, I'm temporarily using ellipsis.circle.badge: But this isn't the recommended More icon anymore. Apple now suggests the standard ellipsis for "More": The problem is, there’s no badged version—so I need a custom "combined" symbol that stays vertically centered, with or without the badge.

Looks like it's still fixed in iOS 26 Dev Beta 5/Public Beta 2 (23A5308g). Hopefully it stays that way. I’ll mark my last update as the answer.

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.

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

Looks like this is fixed—the animation now works as expected in iOS 26.0 Dev Beta 4 (23A5297i) and Public Beta 1 (23A5297m). I’ll wait for the next set of betas before calling it fully solved, but so far it's promising.