February 1, 2013
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
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.
January 28, 2013
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.
October 18, 2012
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
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.
July 25, 2012
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:
# Give the network a chance to connect
brew update > /dev/null 2>&1
outdated=`brew outdated | sort | tr '\n' ' '`
if [ ! -z "$outdated" ]; then
-group net.codeworkshop.homebrewupdate \
-title "Homebrew Updates Available" \
-message "$outdated" \
-activate com.apple.Terminal > /dev/null 2>&1
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.
July 19, 2012
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.