Can we at least do no harm in OS 10.3?

Sparkle 1.5b5 uses code that is not supported by Panther, so the answer to your first question is: no, it's not supposed to work at all. Sparkle is a framework, and as such is loaded automatically with the executable in your (app) bundle. Sparkle would have no way to "harmlessly do nothing on Panther", because when it would have a chance to do anything, it would already be too late.

If you want to use Sparkle on 10.4+ and still allow your app to run on 10.3, you need to load Sparkle dynamically yourself after checking the system version (or AppKit version) rather than linking to it. See the documentation on loadable bundles for more details.

Contrary to your answer, I believe I have devised a way to add a few lines of code to make Sparkle harmlessly do nothing in Panther.

Up at the beginning of SUUpdater.m, I added the function:

static BOOL IsOSTooOld()
{
 SInt32 response;
 Gestalt( gestaltSystemVersion, &response );
 return (response < 0x1040);
}

At the beginning of [SUUpdater registerAsObserver], I inserted:

 if (IsOSTooOld())
 {
  return;
 }

And at the beginning of [SUUpdater validateMenuItem], I inserted

 if (IsOSTooOld())
 {
  return NO;
 }

No more crashes, at least so far.

If it is the case that 10.3 is not supposed to be supported, someone ought to update the web site. The Sparkle home page has a link "Read more about what's new" that leads to the page saying that 10.3 support is "sketchy at worst". "None" is worse than "sketchy".

The keyword is "so far". Depending on the pref settings, this won't work. And registerAsObserver is certainly the wrong place to check (I'd do it in allocWithZone:). What you do is very dangerous and very wrong. If you like putting a bomb in your program, it's of course your responsibility. To make this safe, much more is required. I advice you to read the cross development guide.

Moreover, maintaining a safe product this way would be a maintenance nightmare, and probably Andy would not be able to test it, so Andy should not do this. I certainly wouldn't be willing to.

As an aside, what you see is a perfect argument as to why Sparkle should *not* attempt any of this. The code in registerAsObserver is in fact fully 10.3 compatible! The fact that it breaks could have never been guessed without testing, and apparently one cannot just rely on expectations and the docs alone.

I'm kind of confounded as to why registerAsObserver is crashing, but that's kind of the nature of trying to develop for 10.3 using 10.6. You're absolutely right that Sparkle shouldn't do no harm if it can: it'd be nice to have it harmlessly do nothing on 10.3. Of course, the framework will still get loaded, but Sparkle only has one +initialize call, so it should be reasonably safe so long as all entry points are no-ops. I'm not sure I can guarantee that, though. I'm thinking that if I maybe make both SUUpdater and SUUpdateDriver's allocWithZone methods perform the check, we'd be at least better off than we are now. What do you folks think?

"Sparkle shouldn't do no harm" -> "Sparkle should do no harm"