2008 July

published on Friday 04 July, 2008 at 12:28 pm. {Share Your Thoughts}

I’m working on some major refactorings to enable Sparkle to work for updating multiple bundles at once, but that’ll take a while, and some rather important bugs have been fixed since 1.5b2. In the spirit of releasing more frequently, I give you 1.5b3. If you’ve released an app with b2, I recommend upgrading as soon as you can.

Added a new delegate method to SUUpdater.h to allow delegates to specify custom version comparators.
Added a German localization, courtesy the Camino localizer team: Dominik T., Tobias Stohr, and Friedemann Bochow.
Bug fixes:
- Fixed a serious bug which could cause a server to be DDoS’d (or the host app to crash!) if an appcast fails to be parsed.
- Fixed .tbz extraction if the archive was made with Stuffit.
- Fixed support for .tar.bz2 and .tar.gz; Sparkle has to assume the archive is a tar when it sees “bz2″ and “gz”; don’t use those without tarring.
- Fixed a typo which caused the shouldPromptForPermissionToCheckForUpdatesToHostBundle: method to not work in 1.5b2.
- Fixed .zip extraction on Tiger (Apple changed the UTI between releases)
- Fixed a crasher on Tiger.
- Fixed display of the default app icon when the host app doesn’t have an icon.
- Sparkle now displays a sensible progress string and uses an indeterminate progress bar when the server doesn’t report a file size.
- Fixed some memory leaks.

Why You Need to Build 64-Bit

published on Wednesday 02 July, 2008 at 11:06 pm. {13 Comments}

The following was only recently made clear to me, and I don’t think it’s been expressed well enough to Mac developers:

You must build your app for 64-bit because if even one binary image running is 32-bit, then the system has to load the entire 32-bit and 64-bit framework stacks. AppKit, Foundation, Quartz—everything down to libc.

The only way the platform can successfully finish the transition to 64-bit is for everyone to distribute a 64-bit binary.

So get your bits in place!