Avoid relying on Sparkle 2.9-only filtering

This feed now depends on sparkle:hardwareRequirements to make Intel clients skip the first 0.15.2 item, but the app still pins Sparkle 2.8.1 in menubar/CctopMenubar.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved lines 17-20, and Sparkle documents this element as added in 2.9. Current Intel installations therefore won't understand the new restriction and can still select the first/latest arm64 item before reaching the x86_64 item, so the hotfix does not actually protect the affected clients unless Sparkle is upgraded first or the appcast is split/ordered in a 2.8-compatible way.

Useful? React with 👍 / 👎.

I’d treat that review as partly valid, but overstated.

The compatibility concern is fair because the previous verification did not actually compile the app against Sparkle 2.8.1, and it leaned partly on
current Sparkle docs, which may reflect newer Sparkle behavior. So the answer “yes, it works” was stronger than the evidence supported.

That said, the specific Sparkle APIs in SparkleUpdater.swift do look compatible with Sparkle 2.x, including 2.8.1: SPUStandardUpdaterController,
SPUUpdaterDelegate, SPUUserUpdateChoice, and automaticallyDownloadsUpdates are not the risky part.

The more important question is the appcast behavior:

• Sparkle appcast update selection is item-based.
• sparkle:hardwareRequirements is an SUAppcastItem property, not an enclosure-level property.
• So splitting arm64 and x86_64 into separate same-version entries is conceptually right.
• The arm64 item must be first, because Apple Silicon can technically run x86_64 apps under Rosetta, and we want Sparkle to pick the native arm64 item
  when both are otherwise applicable.

The current appcast shape:

looks reasonable for Sparkle 2.8.1.

What I would not claim without more evidence is “definitely works end to end.” To close that properly, run a real Xcode build with the resolved
package and ideally test update selection from an Intel machine or x86_64 runtime. The strongest local verification would be:

xcodebuild -resolvePackageDependencies -project menubar/CctopMenubar.xcodeproj
xcodebuild build -project menubar/CctopMenubar.xcodeproj -scheme CctopMenubar -configuration Debug -derivedDataPath menubar/build
CODE_SIGN_IDENTITY="-"
./scripts/validate-appcast.sh

So: the review comment is correct to question the confidence level, but I don’t see evidence that the fix is actually incompatible with Sparkle 2.8.1.

Sources checked: Sparkle SUAppcastItem docs show hardwareRequirements is item-level, and Sparkle SPUStandardUpdaterController docs show the updater
APIs used by the app exist in Sparkle 2.x.
https://sparkle-project.org/documentation/api-reference/Classes/SUAppcastItem.html
https://sparkle-project.github.io/documentation/api-reference/Classes/SPUStandardUpdaterController.html

So I coded this thing with Codex and from what I can see in their documentation when I let Codex also check the review comment it seems like the item has support for that in Sparkle 2.8.1.

Looking at sparkle-project/Sparkle#2797, I don't think it's supported in v2.8.1.
So for this to work properly, we should also bump sparkle to v2.9.0+

Good catch, I totally missed that the documentation (https://sparkle-project.org/documentation/api-reference/Classes/SUAppcastItem.html) says "Sparkle 2.9.1 Docs".
I was looking for something like "Added in ...." where the element but thought it had been there forever as it was nothing like that pointed out.

Do you think it would be any worries about upgrading to 2.9.1 ?

Seems like maybe a good idea is to have two different xml-files for <= 2.9 and >= 2.9 as it might break update in older versions. Though as it is an xml I feel it should just ignore things xml-tags it does not understand.
But maybe make a appcast29.xml or something like that for the future apps for a while? Or do you have statistics on app versions in the wild @st0012 ?

How can it break older versions?