Update error! #315

BaseHead opened this Issue Jan 6, 2014 · 8 comments


None yet
2 participants

BaseHead commented Jan 6, 2014

Hey all and Andy!

I saw this error many times talked about on the web but nothing seemed to help my situation.

Update Error!
An error occurred while installing the update. Please try again later.

Getting this after it downloads the update and I click to install it.

It all used to work fine but it's been about 4 months since we released a version on auto-updater using Sparkle via Feeder.
seeing it on 10.7 and 10.8 and same with all other users of my software.
Other Sparkle apps on my mac seem fin

Any ideas what to try or check?



BaseHead commented Jan 6, 2014

oh...I should add that this is a desktop app that is NOT sandboxed....8)


What is written to ~/Library/Logs/SparkleUpdateLog.log?

BaseHead commented Jan 6, 2014

it's pretty blank....only this

2014-01-06 01:03:20 +0000: ===== Versions ====

strange....any ideas what to try next? thx for the help!! 8)

Do there appear to be any left over files from the update in your ~/Library/Application Support/<YourApp> folder? If you move those aside, does the update succeed?

Does your app have any items (files or directories) which might be read-only for the current user? Check both the version that you're trying to update from and the version that you're trying to update to. For the latter, download it from the link in your feed, to be sure you're getting the same bits as users.

BaseHead commented Jan 6, 2014

if I rename the whole folder....same problem still....8(

Everything looks as set to Read and Write for my current user....i'm just replacing a .app that is zipped up.
I looked at the privileges of most all on the .app contents also

strange that the log seemed blank though....huh?

what's next?


Are you sure the update has a higher version number than the one you're running?

Is the update changing the name of the app?

strange that the log seemed blank though....huh?

Not really. Sparkle is pretty bad at logging what's going on.

BaseHead commented Jan 6, 2014

yep...otherwise I don't think it would even download it.....
BUT I figured it out with a little nudge by you!! 8)

the current version is 3.0.68 and the new version is 3.1.25 and since the build number is lower it wouldn't even start the update and download it... so I fudged it in Feeder and set it to 3.1.70 and then it downloads fine

I didn't realize another check would be done before replacing the file and apparently there is....8)
so I'm all good now after I rebuild the .app also for 3.1.70

Any ideas why 3.1.25 would not be considered higher then 3.0.68?

maybe I don't get how to set the settings in Feeder 100%
I've got the short version set to 3.1 and the Sparkle version set to 70 to equal my xcode build of 3.1.70
does that seem the correct way to do it ya think?

thx for all the help man!


Let's be specific: in your app's Info.plist, what are the values for CFBundleVersion and CFBundleShortVersionString for both the app you're running and trying to update and the one you're updating to? Likewise, what is the sparkle:version and sparkle:shortVersionString in your feed?

In general, there doesn't have to be any relationship between the version and the short version. The short version is sometimes considered the marketing version. It's the one that users will usually see and think about. The version is considered the build version. It's a technical value that should have a precise meaning in terms of what was built. In general, only the build version will be programmatically analyzed by Sparkle or OS X. The short version is for human consumption.

The important thing from Sparkle's perspective is that the build version should increase with an update.

From your description, you would want the build version (a.k.a. sparkle:version and CFBundleVersion) to be something like 3.0.68 and 3.1.25, not just "68" and "25". (You could have a build version that's just a single number, but then it would not make sense to treat that as the "z" component of an "x.y.z" version number. The single number would have to only increase over time.)

Indeed, the build version may sometimes be even more specific than x.y.z because for any given x.y.z release, you might tweak and build it several times as testing dictates. So, you might use x.y.z-actualBuildCount or x.y.z-totalCommitCount.

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