atomicbird

Macaroni 2.1.1 has just been released. This version fixes a number of minor bugs in 2.1, most notably:

• Fixes a particularly embarrassing bug where it would occasionally be impossible to register Macaroni.
• Fixes the "clear history" button, which was unfortunately broken in 2.1.

System Requirements

To use Macaroni 2.1.1 you must have Mac OS X 10.4 or 10.5, on an Intel or PowerPC Mac. Mac OS X 10.2 and 10.3 will not run Macaroni 2.1.1, although Macaroni 2.0.8 is still available from the Macaroni page if you need it for an older Mac
.
This is a free upgrade for all registered users of Macaroni. Macaroni 2.1.1 can be downloaded from the Macaroni home page.

To Upgrade

There always seems to be a little confusion regarding how to upgrade Macaroni. Here's how you do it:

1. Install the new version.
2. There is no step 2.

People often assume that they need to go through a complex upgrade routing involving (at a minimum) removing the old version and (sometimes) mysterious rituals they expect are necessary to prepare their Mac. I try to make it as painless as possible but some people seem to expect the worst. If for some reason it's not that simple for you, please let me know so that I can make sure to fix the problem in the next version.

Developer Note

If you're interested in Mac OS X software development, you may be interested to know that this is the first version of Macaroni built on Mac OS X 10.5 "Leopard", and using the new Xcode 3 development environment. Macaroni 2.1 was a Leopard-compatible upgrade, but was built on Mac OS X 10.4 using Xcode 2.4. I have not yet migrated from nibs to xibs for the GUI, but I'm investigating the possibility for future releases.

According to numbers sent in by Sparkle, Leopard usage among people using my software has just passed 50%, just over 7 weeks after Leopard's release. The most recent numbers show 51.9% on 10.5 (49.7% on 10.5.1 and the rest still inexplicably sticking with 10.5). The plot below also shows a solid 40% sticking with 10.4.11 for now.

I'm waiting to see what sudden changes might occur after Christmas, or possibly after MacWorld next month. Either could mean a lot of new Macs replacing or supplementing old ones.

The latest numbers from Sparkle can always be found on the Sparkle Stats page, which is automatically updated every night.

Yesterday Atomic Bird was one of the featured developers at MacSanta. It went well. It was the first day of MacSanta and I was concerned that not many people would have heard about it yet. As it turned out, well, I don't release specific sales numbers but yesterday's MacSanta customers here at Atomic Bird came to more than 90% of the number of MacSanta customers last year. Last year of course MacSanta ran for about a week, with all developers listed every day. So I'd call MacSanta a smash success already, and it's still just December 2.

And it's still going

Although Atomic Bird isn't the daily featured developer, MacSanta deals continue for the rest of the month. You can find Atomic Bird on the participants list where everyone who's participated in MacSanta so far will be offering discounts all month. Just use coupon code MACSANTA07TEN. And of course there are new featured developers on the main MacSanta page every day in December.

The MacSanta promotion is back for a second year!

For the month of December, independent Mac software developers will be offering special deals on their software through the MacSanta web site at MacSantaDeals.com. Every day new developers will be featured, offering 20% off of their software for that day, using coupon code MACSANTA07 when purchasing. After their featured day they will continue to offer 10% off through the end of the month using coupon code MACSANTA07TEN.

Atomic Bird is featured December 1

We drew the very first day, so on Saturday December 1, all of our software will be 20% off with coupon code MACSANTA07. That code can be used in our web store, but be sure and visit the MacSantaDeals.com web site to see what else is available. After December 1 the coupon code MACSANTA07TEN can be used for the rest of the month.

Thanks

The MacSanta promotion is run by Paul Kafasis of Rogue Amoeba, who does all the work on a volunteer basis. Most of the participants also volunteer to buy Paul a beer if we ever meet in person.

I recently wrote about problems using Leopard code signing with Mac OS X frameworks. I've since gotten feedback on my bug report. It looks like the problem isn't so much that frameworks can't be signed but that the correct signing procedure isn't documented.

The code signing documentation indicates that bundles should be signed. Frameworks are bundles, so if you're looking to sign your code you'll likely be tempted to sign a framework like this:

$ codesign -s "authority info" Sparkle.framework

But if you do that you run into the confusing situation I encountered, with your framework structure modified and difficulty knowing if the bundle is valid or not.

The feedback I got on my bug report explains that code signing should be done differently for versioned bundles like frameworks and... whatever other versioned bundles there might be. Although frameworks commonly contain only one version, they're designed so that multiple versions can be present. When signing a framework then, you sign the specific version, not the entire framework bundle. So instead of the above, you instead do something like this:

$ codesign -s "authority info" Sparkle.framework/Versions/A

If there are other versions, sign them separately.

This leaves the framework structure unmodified:

$ find Sparkle.framework/ -name Sparkle -exec ls -l {} \;
lrwxr-xr-x  1 tph  wheel  24 Nov 29 11:44 Sparkle.framework/
    /Sparkle -> Versions/Current/Sparkle
-rwxr-xr-x  1 tph  wheel  242928 Nov 29 11:44 Sparkle.framework/
    /Versions/A/Sparkle

Of course when verifying the signature, you also need to verify the versions independently of the framework bundle. The framework itself won't have a valid signature, but that's not what you should be looking at anyway:

$ codesign -vvv Sparkle.framework/Versions/A
Sparkle.framework/Versions/A: valid on disk
$ codesign -vvv Sparkle.framework/
Sparkle.framework/: code or signature modified

This seems to make sense. A framework is designed to allow multiple independent bundles, with symbolic links to indicate which is current. So, sign each bundle on its own.