For me when I quit my full time job with ASMP to focus on my Mac development work the song was Maggie’s Farm, Bob Dylan. I was really into Dylan at the time and the lyrics just fit. I remember blasting it from my office and hearing it play throughout the apartment those first few indy days working at home.

I’d love to hear what songs match up to your own big indy life moments. Shoot me an email or tweet me your story.

I could get into some real heavy talk regarding Apple’s policies about installing software outside their stores (and maybe I will someday) but for now let us all be thankful that not all Mac software must come to us through Cupertino. Let us also be thankful for Gatekeeper, a nice compromise Apple offers.

With Gatekeeper, Apple allows people to distribute Mac software outside the store but requires it be signed with an identity registered with Apple. The general idea being if a developer gets marked as distributing malware Apple can blacklist them so as to not effect users in the future. I’m not aware of any honest developer being wrongfully blacklisted and my general understanding is that the program is working well with known limitations.

OS X ships with a nice safe default via Settings > Security,
“Allow apps downloaded from:” set to “Mac App Store and identified developers”. Unfortunately even though Gatekeeper has been around since 10.7 there are some apps that are not signed nor will never ever be signed that you want to run. Most users will sadly turn off the Gatekeeper check entirely at this point, leaving their system vulnerable. Below I’ll walk you though how to allow a unsigned app to run while leaving the security setting as-is.

By default OS X ships with the setting set to “Mac App Store and identified developers”.

When you try to open an unsigned app you’ll get a prompt like this:

Click OK and then go back to System Preferences and you might notice the pane has changed:

Now you can choose to “Open Anyway” for the last app blocked by Gatekeeper. Go back and try to launch the app again. You’ll get a final prompt asking if you sure, and upon clicking Open you’ll be able to run you unsigned app while still maintaining the default security setting.

While a little tedious jumping back and fourth for the initial approval, I’d much rather do this and leave Gatekeeper on than to run without the identity check. I highly recommend you do so too, and if you can, maybe a friendly email to your app developer asking him to sign his app.

UPDATE: Was informed by @boredzo and @ abrahamvegh that there is a shortcut to this flow if you anticipate the app requiring approval. For example, if you download an app you know will need this special exception you can control-click it and choose Open from the context menu. Doing so will cause a similar prompt that will whitelist the non-signed app and allow you to run it without turning off Gatekeeper. Thanks for the extra info guys!

While user interface design is not a core responsibility at my current job I do believe it is an important skill in my field and I try to improve all the time. A large aspect of user interface design is choosing the right words. For example, a good UI designer when crafting an iOS alert will honor and consider Apple recommendations. Some notes from the HIG:

Place buttons appropriately. Ideally, the button that’s most natural to tap should meet two criteria: It should perform the action that users are most likely to want and it should be the least likely to cause problems if a user taps it inadvertently. Specifically:

When the most likely button performs a nondestructive action, it should be on the right in a two-button alert. The button that cancels this action should be on the left.

When the most likely button performs a destructive action, it should be on the left in a two-button alert. The button that cancels this action should be on the right.

Give alert buttons short, logical titles. The best button titles consist of one or two words that describe the result of tapping the button. Follow these guidelines as you create titles for alert buttons:

As with all button titles, use title-style capitalization and no ending punctuation.

As much as possible, use verbs and verb phrases that relate directly to the alert text—for example, “Cancel,” “View All,” “Reply,” or “Ignore.”

Use “OK” for a simple acceptance option if there is no better alternative. Avoid using “Yes” or “No.”

Avoid “you,” “your,” “me,” and “my” as much as possible. Button titles that use these words are often ambiguous and can appear patronizing.

My personal pet peeve isn’t mentioned in the HIG but is present in almost all systems that require a user account:

Forget your password?

I hate that phrase. I find it to be patronizing and judgmental. As if I’m suppose to remember every password I ever created for every little web site and service. Who could?

Additionally, it’s misleading. If I click a link labeled “New Comment” I expect to be provided a form to make a new comment. If click a link to “Forget your password?” do I expect some flashy animated GIF that will erase some data from my brain? What I want is a link to “Reset Password”. The link title “Reset Password” is clear, focused on the target action to be performed and does not have a hint of judgement.

Sweat the little things. Read and then reread the interface guidelines. Be able to explain why for all your interface choices. Have fun.

Now that all the new bits of iOS 9 and OS X 10.11 are in the wild you might find yourself wanting to get up to speed on some of the changes. One great resource to help you get started is Apple’s WWDC videos.

The WWDC video library has a lot going for it: HD and SD video sizes, slide downloads and now even full text search! The only real negative thing is the sheer amount of content out there. It can get overwhelming and time consuming to watch all the stuff you are interested in. Here’s the hint. Like podcasts, WWDC videos are mostly single voices speaking one at a time and if you have the tools to double the playback speed you’ll find them still very comprehensible.

Now for the tools. For downloading you can of course use the Apple website. I like this WWDC Mac app as well. Once you have the video file on your hard drive you’ll unfortunately need to look for something beside the built-in QuickTime player to help. Even with all its enhancements it sadly doesn’t have this tool of QuickTime’s past. The good news is you can still download QuickTime 7 and it works great!

After you open your movie in QuickTime 7 (you’ll find it installed in the Utilities folder), use the Window menu and choose Show A/V Controls. In this panel you’ll see a slider that let’s you adjust the playback speed.

Now you can watch your chosen WWDC videos in half of the time! Enjoy!

UPDATE: My thanks to Paul Brown who let me know that the native QuickTime player can playback faster, even if it is a little hidden. To increase playback speed, bring up the controls with your mouse, then option-click on the fast-forward control. This will increment playback speed by 10% each time you click. You can keep clicking this up to 2.0x playback speed but sadly the audio does not work at 2.0x, you’ll have to limit yourself to 1.9x to retain the faster audio. Thanks again for the help Paul!

I was doing some proofreading and research today regarding the latest testing features in Xcode 7. In the process I ended up rereading this article from Mark Dalrymple on code coverage. It’s a great article but it also reminded me of a little tip I wanted to share on the blog.

Not only can this type of check help speed up your unit test times by a little bit, but, it also makes sure you aren’t loading things like crash log capture tools, performance monitoring injections, or other things that might otherwise interfere with your unit test logic or code coverage numbers. Now if you are doing the new UI testing you’ll probably have to use some other kind of flag to define this path, but regardless the core idea is the same.