sparkle-project/sparkle

A software update framework for macOS

Sparkle 2

Secure and reliable software update framework for macOS.

Sparkle 2 adds support for application sandboxing, custom user interfaces, updating external bundles, and a more modern architecture which includes faster and more reliable installs.

Pre-releases when available can be found on the Sparkle's Releases or on your favorite package manager. More nightly builds can be downloaded by selecting a recent workflow run and downloading the corresponding Sparkle-distribution artifact.

The current status for future versions of Sparkle is tracked by its roadmap.

Please visit Sparkle's website for up to date documentation on using and migrating over to Sparkle 2. Refer to Changelog for a more detailed list of changes. More internal design documents to the project can be found in the repository under Documentation.

Features

• Seamless. There's no mention of Sparkle; your icons and app name are used.
• Secure. Updates are verified using EdDSA signatures and Apple Code Signing. Supports Sandboxed applications in Sparkle 2.
• Fast. Supports delta updates which only patch files that have changed and atomic-safe installs.
• Easy to install. Sparkle requires no code in your app, and only needs static files on a web server.
• Customizable. Sparkle 2 supports plugging in a custom UI for updates.
• Flexible. Supports applications, package installers, preference panes, and other plug-ins. Sparkle 2 supports updating external bundles.
• Handles permissions, quarantine, and automatically asks for authentication if needed.
• Uses RSS-based appcasts for release information. Appcasts are a de-facto standard supported by 3rd party update-tracking programs and websites.
• Stays hidden until second launch for better first impressions.
• Truly self-updating — the user can choose to automatically download and install all updates in the background.
• Ability to use channels for beta updates (in Sparkle 2), add phased rollouts to users, and mark updates as critical or major.
• Progress and status notifications for the host app.

Requirements

• Runtime: macOS 10.13 or later.
• Build: Latest major Xcode (stable or beta, whichever is latest) and one major version less.
• HTTPS server for serving updates (see App Transport Security)

Usage

See getting started guide. No code is necessary, but a bit of configuration is required.

Troubleshooting

• Please check Console.app for logs under your application. Sparkle prints detailed information there about all problems it encounters. It often also suggests solutions to the problems, so please read Sparkle's log messages carefully.

• Use the generate_appcast tool which creates appcast files, correct signatures, and delta updates automatically.

• Make sure the URL specified in SUFeedURL is valid (typos/404s are a common error!), and that it uses modern TLS (test it).

API symbols

Sparkle is built with -fvisibility=hidden -fvisibility-inlines-hidden which means no symbols are exported by default. If you are adding a symbol to the public API you must decorate the declaration with the SU_EXPORT macro (grep the source code for examples).

Building the distribution package

You do not usually need to build a Sparkle distribution unless you're making changes to Sparkle itself.

To build a Sparkle distribution, cd to the root of the Sparkle source tree and run make release. Sparkle-VERSION.tar.xz will be created and revealed in Finder after the build has completed.

Alternatively, build the Distribution scheme in the Xcode UI.

Code of Conduct

We pledge to have an open and welcoming environment. See our Code of Conduct.

sparkle's Issues

Provide capability to revert to previous version if new version has unexpected bugs

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-05-09:*

"Seems to me that the only downside of self-updating is that if the new
version suffers from a bug that makes it unusable for a particular user,
that user is going to have to jump through hoops to be able to get back
to the previous version. Perhaps Sparkle could store the previous
version internally as a diff, making it possible to revert to an older
version if need be. I realize this is unlikely to be a common need, but
I'll bet there are users out there who are unhappy about self-updating
for this reason."

AMM: This seems like a good idea (though a wish, really); seems like a
custom driver could handle cherrypicking versions.

This ticket was migrated from the old trac: re #39
Originally reported by: [email protected]

Double-authentication causes installation failure.

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-05-09:*

1. Try to update an app without write access.
2. Get authentication prompt; cancel.
3. Check for updates again and authorize this time.
4. Note that Sparkle fails to copy the new app in place but still trashes the old one.

Install and Relaunch appears on top of Installer

**Carl Harris (ceharris414)* reported (on Launchpad) on' 2009-07-12:*

When updating using a package (.pkg) in a disk image, the Install and
Relaunch panel appears over top of the Installer itself. This confuses
users -- they seem to expect that the install will happen automatically
since the Installer app isn't on top.

Sparkle 1.5b6

Cannot develop for Leopard on Xcode 4

**Hofman (cmhofman)* reported (on Launchpad) on' 2011-03-21:*

It is not possible to compile Sparkle on Xcode 4 while supporting
10.5.x. The reason is that Xcode 4 requires the use of the 10.6 SDK,
while Sparkle links to libcrypto, which is not compatible with the
version available on 10.5.x.

Isn't it possible to replace the DSA verification code by something that
is compatible, rather than the very problematic openssl?

BTW, why does it link to libcrypto using an explicit linker flag, rather
than adding libcrypto to the link build phase? It took me a lot of time
to figure out what was going wrong.

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Failed update should try again

**Hofman (cmhofman)* reported (on Launchpad) on' 2008-09-13:*

Currently, every update check is done only once. When it fails, e.g.
when there's no connection, it won't try again. I think this is wrong,
especially if a user has a large update interval (a week or a month).

Perhaps you should register a separate check time when the check fails,
or use a last check time in the past, something like: [NSDate
dateWithTimeIntervalSinceNow:3600 - [updater updateCheckInterval]].

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Bundles can't ask for permission to update; developers have to hard-code YES for SUEnableAutomaticChecks

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-12-30:*

So unfortunately, right now, Sparkle doesn't support asking for
permission to update for bundles. And resetUpdateCycle uses whatever
settings the user has to set an appropriate schedule. But if the user is
never asked for permission, then there are no settings, and so no update
will be scheduled, and there's no way for a bundle to make the
permission UI happen.

This sucks, and I'll fix it someday. In the meantime, set
SUEnableAutomaticChecks to YES in your Info.plist. Sorry about that.

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Add option to have multiple updates in a single appcast that can be selectively chosen

**livings124 (livings124)* reported (on Launchpad) on' 2009-01-12:*

I'm not sure if "Answers" or here is the best place to add feature
requests, so I'm guessing it's here.

It would be useful to have multiple updates listed in a single appcast
file, with some sort of key separating them. This would be similar to
how it works now with minimum version numbers.

For an example, I could have 2 updates, one with no key and one with the
key "beta". There would be some sort of method (delegate maybe?) to
specify all the valid keys (as an array most likely). If no keys are
specified, the update with the "beta" key would be ignored and only the
other would be considered. If one of the keys specified in the code is
"beta", however, both would be considered, and the one with the higher
version number would be used. This would simplify things greatly for
users that want to support optional updates for betas, etc.; it's easier
to maintain and feels less hacky than having multiple feeds that have to
be synchronized.

sparkle initial window effecting app's window size

**Hans Hansen (hans-midnightbeep)* reported (on Launchpad) on' 2009-02-04:*

When my application's main window did not have an "autosave" name set,
Sparkle 1.5b6's initial "do you want to check for updates" window is
overriding my app's own saved window size preference. I fixed this by
giving my app's window a name (rather than the default blank name).
However my guess is that this is happening because the window Sparkle
presents also doesn't have an "autosave" name specified -- it probably
should, just as I probably should have.

Support for flat .pkg files that are not compressed

**martoche (martin-ottenwaelter)* reported (on Launchpad) on' 2009-03-14:*

Mac OS X 10.5 introduced flat .pkg files that are already compressed. It
doesn't make sense to .zip or .tar.gz a flat .pkg file, they can be
downloaded as-is.

Sparkle assumes that all downloaded files should be unarchived, which is
not the case for a flat .pkg file.

Attached to this report is a patch that solves the problem. The patch
consists in one new class "SUNoOpUnarchiver" which is a SUUnarchiver
subclass that registers itself as the unarchiver for flat .pkg files,
but does nothing when asked to unarchive the file.

Unnecessary unregisterAsObserver

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2009-10-27:*

"It is -unregisterAsObserver that is causing the NSException.

Andy, many of us have a breakpoint set for NSException (and/or
objc_exception_throw) in XCode. So every time we run the app and get to
the point of the second nib instance it causes the breakpoint to fire
and stop execution. This gets rather annoying after a while. :)

I solved this by adding a flag to SUUpdater called
hasRegisteredObservers. I set it in -registerAsObserver and in
-unregisterAsObserver if it is not set it returns.

No more unnecessary NSExceptions."

Hofman: "I wonder if it's not the -unregisterAsObserver in -[SUUpdater
dealloc]. That's potentially dangerous and moreover totally unnecessary,
because instances that did register as observer will never be
deallocated (as they're retained by the sharedUpdaters dictionary),
while instances that are deallocated are never initialized (and
therefore never registered)."

"Install on Quit" Button

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-05-09:*

Originally reported by: It'd be nice to complement the "Install and
Relaunch" button with an "Install on Quit" button.

This has already been done for fully automated updates, but it'll take a
bunch of changes to SUStatusController to make it work for normal
updates.

Testing

API

Get updated localizations before shipping 1.5

**dwood (dwood-karelia)* reported (on Launchpad) on' 2009-01-05:*

Using Peter Hosey's Localization Helper <http://boredzo.org
/localization-helper/> against r326, I found a few issues with the
localizations. Maybe our localizers could make a pass here so that when
1.5 is released it will be fully localized?

Brief overview: DE, FR/FR_CA, IT need one update, to fix this string:

"%1$@ can't be updated when it's running from a read-only volume like a
disk image or an optical drive. Move %1$@ to your Applications folder,
relaunch it from there, and try again."

SV needs the above plus: "%@ downloaded"

ES needs several updates:

"An error occurred while relaunching %1$@, but the new version will be available next time you run %1$@."
"%@ downloaded"
"You already have the newest version of %@."
"%1$@ can't be updated when it's running from a read-only volume like a disk image or an optical drive. Move %1$@ to your Applications folder, relaunch it from there, and try again."
"An error occurred while parsing the update feed."
"%1$@ %2$@ has been downloaded and is ready to use! Would you like to install it and relaunch %1$@ now?"
"Checking for updates..."
"Cancel Update"
"An error occurred while installing the update. Please try again later."
"Should %1$@ automatically check for updates? You can always check for updates manually from the %1$@ menu."
"An error occurred while downloading the update. Please try again later."
"A new version of %@ is ready to install!"

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Failed install should move back version set aside

**Hofman (cmhofman)* reported (on Launchpad) on' 2009-07-19:*

When the final installation fails (copying the new version to the
install location), the old version that was moved to a temporary
location should be moved back to the old location so the user can easily
find it back. This problem can happen when the /Applciation/ folder is
password protected.

I'm passing on a problem reported by one of our users, who reported:

"When the application folder is password protected, and one updates to
the new version, it does not ask for the password, but reports that the
update has failed. Then the current version is already erased."

Add an "Older Release Notes" popup menu

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-05-09:*

This is a really cool idea (thanks, Matt Gough!): add a popup menu to
the update alert for older release notes. This solves the tricky problem
of not being able to merge HTML files well without some server-side
support.

This ticket was migrated from the old trac: re #5
Originally reported by: Matt Gough

Sparkle changes name of installed product

**Hofman (cmhofman)* reported (on Launchpad) on' 2009-06-29:*

The installed product should be named the same way as whatever is in the
update. However, SUPlainInstaller always uses the name of the bundle
that was updated, which is not necessarily the same. This is very wrong.

Install on relaunch

**Paul Marks (shadowofged)* reported (on Launchpad) on' 2010-03-08:*

I'm running Sparkle 1.5b6 and I've seen a few crashes in my app, often
under -[NSTask launch], because the target executable is missing.

From the logs, it's clear that my application has been moved by Sparkle,
even though I return YES from
-updater:shouldPostponeRelaunchForUpdate:untilInvoking: when I may still
be launching NSTasks. So the move must happen before I'm asked if
relaunching/installation should be deferred.

The order looks something like this:

• Start NSOperation that launches a few NSTasks.
• Find update; user agrees to install & relaunch.
• New version is installed while NSOperation is still running.
• Things go wonky because resources are temporarily unavailable during the installation.
• Application is then asked if it should postpone relaunching.

However, the damage is already done. A this point, the singleton
-[NSBundle mainBundle] path is incorrect, so all the resources are
whatever shipped with the updated version.

test

foo

Give the user the option to update when the application CLOSES

**A. Jesse Jiryu Davis (ajdavis)* reported (on Launchpad) on' 2010-01-18:*

I've had what may be a user-experience insight: software applications
should self-update when you CLOSE them, not when you open them. When I
open an application it's because I want to use it NOW. The notification
should still appear when you open the app, BUT a button on the
notification box that says "Upgrade On Close" would be fantastic!

The problem with "upgrade first" is that the moment I open the app is
when I'm least likely to be willing to click "OK, do this mysterious
upgrade, which probably won't noticeably help me, and prevent me from
the using the app I JUST OPENED for an unspecified period of time." If
you really want the app to upgrade you have to make the user willing to
click "yes".

It might also be nice to distinguish between feature upgrades (do it
whenever) and critical upgrades (do it before you use the app or you
might be sorry), but that adds complexity both to the code and the user
experience that may be unwarranted.

Feature: Silent updating

**Tom Davie (tom-davie)* reported (on Launchpad) on' 2010-09-24:*

Being able to set sparkle to update an application silently in the
background (showing no dialog boxes), so that the new version is
installed when the user relaunches would be very nice. Perhaps with a
ticky box in the update window to ask for it not to be shown again –
simply to update automatically from then on.

Write test driver and test feeds

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-05-12:*

Sparkle is really rickety right now without any formal testing
procedures. Using the new driver framework, we should be able to
implement a driver that will perform a test installation and return
whether it was successful; we can then generate a number of test feeds,
spanning various appcast options and archive formats, to ensure that
everything's working as expected.

If update fails, re-trying should try already-downloaded update first

**Chris Hanson (eschaton)* reported (on Launchpad) on' 2009-02-05:*

When an update is downloaded but installing the update fails (say with a
crash), the next time you try to update Sparkle should first attempt to
use the already-downloaded update if it still exists, is still the
latest, and its signature is intact.

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Subclass of SUBasicUpdateDriver can't find relauncher

**Jordy/Jediknil (jediknil)* reported (on Launchpad) on' 2010-01-24:*

When I subclass SUBasicUpdateDriver /outside/ of the Sparkle framework,
it can no longer find the "relaunch" executable to copy to
NSTemporaryDirectory(). This is a particularly bad problem because it
then has a nil path, and the file manager removes the temp folder
completely, before the update copy is performed!

Fix: in -[SUBasicUpdateDriver installUpdate], replace [NSBundle
bundleForClass:[self class]] with SPARKLE_BUNDLE.

Sparkle v1.5b6, used for a preference pane.

Sparkle closes on program close

**HPShelton (parker-shelton)* reported (on Launchpad) on' 2010-02-05:*

Sparkle should behave in a more modal manner, prompting the user to
cancel the update or cancel closing the main application if the main
program was closed.

1. I close the program, forgetting Sparkle has downloaded an update
2. Sparkle comes to front, asking if I'm sure I want to close and offering the option to continue updating or close the program.

This affects all applications that use Sparkle, and has been highly
annoying to me.

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Sparkle assumes that greater versions are always newer, which is wrong

**Peter Hosey (boredzo)* reported (on Launchpad) on' 2009-06-25:*

When Sparkle looks for a usable version among the appcast items (see #228485), it sorts the items by date.
This is a problem, demonstrated by Adium 1.4b6.

Our appcast for Adium betas includes both 1.4b7 and 1.3.5; of these,
1.3.5 is actually the newer (more recent) release. Because Sparkle sorts
the items by date, it looks at 1.3.5 first; it finds that 1.3.5 will run
on the host, so it stops looking for more versions. However, 1.3.5 is a
lower version number than 1.4b7, so it tells the user that “1.4b6 is the
latest version available!”—which is wrong, since b7 is available.

We're not sure exactly which version of Sparkle we're using (it was a
build from source, and the developer who committed it didn't note the
version in his commit message). All I know is that CFBundleVersion is
340, for whatever that's worth.

update notification launches in background in lion fullscreen apps

**Harrison Heck (harrison-heck)* reported (on Launchpad) on' 2011-10-17:*

When a notification pops up about an update, and the update is for an
application that is in the Lion fullscreen mode, the notification
sometimes pops up in the background. This causes the user to have to get
out of fullscreen to see the notification.

SUUpdateAlert's check box for automatically download updates isn't bound correctly

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-12-08:*

It's bound to the (private) preferences key rather than to the
automaticallyDownloadsUpdates key on SUUpdater.

Improve support changes in application name

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-05-09:*

Sparkle fails utterly if the application's name changes at some point
through its history. I think the right way to do this is that if the
package to be installed is going to have an unexpected name, set some
attribute in that appcast item. Needs more thought.

This ticket was migrated from the old trac: re #11
Originally reported by: andym

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

maximumSystemVersion key

**Jeremy Huddleston (jeremyhu)* reported (on Launchpad) on' 2009-10-12:*

This bug report follows from
https://answers.launchpad.net/sparkle/+question/84464

Essentially, there needs to be functionality in place to set a maximum
system OS version for a package rather than just minimum.

Crash when update is downloaded but waiting for install overnight

**kdbdallas (dbrown-hashbangind)* reported (on Launchpad) on' 2009-09-16:*

If there is an update, and you accept the update and it downloads, but
you DON'T install and you leave it at that state over night and between
machine sleeps, when you then tell the update to install the update
fails and gives the console message of:

Sparkle Error: An error occurred while installing the update. Please try again later.
Sparkle Error (continued): Sparkle Updater: Possible attack in progress! Attempting to "upgrade" from 1 to (null). Aborting update.

If you then try and check for updates again the app will crash with
signal: “EXC_BAD_ACCESS”

This is with the latest version of Sparkle.

Sparkle 1.5 doesn't work with Sparkle 1.0 loaded

**willco007 (will-panic)* reported (on Launchpad) on' 2009-05-04:*

If a host application has an old version of Sparkle loaded, say 1.0, and
it loads a plugin with Sparkle 1.5 in it when Sparkle 1.5 tries to
update it will throw an exception because it's trying to call methods on
a the already loaded Sparkle 1.0 classes.

The exception is:

NSInvalidArgumentException - *** +[SUUpdater updaterForBundle:]:
unrecognized selector sent to class 0x6595e0

Since sparkle 1.5 is not compatible with Sparkle 1.1, the classes should
be renamed to avoid name space issues or it should, at the very least,
check to make sure the class has not be loaded yet and if it has, make
sure it's a compatible version. If it's not, it should not load itself.
This is a critical bug.

SUPackageInstaller should respect synchronously option

**David Dauer (ddauer)* reported (on Launchpad) on' 2008-11-24:*

1.5b6:

the corrected method should be

• (void)performInstallationWithPath:(NSString *)path host:(SUHost *)host delegate:delegate synchronously:(BOOL)synchronously versionComparator:(id )comparator;
  {
  ....

  NSTask *installer = [NSTask launchedTaskWithLaunchPath:installerPath arguments:[NSArray arrayWithObjects:path, nil]];
  if (synchronously) [installer waitUntilExit]; // changed here

  // Known bug: if the installation fails or is canceled, Sparkle goes ahead and restarts, thinking everything is fine.
  [self _finishInstallationWithResult:result host:host error:error delegate:delegate];
  }

System-wide preferences

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-05-09:*

It would be useful for IT-administered environments if automatic updates
in all applications could be disabled so users don't have to deal with
updates they shouldn't (and can't) install. On a similar note, it'd be
nice for power users to be able to say "always update my software
always!"

An appropriate way to implement this would be to read
/Library/Preferences/org.andymatuschak.sparkle.plist for
SUEnableAutomaticChecks and SUAutomaticallyUpdate.

This ticket was migrated from the old trac: re #77
Originally reported by: catlan

Ability to run Install.app without user interface

**Peter Speck (speck)* reported (on Launchpad) on' 2008-09-19:*

I would like to be able to run Installer.app without using the GUI but
simple running the command line version.

Using the GUI results in the Window-esque click-ok click-ok click-ok
sequence.

The proposed patch adds a delegate callback which enables the host app
to run the installation itself instead of calling the Installer.app.
Sparkle still does the rest of the process.

I need to use the Installer.app instead of simple download install to
have the stuff installed correctly.

Sparkle runs thread-unsafe code on secondary threads

See bug #388793 for a consequence of this bug, though this does not even
touch the real problem. As the problem is more widespread and lies
deeper I open a new more comprehensive bug.

Sparkle runs code that can only be used on the main thread on secondary
threads. This happens (for sure) in SUPlainInstaller,
SUDiskImageUnarchiver, and SUPipedArchiver.

The clearest problem is the use of shared instances of thread-unsafe
classes, such as NSFileManager, NSWorkspace, and NSBundle, either
directly or indirectly. You can use these instances ONLY on the main
thread, because they're the same objects that are already used for sure
on the main thread.

I can only see three ways to fix this (may depend on the particular instance):

1. Run this code synchronously.
2. Run the unsafe code synchronously before spawning the secondary thread.
3. Replace the unsafe Cocoa methods by thread-safe Carbon functions. For example, the Carbon file manager is generally thread safe.

Migrated from Launchpad: https://bugs.launchpad.net/sparkle/+bug/389869
Originally reported by Hofman (cmhofman) at Sat, 20 Jun 2009 12:05:18 -0000.

Testing issues

harrumph

Support password-protected appcasts

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-05-09:*

Sparkle should support appcasts and update archives which are behind
simple HTTP authentication.

Delegate method for errors

**Koingo Software (main-koingosw)* reported (on Launchpad) on' 2008-11-07:*

Josh Hague said:
Throw a sparkleError(int errCode,str errMsg) event whenever a sparkle update fails (maybe web access is off, etc.) so the developers have the ability to perform code in this event.

Andy Said:
Good call. There should be a delegate method for errors. Please file a bug for this at http://bugs.launchpad.net/sparkle.

"Ready to Install" alert should bring itself to front when opened

**dwood (dwood-karelia)* reported (on Launchpad) on' 2009-09-02:*

If you have started downloading an update, and your downloading progress
window gets hidden behind any other window, then when the app is ready
to install and relaunch, the "Ready to install" alert does not appear
over other windows in the app.

This is confusing. I see that this is not a modal dialog, but it acts
similar to one. (Though it's nice to be able to move it out of the way
behind the other windows once you have seen it, so you can relaunch
later.)

To reproduce:

• Start downloading an update.
• Bring another window to front, covering up your downloading window.
• For even more fun, bring another application up.

Later, when the update is downloaded, click the program's icon in the
dock (if it wasn't active).

I would expect the Ready to Install window to be front and center.

Instead, it is hidden behind other window(s).

Can this window be forcibly brought to front when it's ready?

Adopt standard code signing in favor of DSA signing

**Andy Matuschak (andymatuschak)* reported (on Launchpad) on' 2008-06-29:*

We should use code signing for 10.5+ applications; it's in the system,
and this way, devs who already sign their apps won't have to do double
duty.