Archive for July, 2012

Arq, SyncPhotos and Duplifinder are Mountain Lion compatible

Sunday, July 29th, 2012

OS X Mountain Lion is out, and all Haystack Software apps are compatible:

Arq 2.8.2: online backup to Amazon S3

SyncPhotos 2.2.2: sync your iPhoto Libraries across computers

Duplifinder 2.1.1: eliminate duplicate photos

If you do happen to run into an issue with any of the above, please email support@haystacksoftware.com and I’ll address the issue very promptly!

Gatekeeper and Leopard/Snow Leopard Compatibility

Wednesday, July 11th, 2012

Both Arq (our backup app)and SyncPhotos (our photo sync app) were bitten this week by the code-signing gotcha that Daniel Jalkut, Ben Artin, and Chris Suter blogged about.

I had switched to using Apple’s new Developer ID scheme for code signing so that when Mountain Lion comes out people will still be able to use Arq and SyncPhotos. I even watched the WWDC video to make sure I was doing it correctly. But apparently I didn’t watch closely enough. As the 3 blog posts linked above explain, the code signatures produced with the new scheme can only be validated by Macintosh computers that have the necessary information to validate them, namely computers running OS X 10.7 or later.

Both Arq and SyncPhotos launched OK on 10.6, 10.7 and 10.8. But on 10.6 they asked for keychain read permission over and over again. This was because OS X couldn’t validate the apps’ signatures and therefore didn’t recognize them.

If you’re working on a Macintosh app and you want to support 10.6, you’ll need to do some extra steps when building it. If you’re not, then the rest of this blog post will be really boring!

For a full explanation of the issue involved, please read the linked blog posts above. They were a great start for me, but didn’t give precise enough step-by-step instructions. In the hope of saving someone else from the hours of trial and error I wet through, I’ve listed the steps I followed below. It worked for me every time. The one crucial difference from the referenced blog posts I think is in step 2, booting into 10.6 before exporting the designated requirement.

Leopard-Compatible Code Signing Using Developer ID

  1. Build your app using Xcode 4.3. This may be painful if you’ve been building in Xcode 3, but fix up the errors as best you can to get a successful build.
  2. Boot OS X 10.6 (I have it on a second hard drive in my MacBook Pro, which is handy), get the app that you built in step 1, and run the following on it:
        codesign -d -r- <path to app>
  3. Find the line in the codesign output that starts with “designated” and store that line in a text file named designated_requirement.txt in the root folder of your project.
  4. Boot your normal development environment (for me this is 10.7).
  5. Discard all those changes you made to your project in step 1 by doing whatever command your revision control system has for that purpose. 
  6. Open your app’s project in Xcode 3. Don’t set code signing as an Xcode build setting. Instead, add a custom build step at the end that looks something like this:
        codesign -f -s 'Developer ID Application: (your company)' \
        -r $SOURCE_ROOT/designated_requirement.txt \
        $BUILD_DIR/$CONFIGURATION$EFFECTIVE_PLATFORM_NAME/<name>.app
  7. Build it in Xcode 3.
  8. Verify the app’s signature using the codesign utility:
        codesign --verify -vvv <path to app>
  9. Boot OS X 10.6 again, get the app you built in step 7, and verify it again:
        codesign --verify -vvv <path to app>

    In both cases you should see output like this:

        Arq.app: valid on disk
        Arq.app: satisfies its Designated Requirement