👍

I don't think this change will quite work. SUHost, and plenty of the other code, is not necessarily called from an Application that uses Sparkle.framework. For example, SUHost.m, SUPlainInstaller.m, and -installationPath method are called from Autoupdate.app (and maybe unit testing) which doesn't use Sparkle.framework, and won't have SUNormalizeInstalledApplicationNameKey or SUEnableAutomatedDowngradesKey set in its bundle info.plist.

SUHost is ideally tied to an input bundle provided in its initializer. Could we find the Sparkle bundle inside the specified host's bundle instead of using -[NSBundle bundleForClass:]?

I wasn't aware that Sparkle had an info.plist of its own. It's in Sparkle's Resources, and so kind of surprises me that it can be located.

Additionally, does SULocalizedString have to change now?

Oh, you're right. Thanks for catching that!

So I think solution to that would be to stop using Sparkle's own Info.plist - move these settings to compile-time constants (they're so unlikely to be changed that maybe even drop the setting completely)

For path of Autoupdate.app it will work, so I'd keep bundleForClass for security there (we really really don't want OS to pick executables from the unverified bundle).

I haven't fixed SULocalizedString, because it's used in too many places, and hopefully wrong strings can't do serious damage.

If we stop using sparkles info.plist we shouldn't even need or use sparkleBundle or SUBundleIdentifier.