As I'm sure many readers have heard, there has been some public outcry lately on the subject of iOS apps accessing the Address Book contacts of a their users and then sending the whole lot of them off to their servers, to accomplish their "friend matching" features.
Many companies have already corrected the error in their ways, (partially), and even Apple has stated that a future iOS release will lock down Address Book access, in the same way that permission is required to access a user's geographic location now.
In the meantime however, if you'd like a quick, easy and safe way to build a "find my friends" type of feature into your app, I'd recommend looking at DTSHashedContacts.
It's is a drop-in iOS library that provides a wrapper around the Address Book frameworks designed to ensure the privacy of user data. Before access is ever made to the Address Book the user will first be prompted for permission with a customizable UIAlertView prompt. Once access is granted the library returns hashed tokens representing the user's private data rather than the data itself.
Here's what it looks like to use it:
[hashedContactsProvider emailTokensWithConfirmation:^(NSArray* tokens) {
//When permission given
} whenDeclined:^{
//When permission denied
}];
Read more about DTSHashedContacts on Github
Building iOS and Mac projects from the command-line could be a lot easier to work with.
Hopefully this post will give you a couple ways to make that happen.
I wanna talk about two different little tools that help ease the process of scripting or working with Xcode projects from the command line.
xcodebuild-rb
xcodebuild-rb is a neat little ruby gem that lets you create a Rakefile inside the root of your Xcode project's folder that looks like this:
require 'rubygems'
require 'xcodebuild'
XcodeBuild::Tasks::BuildTask.new
What does that get you?
Well, after creating that Rakefile, running a quick rake -T (which will list all available rake tasks) will output something like this:
rake xcode:build # Builds the specified target(s).
rake xcode:clean # Cleans the build using the same build settings.
rake xcode:cleanbuild # Builds the specified target(s) from a clean slate.
One of the coolest features of xcodebuild-rb is it's use of "formatters". One of my favorite formatters is called "progress". You can enable it like this:
XcodeBuild::Tasks::BuildTask.new do |t|
t.formatter = XcodeBuild::Formatters::ProgressFormatter.new
end
Then when you build using xcodebuild-rb, your output will look something like this:
Building target: ExampleProject (in ExampleProject.xcproject)
=============================================================
Configuration: Release
..............
Finished in 2.226883 seconds.
Build succeeded.
Read more about xcodebuild-rb on Github
xcodearchive
Apple ships Xcode with a command line tool called xcodebuild, which as the name suggests, builds an Xcode project. One drawback about the built-in xcodebuild tool is that it can't create .ipa archive files.
Well, enter xcodearchive.
Unlike xcodebuild-rb, xcodearchive isn't a ruby gem. It is just a .rb file that you can put anywhere you'd like and run.
xcodearchive has a ton of great features, check out the USAGE output:
Usage: xcodearchive [OPTIONS]
--version
Show version number
-v, --verbose Output more information
-g, --growl Show growl alerts to inform about progress of the build
-n, --do_not_keep_dsym_symbols Do not keep the dSYM symbols
-s, --show Show archive in Finder once created
-c, --clean Do a clean before building the Xcode project
-o, --ipa_export_path FOLDER Set the path of the folder where the ipa will be saved. Default is '~/Desktop'
-i DEVELOPPER_IDENTITY, Force the developper identity value
--developper_identity
-p, --project PROJECT Specifiy xcode project
-h, --help Display this screen
Read more about xcodearchive on Github
If you aren't already automating the tedious parts of your build and release processes, you are missing out. As any iOS developer knows, building and releasing can become some of the most monotonous and annoying parts of our jobs, hopefully these little tools will inspire you to start scripting your way to a smoother build/release cycle.
Yet another example of details that 99.9% of users would never notice but use constantly.
The iPad’s split keyboard has phantom buttons. If you’re used to typing Y with your left hand, you can.
To enable this keyboard, tap-hold on the “toggle keyboard” button in the lower right to get a menu, or tap-hold on it and drag upwards. Reverse that to reunite the two halves back to normal at the bottom.

I love discovering little tid bits like this. Apple (among others) manage to sprinkle them in the strangest and most obvious places.