@p-linnane Why did you set Tahoe required on the TG Pro cask?

Because that's what our tooling indicated on the last attempted version bump:

==> Downloading https://www.tunabellysoftware.com/resources/TG%20Pro%202.98.dmg
Already downloaded: /Users/runner/Library/Caches/Homebrew/downloads/bffce8b505a7da2fc874a89ad73aa85cb6d50199dcd0551c71f537405baf6d28--TG Pro 2.98.dmg
Error: 1 problem in 1 cask detected.
audit for tg-pro: failed
 - Upstream defined :tahoe as the minimum macOS version but the cask declared no minimum macOS version
tg-pro
  * Upstream defined :tahoe as the minimum macOS version but the cask declared no minimum macOS version
Error: Upstream defined :tahoe as the minimum macOS version but the cask declared no minimum macOS version
Error: `brew audit` failed!

Looking in the app bundle it does say 10.13, so there may be a bug in our check. We should be able to set it to :catalina, which is the oldest version of macOS that runs Homebrew.

Looking in the app bundle it does say 10.13, so there may be a bug in our check. We should be able to set it to :catalina, which is the oldest version of macOS that runs Homebrew.

I think that the Sparkle strategy also verifies the embedded minimum system version, which is macOS 26 for version 2.98:

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle"  xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>TG Pro 2.98</title>
		<link>https://www.tunabellysoftware.com/resources/sparkle/tgpro.xml</link>
		<description>Update to 2.98</description>
		<language>en</language>
        <item>
            <title>Version 2.98</title>
            <sparkle:minimumSystemVersion>26.0.0</sparkle:minimumSystemVersion>
            <description><![CDATA[
                <h3>Version 2.98</h3>
                <div style="font-size:13px">
                <ul>
                <li><strong>[New]</strong> Added full support for <strong>macOS 26 Tahoe</strong>, including an updated app icon and refreshed user interface.</li>
                <li><strong>[New]</strong> Migrated to the new Tunabelly Software licensing system for improved long-term compatibility with future macOS releases. This provides a more intuitive interface, smarter logic, and in most cases automatically migrates existing license keys without requiring interaction.</li>
                <li><strong>[Improvement]</strong> Enhanced activation handling to recognize the same hardware, preventing unnecessary use of additional activation slots.</li>
                <li><strong>[Improvement]</strong> When an order has been refunded, the license dialog now clearly shows that the license key is no longer valid, along with the refund date.</li>
                <li><strong>[Improvement]</strong> The main window title now displays the full Mac model name.</li>
                <li><strong>[Improvement]</strong> Reduced Sentry.io connections (used for crash reporting) so that TG Pro will only connect if a crash occurred during the previous launch, maintaining the policy of zero analytics or tracking.</li>
                <li><strong>[Fixed]</strong> Resolved an issue where duplicate SSD temperature sensors could appear on the 2025 Mac Studio M4 Max.</li>
                <li><strong>[Fixed]</strong> Corrected an issue where the last shutdown reason might not update properly on some Apple silicon models.</li>
                <li><strong>[Fixed]</strong> Fixed indentation of the separator menu item in the drop-down menu on recent macOS versions.</li>
                <li><strong>[Fixed]</strong> Addressed an issue on Mac mini M4 models where inactive GPU temperatures could display incorrectly as 1 °C.</li>
                </ul>
                </div>
            ]]>
            </description>
            <pubDate>Wednesday, October 1, 2025 21:00:00 -0500</pubDate>
            <enclosure url="https://www.tunabellysoftware.com/resources/TG Pro 2.98.dmg" sparkle:version="18302" sparkle:shortVersionString="2.98" sparkle:dsaSignature="MCwCFEtoPuNxpCZsS1U93YT71DJXDgfsAhQ9BgirpGlm6Mtm17JOWsMcHyiPwQ==" length="16992430" type="application/octet-stream" />
        </item>
        ...
	</channel>
</rss>

@AaronKelley You may want to reach out to upstream since their Sparkle feed is stating macOS 26 is required.

Looking in the app bundle it does say 10.13, so there may be a bug in our check. We should be able to set it to :catalina, which is the oldest version of macOS that runs Homebrew.

I switched it to :catalina, but the audit still fails with the same error.

@AaronKelley You may want to reach out to upstream since their Sparkle feed is stating macOS 26 is required.

I will do so.
[Edit] Support request filed with Tunabelly Software.

I think that the Sparkle strategy also verifies the embedded minimum system version, which is macOS 26 for version 2.98

For what it's worth, livecheck's Sparkle strategy only uses the minimumSystemVersion value to omit appcast items for prerelease macOS versions, so this seems to be an issue with the audit.

For what it's worth, livecheck's Sparkle strategy only uses the minimumSystemVersion value to omit appcast items for prerelease macOS versions, so this seems to be an issue with the audit.

True, but this value seems to also be read in the audit_min_os audit and is used if it is higher than the bundle version (https://github.com/Homebrew/brew/blob/43fa5f5e172c91b0642d1eb56435530969ba953f/Library/Homebrew/cask/audit.rb#L777).

this value seems to also be read in the audit_min_os audit and is used if it is higher than the bundle version

Ahh, thanks for the reminder. I was wondering what the audit was doing internally (i.e., why it wasn't respecting the macOS requirement from the app) but hadn't looked into it yet, so now I understand. Ironically, I modified part of that audit ~2 years ago but completely forgot about that behavior in the interim time 😆

I wonder if something like app_min_os = bundle_min_os || sparkle_min_os would be more appropriate (i.e., only fall back to the minimum macOS version in the appcast if the app doesn't specify a requirement). It doesn't feel correct for the appcast macOS requirement to override what's specified in the app, as the requirement in the app is what matters when it comes to running it on a given system. At the very least, this brew change would fix the audit issue and I think we could technically remove the depends_on macos: call if/when the audit change is merged.

Edit: I opened a brew PR for the aforementioned audit logic change: Homebrew/brew#20813

I see that some work is being done by @samford to change the audit behavior, such that the "Sparkle" requirement will not override the requirement from the app itself. I'm marking this PR in draft and I'll review as soon as that merges and I can get the audit to pass locally.

Thank you for your work here @AaronKelley
And thanks all for getting this worked out!

Here's the response that I got to my support request.

———

Hi Aaron,

Thanks for reaching out and for your feedback, I truly appreciate it!

The minimum OS version was listed as macOS 26 Tahoe as a temporary measure to enable us to roll out the update in waves. This was important since this update migrates users to our new in-house licensing system (from Paddle who were previously using) and we didn't want to overwhelm the servers with everyone migrating at the same time. I just changed the minimum to macOS 14 for the next wave and if everything is solid, I should be able to set it down to 10.13 tomorrow so everyone can upgrade.

I realize this isn't ideal for the home-brew cask and I apologize for the inconvenience. It will be set to the proper version soon and I hope this helps to explain why we did this.

Thanks,

Matt
Tunabelly Software