Code Workshop

Xcode Build Setting Transformations

2015-08-08T12:50:13-06:00

Xcode supports the ability to substitute the value of build settings using the $(BUILD_SETTING_NAME) or ${BUILD_SETTING_NAME} syntax in a number of places including Info.plists, other build setting values, and .xcconfig files. In these substitutions it’s also possible to add operators that transform the value in various ways. You may have seen one of these in the Info.plist included in project templates:

com.company.$(PRODUCT_NAME:rfc1034identifier)

This results in the value of the PRODUCT_NAME build setting being transformed into a representation suitable for use in the reverse DNS format used by CFBundleIdentifier. So if PRODUCT_NAME is “Whatever App” the resulting string is “com.company.Whatever-App”.

These transformations can be quite useful but don’t appear to be documented, so here’s the list of available operators and what they do:

Operator	Returns
identifier	A C identifier representation suitable for use in source code.
c99extidentifier	Like `identifier`, but with support for extended characters allowed by C99. Added in Xcode 6.
rfc1034identifier	A representation suitable for use in a DNS name.
quote	A representation suitable for use as a shell argument.
lower	A lowercase representation.
upper	An uppercase representation.
standardizepath	The equivalent of calling stringByStandardizingPath on the string.
base	The base name of a path - the last path component with any extension removed.
dir	The directory portion of a path.
file	The file portion of a path.
suffix	The extension of a path including the '.' divider.

Note that these operators can be chained, so you can do things like $(PRODUCT_NAME:lower:rfc1034identifier) or $(CONFIGURATION:upper:identifier).

An Objective-C API Diff Tool

2014-06-17T19:26:33-06:00

For the last year most of my work has been in Objective-C framework development. With each release I would look through a diff of the headers since the previous release and make note of the API modifications so that users of the framework could easily see what had changed. While not terribly time consuming it was tedious and required some care, especially when declarations were relocated. Having previously contributed to the ObjectDoc project’s Objective-C wrapper for libclang, this seemed like a good opportunity to make use of that work and put together a tool to automate the diff generation. The result is objc-diff, a libclang-based tool to generate an Objective-C API diff report.

The reports generated by the tool (example) are similar to those provided by Apple for the system frameworks, with a couple of improvements:

When a class or protocol is moved to a different header a relocation is reported only for that entity rather than it and all of its methods and properties. The relocation of the children is implied and this eliminates a lot of noise from the report.
Conversions between explicit accessor methods and @property declarations are reported as modifications to the declaration rather than a series of additions and removals. This more accurately describes the change and makes the actual additions and removals easier to identify.

Binary releases are available on the project page, and the source is available on GitHub.

Clean File Templates for Xcode 4

2013-02-01T07:47:42-07:00

When creating new classes through Xcode I tend to delete just about everything provided in the default file templates. The information in the comment block headers is better tracked by a source control system and I often don’t want the default method implementations. To support this I’ve created a set of file templates that include nothing but an #import appropriate for the base class and an empty @interface and @implementation.

To install these templates create ~/Library/Developer/Xcode/Templates/File Templates if it doesn’t already exist and clone the GitHub repo into a sub-directory name of your choice (I use “Clean”). This directory name will appear as a category in Xcode’s new file dialog. Once installed you can use these instead of the normal Cocoa / Cocoa Touch templates and enjoy one less step when adding new classes to your project.

Disabling Xcode 4.6's Garbage Collection Warning

2013-01-28T19:21:37-07:00

Xcode 4.6 generates a Target Integrity warning if the build setting GCC_ENABLE_OBJC_GCC is set to a value other than “unsupported”, stating that garbage collection is deprecated and encouraging you to migrate to ARC. However, for targets like System Preference panes garbage collection support is still required so GC is enabled for a good reason. In such cases this warning is annoying and there is no obvious way to turn it off. But it turns out that with a little build setting manipulation it is possible.

Set the default value of GCC_ENABLE_OBJC_GCC to “unsupported”, then expand the build setting and for each configuration add a per-architecture setting with a value of “supported”. If you’re using GC for multiple architectures do this for each supported architecture, as using “Any Architecture” will still cause Xcode to complain. You should end up with something like this:

This silences the warning and allows you to continue to build with GC support, at least for now.

Update: This works in Xcode 4.6 through 5.0.2. Support for garbage collection was removed in Xcode 5.1.

Power Nap and the Network

2012-10-18T15:25:34-06:00

With the introduction of Power Nap developers have something new to think about: applications running while the system appears to be asleep. Every hour Power Nap enabled systems partially wake up and any running applications will briefly execute with disk and network access. In most cases this works just fine, but for some apps it can result in behavior that the user does not expect. For example, consider apps like instant messaging and IRC clients that advertise the presence of a person or service. Every hour they will reconnect to their networks and make it appear as if the user is available when they really aren’t. Such reconnections can also cause downright annoying behavior like the AIM multiple sign-in warning, improper redirection of incoming messages, or an offline IRC buffer being sent to the wrong device.

For apps like these the behavior is likely caused by the application attempting to reconnect in response to a closed connection or low-level network state notifications. Previously this worked as expected because the reconnection code did not run until the user woke up the system, but under Power Nap it is running while the system is still asleep from the user’s point of view. Apps that run into trouble here will need to suspend their reconnect behavior until the system is fully awake, and fortunately this is pretty easy to do. The partial wake state used by Power Nap is known as Dark Wake, and while in this state the NSWorkspaceDidWakeNotification and SCNetworkReachability callbacks are not sent. As a result a simple solution is to watch for the NSWorkspaceWillSleepNotification and disable reconnects or network state observers until an NSWorkspaceDidWakeNotification is received. Alternatively an application can adopt the SCNetworkReachability APIs if possible and rely on those callbacks to inform the app when it is appropriate to reconnect.

If you want to test your changes without waiting an hour for Power Nap to kick in an easy way to trigger Dark Wake for a few seconds is to put the system to sleep then connect or disconnect AC power or a peripheral. This is also useful for testing a direct transition from Dark Wake to full wake by connecting power then pressing a key to wake up the system.

Notification Center Updates for Homebrew

2012-07-25T16:12:20-06:00

I’ve modified my Homebrew update notification script to use Notification Center thanks to terminal-notifier, a growlnotify replacement that allows posting to Notification Center from the command line. The script now looks like this:

export PATH=/usr/local/bin:$PATH
notifier=/Applications/terminal-notifier.app/Contents/MacOS/terminal-notifier

# Give the network a chance to connect
sleep 10

brew update > /dev/null 2>&1
outdated=`brew outdated | sort | tr '\n' ' '`

if [ ! -z "$outdated" ]; then
    $notifier \
        -group net.codeworkshop.homebrewupdate \
        -title "Homebrew Updates Available" \
        -message "$outdated" \
        -activate com.apple.Terminal > /dev/null 2>&1
fi

The launch agent remains the same, checking for updates every day at 6:00 p.m. or the next time the Mac wakes from sleep. To install, first download terminal-notifier and place it in your Applications folder. Then download the script files and move homebrewupdate into /usr/local/bin and net.codeworkshop.homebrewupdate.plist into ~/Library/LaunchAgents. Then load the launch agent and you should be set.

launchctl load ~/Library/LaunchAgents/net.codeworkshop.homebrewupdate.plist

If you’re upgrading from the Growl version you only need to replace the homebrewupdate script. The launch agent works just as before.

Switching to an Inexpensive Code Signing Certificate

2012-07-19T06:40:38-06:00

For the last few years I’ve been using a code signing certificate from Thawte. At the time I just wanted to get my app out the door and some quick research turned up Thawte as a popular choice and a trusted certificate authority on every OS version I was targeting. The $275 a year fee always annoyed me a bit though and with the introduction of Gatekeeper meaning that I’ll only be using the certificate to silence scary warnings on Windows I decided to look into less expensive options.

The reason certificate prices vary so widely is a combination of reputation and OS support. By purchasing a certificate you are linking yourself to the certificate authority’s good name, so if they have a more widely known name supposedly that is better for you. In practice very few people care what CA your code signing certificate comes from as long as it works. OS support is also not likely to be an issue. CAs that have been around for a long time are trusted by default on more operating systems, with the big names going all the way back to Windows 95. There is a slim chance this matters to you for an SSL certificate, but for code signing you only care about the CA being trusted on the oldest OS your software supports. In my case that’s Windows XP and this opens the door to other options, namely Comodo and any of its resellers. Comodo’s direct price is $170 a year but from a reseller you can get that down to $90 a year or less.

After some searching I decided to buy from K Software. There are slightly cheaper options out there but K Software has a great site, documentation to guide you through the whole process, and a lot of positive mentions on developer blogs. I pulled the trigger and after responding to a couple requests from Comodo I had my new cert a few hours later.

The certificate you receive comes directly from Comodo and doesn’t involve the reseller in the certificate chain in any way. This means that you can renew through any other reseller or directly from Comodo in the future, and anyone looking at the certificate won’t know who you actually bought it from.

To double-check OS compatibility I signed my app with the new certificate and tested it on Windows 7 and an up-to-date version of XP. Then I fired up a virtual machine running a clean install of XP from a 2002 retail disk. Without any updates or service packs applied the app’s signature verified just fine, and if it works there it will work anywhere.

I was initially on the fence about buying from a reseller because the price difference kept making me wonder what the catch was. But after looking into why the difference exists and seeing the results for myself I can’t see any reason why you wouldn’t go for the best deal that supports your oldest target OS. The next time you’re in the market for a code signing certificate I highly recommend giving the inexpensive options a look.

Filtering Sparkle Release Notes with JavaScript

2012-02-21T12:25:59-07:00

Up ‘til now I’ve been using the description field in my Sparkle appcast to display release notes. It’s easy and I like showing users just the notes that are relevant to the update. The downside to this approach is that if someone doesn’t run the app often they are likely to be a couple releases behind and not get the full picture. This is especially true if I’ve recently released a significant update. Such updates usually have the most important notes and are usually followed pretty quickly by a patch release. Unless the user runs the app before the patch release goes out they’ll miss the good bits.

There are a few ways to deal with this. The simplest is to use the releaseNotesLink field and just show release notes for all versions every time, leaving it up to the user to look at the version numbers and figure out what is relevant. Another option is to append a “new in $(last significant update)” section to the description HTML as Apple does. I thought about going this route, but remembered that in the apps I use sometimes it has been the smallest change that has had the most impact. If it was that One Thing that drove me nuts about an otherwise-great app that’s what I would be looking for every time.

The final approach I’ve seen is to pass the version range as parameters to the feed URL and build a custom appcast on the server. This offers the output I’m looking for but I wondered if I could do the same thing with a static page. With a little Sparkle hack it turned out to be possible and I’m pretty happy with the result.

To build this I took a page with full release note history and wrapped every release in a div with its id set to the version number. These were grouped under a parent element with nothing else in it, then I put the following in a script tag:

function getQueryParameter(name) {
    // From http://james.padolsey.com/javascript/bujs-1-getparameterbyname/
    var match = RegExp("[?&]" + name + "=([^&]*)").exec(window.location.search);
    return match && decodeURIComponent(match[1].replace(/\+/g, " "));
}

function filterVersions() {
    var currentVersion = getQueryParameter("currentVersion");
    var updateVersion = getQueryParameter("updateVersion");
    var updateVersionIndex = undefined;
    var currentVersionIndex = undefined;
    if (!updateVersion) {
        updateVersionIndex = 0;
    }

    if (!currentVersion || currentVersion == updateVersion) {
        return;
    }

    var releases = document.getElementById("releases").children;
    var length = releases.length;
    for (var i=0; i < length; i++) {
        var elem = releases[i];
        if (updateVersionIndex === undefined && elem.id == updateVersion) {
            updateVersionIndex = i;
        }

        if (currentVersionIndex === undefined && elem.id == currentVersion) {
            currentVersionIndex = i;
        }

        if (i >= currentVersionIndex || updateVersionIndex === undefined) {
            releases[i].style.display = "none";
        }
    }
}

addEventListener("DOMContentLoaded", filterVersions);

Assuming my releases are in descending order by version this will hide everything that falls outside the range parameters included in the URL. The next step was to get Sparkle to include those parameters when requesting the release notes. I replaced the description field with a releaseNotesLink pointing to the new page, then used the following tweak in the app:

- (void)updater:(SUUpdater *)updater didFindValidUpdate:(SUAppcastItem *)update {
    NSString *urlString = [[update releaseNotesURL] absoluteString];
    urlString = [urlString stringByAppendingFormat:@"?currentVersion=%@&updateVersion=%@",
                 [[[updater hostBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"],
                 [update displayVersionString]];
    [update setValue:[NSURL URLWithString:urlString] forKey:@"releaseNotesURL"];
}

There isn’t a public API to modify releaseNotesURL but there is a set method implemented so I used setValue:forKey: to invoke it and boom, release notes tailored to the updated version range without anything special running on the server.

Silent Updates

2012-01-23T09:05:47-07:00

Lately I’ve been thinking about software updates on the Mac, specifically patch releases. With just about every app that isn’t in the App Store adopting Sparkle I see that update prompt quite a bit, usually populated by release notes consisting of bug fixes and performance improvements. It’s fantastic that developers are improving the apps I use, but with updates like this I pretty much mindlessly click install, then wait while the update is downloaded and applied. Depending on the speed of my connection to the update server and the complexity of the install process I could be waiting a while.

Compare this with the experience of using Chrome or Dropbox. Both apps just install the latest version with little to no presentation to the user. Chrome shows you its Arrow of Judgement if you don’t restart the app for a while when an update is pending, but normally you don’t know anything has happened. Dropbox is able to restart itself and shows no UI at all. When using these apps you don’t have to think about software updates. You just use the app and benefit from the improvements.

For patch releases the silent update process strikes me as the better choice. Your apps improve with fewer update prompts and less thinking about software updates for everyone. I say patch releases because an across the board silent update seems like going too far for most desktop apps. The goal of a silent update process should be to refine the experience the user is familiar with. The UI and application behavior shouldn’t just change unannounced. Imagine if you were giving a presentation and launched an app to find that it had silently updated with a redesigned user interface. All the saved update prompts in the world aren’t going to make that up to you.

With this in mind I came up with some guidelines for how I would implement a silent update process:

Automatic updates are enabled by default.
Automatic updates can be disabled.
There is a method to manually check for an update.
Updates that substantially change the application’s behavior or user interface require user approval.
Updates that interact with the user during installation require user approval.

The ability to disable updates doesn’t need to be part of the UI, but it should be possible. If a user runs into an update that doesn’t work on their system they should have a way of going back to a previous version and staying there. Likewise, a manual update check doesn’t need to be obvious in the UI but should be there for users that follow your blog or Twitter feed. If they see that a new version has been released they should be able to use the software update process to get it.

I hope to implement something like this in my own apps in the near future. Besides making a small dent in the number of update prompts slung at users I think this will increase the number of updates I release. Many times I’ve made a small fix and then sat on it for weeks because it didn’t seem worthy of a release by itself. When such releases are invisible there’s no reason not to get it into everyone’s hands right away.

Update: Work is in progress to implement this in Sparkle’s quiet-automatic-update branch.

Growl Notifications for Homebrew

2011-08-25T15:53:21-06:00

Here’s a simple script I use to update Homebrew and display a Growl notification if there are any outdated formula:

export PATH=/usr/local/bin:$PATH

# Give the network a chance to connect
sleep 10

brew update > /dev/null 2>&1
outdated=`brew outdated`

if [ ! -z "$outdated" ]; then
    growlnotify -t "Homebrew Updates Available" -m "$outdated"
fi

To use it you’ll also need growlnotify:

brew install growlnotify

Add the script to your scheduler of choice and you’ll have one less thing to obsess about keeping up-to-date. I use a launch agent to run the check every day at 6:00 p.m. While not as simple as cron, the nice thing about launchd is that if the computer is asleep during the scheduled time the task will be performed as soon as the computer wakes up. The script’s sleep call is to give the network a chance to connect in this case. Incidentally, if anyone knows of a better way to delay execution until the system is on the network I’d love to hear about it.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>net.codeworkshop.homebrewupdate</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/homebrewupdate</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>18</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>
    <key>StandardOutPath</key>
    <string>/dev/null</string>
    <key>StandardErrorPath</key>
    <string>/dev/null</string>
</dict>
</plist>

If you’d like to use my setup you can download these files and move homebrewupdate into /usr/local/bin and net.codeworkshop.homebrewupdate.plist into ~/Library/LaunchAgents. Then load the launch agent and you should be set.

launchctl load ~/Library/LaunchAgents/net.codeworkshop.homebrewupdate.plist