This still appears to be an issue on iOS 26 and macOS 26. For a control inside a navigation-bar ToolbarItem, the .buttonStyle(...) workaround is still required. In my case, the tip reaches .available and the isPresented binding flips to true, but nothing is rendered unless the enclosing control has an explicit button style. Attaching .popoverTip(...) to the inner Label alone is not sufficient; the explicit button style is the important part. This works, and removing .buttonStyle(.plain) breaks presentation: Toggle(isOn: $isOn) { Label("Voice", systemImage: "mic") .labelStyle(.iconOnly) .popoverTip(tip, isPresented: $isPresented, arrowEdge: .top) } .buttonStyle(.plain) .toggleStyle(.button) I’m also seeing a separate issue with the popoverTip(_:isPresented:...) overload on iOS 26/macOS 26: if the modifier remains attached while the tip value is nil, or after the tip is dismissed/no longer eligible, an empty popover shell can briefly appear and dismiss itself. This is especially visible on macOS. The only reliable workaround I’ve found is to remove the .popoverTip(...) modifier from the view hierarchy entirely once the tip is no longer eligible, rather than passing nil: if tipIsEligible { label.popoverTip(tip, isPresented: $isPresented) } else { label } I’ve worked around both issues as best I can, but wanted to leave an update here for anyone else who lands on this thread while debugging TipKit + toolbar presentation, as I did.

Quick update: this is still a problem in iOS 27.0 (24A5355q).

As requested, I tested this again in iOS 26.5 (and 26.6 (23G5028e)) and .disabled toolbar buttons still reacts to taps.

Thanks, @DTS Engineer. I haven’t tried that exact workaround, but I expect it works. Defining the label differently also avoids the issue with less code, so there are multiple workarounds. The bigger issue is the tap feedback. Tapping outside the SF Symbol but inside the visible button can show the normal bounce animation without triggering the action. If the action doesn’t run, the button shouldn’t look like it accepted the tap. This feels related to another issue I reported, where a disabled button still bounces like an active button:

Quick follow-up… This made it through App Review and is now live. I refined the paywall screens a bit before release: It's been out a couple weeks now. Downloads picked up after switching from paid upfront, but unfortunately no increase in sales yet.

@akashr Thank you! 🙏 This saved me from wasting more time on this. I’d already burned a couple hours trying to figure out why a symbol that clearly supports variable value in the SF Symbols app, wasn’t working in code. I really wish Apple’s docs included more real-world samples. Seems like many symbols do need .symbolVariableValueMode(.draw) for this to work.

Not sure when it changed, but the iOS Builds page now seems to keep the Build Uploads section collapsed, surviving page reloads and navigating away and back. To whoever fixed this: Thank you, thank you! 🙏

Well, now it's in the hands of App Review. We'll see how this goes!? 😅

I made a few wording tweaks, so here’s the latest:

@DTS Engineer, thanks for the reply. 🙏 That’s right, I used the local test environment only to capture those screenshots. The build currently in TestFlight does use sandbox. I’m asking about the text of the two paywalls. The guidelines are unclear for this corner case, and there aren’t many up-front paid apps with trials to reference. So, to clarify: Does the paywall text look acceptable, or should I change anything before submitting to App Review?

Since I never got an answer and my app has buttons that resize during a drag, I removed the .buttonStyle(.glass) modifier for now. Not a huge loss, but it’d be nice if glass button backgrounds didn’t change based on size. If they do need to change, the transition should be gradual so it animates smoothly with a size change.

I spent most of last week implementing the $0 non-consumable IAP trial and Lifetime Unlock flow with StoreKit 2, and it’s now out on TestFlight. Here’s what the current flow looks like: I’m planning to submit this soon, but I’m still nervous about App Review and customer confusion. I want to make sure the trial terms, $0 purchase, and Lifetime Unlock are clear and not misleading, especially since this is an obscure workaround and the guidelines aren’t very specific. Are there any glaring issues with either paywall?

@App Store Commerce Engineer, thanks for the guidance in the accepted solution. 🙏 One follow-up question: With the two non-consumable approach, is it acceptable to offer a limited in-app preview before presenting the free trial IAP? The trial would still be the $0 non-consumable, with duration based solely on the transaction date. The preview wouldn’t be described as the trial or used to calculate trial time. In other words, are new customers required to see the free trial IAP before any functionality is available, or can it be presented contextually after a brief preview?

Since I wasn’t able to get an answer here, I emailed Apple Developer Technical Support. Here’s their response… Apple DTS wrote: Yes this is the current approach to allow free app download with functionality gated by a free and paid non-consumable IAP purchase. With originalPurchaseDate the users clock would start immediately upon purchase time. That is a reliable signal but worth noting that purchase event is not when a user has opened or started to use your app or service. For that reason a free non-consumable enables the users to know the terms and start the clock when they are ready.

[deleted]