Skip to content

Fix Wireshark Sparkle updates selecting Intel builds on Apple Silicon#563

Open
moreaki wants to merge 1 commit into
mangerlahn:mainfrom
moreaki:fix/wireshark-arm-sparkle-feed
Open

Fix Wireshark Sparkle updates selecting Intel builds on Apple Silicon#563
moreaki wants to merge 1 commit into
mangerlahn:mainfrom
moreaki:fix/wireshark-arm-sparkle-feed

Conversation

@moreaki

@moreaki moreaki commented Mar 15, 2026

Copy link
Copy Markdown

Summary

This fixes Wireshark/Stratoshark Sparkle updates resolving the wrong architecture-specific feed on Apple Silicon, which could lead to an ARM install being updated to the Intel build.

Closes #454.

Root cause

Latest currently reads SUFeedURL directly from the target app bundle and treats it as authoritative.

For Wireshark and Stratoshark, the bundled macOS plist ships a static SUFeedURL that points to the x86-64 appcast path. Their own updater code then rewrites that URL at runtime based on the actual build architecture (x86-64 vs arm64).

That means external Sparkle consumers like Latest can end up using the Intel feed for an Apple Silicon install even though the installed bundle itself is ARM.

There was also a secondary precision issue in our Sparkle path: we resolved bundles by bundle identifier during check/install instead of preferring the exact on-disk bundle URL selected by the user.

Changes

  • detect Wireshark/Stratoshark architecture-specific feed URLs and rewrite the feed path to match the installed bundle's executable architecture
  • prefer Bundle(url:) over Bundle(identifier:) when creating Sparkle updaters for both checking and installing
  • add regression coverage for the Wireshark ARM feed rewrite path

Verification

  • xcodebuild build -project 'Latest.xcodeproj' -scheme 'Latest' -destination 'platform=macOS' CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY=''

I also added a focused XCTest for the feed rewrite logic. I could not execute the test target successfully in this local environment because Latest Tests failed to resolve the private framework module dependencies CommerceKit and StoreFoundation, but the app build itself succeeds.

Upstream

I opened an upstream Wireshark issue about the bundled Sparkle metadata always shipping an x86-64 SUFeedURL:

@rgoldberg

Copy link
Copy Markdown

I haven't read through all the code, but wouldn't it make sense to use the architecture of the actual app for all apps, not just for Wireshark/Stratoshark, in case other apps behave the same way?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wireshark ARM gets updated to Intel

2 participants