Time for some spring cleaning? Version 2.0? #248

samdeane opened this Issue Feb 11, 2013 · 7 comments


None yet

4 participants


I'm not very familiar with the code, but from what I've seen, it looks like it could do with a little spring-cleaning, as the inevitable result of developing over a number of years whilst maintaining full backwards compatibility.

I'd like to see a version of the source code that is 64-bit, modern runtime, sandboxing friendly (and as a result of all of this, 10.7+ only):

Seems to me that adding sandbox support might be an opportunity to perform this more radical cleanup. For one thing, sandboxing (and code signing) naturally makes some things obsolete. For another thing, without a clean break, sandboxing is going to introduce parallel code paths into an already fairly complicated picture. This is going to do nothing to help with long-term maintainability.

I'd suggest:

  • remove old #ifdef'd code supporting earlier systems
  • remove everything but code signing as a way of verifying the download
  • remove dmg archive support since it won't work for sandboxed apps
  • assume the modern runtime, and use automatically synthesized ivars
  • adopt the modern syntax for enumeration, collections, etc
  • remove any other obsolete code / ui
  • use NSURL instead of NSString where appropriate
  • not sure, but possibly... ARC

On a related note, although not strictly code changes:

  • clear up the folder structure for the project, move code and localised resources into subdirectories
  • document the design :) (maybe this is somewhere already and I've missed it)

Yeah. People are still using Snow Leopard though, however, it's definetly time for a new direction I think.


Yeah, 10.6 is definitely still in use (two big apps I'm contracting on still support it, for example).

I think, though, that most developers are just looking for an excuse to drop it. Sandboxing is a big nudge in that direction anyway, particularly since XPC is 10.7 only. ARC is obviously another nudge.

So making a new Sparkle 10.7+, rather than 10.6+, just seems more logical to me.


I suppose. The people who want it to still support pre-10.7 could always fork Sparkle.


Yes, a version for 10.8 and 10.9 only would be great!


I wouldn't be so hasty about dropping 10.7 yet, though. 10.6 can certainly be dropped however.

Sparkle Project member

We've done most of that spring cleaning.

@pornel pornel closed this Mar 2, 2015


@samdeane samdeane referenced this issue in BohemianCoding/Sparkle Mar 18, 2016

Code Review: Update to the latest Sparkle (#4258) #8

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