My name is Jake Marsh.
I'm a developer, designer, and writer.

Subscribed via Push Notifications. You can also subscribe via RSS or Twitter.

Subscribe via RSS or Twitter.

Subscribe via Push Notifications, RSS or Twitter.

▸ CoreData + AFNetworking = AFIncrementalStore

Another amazing open-source project from @mattt and the AFNetworking guys: AFIncrementalStore.

AFIncrementalStore is an NSIncrementalStore subclass that uses AFNetworking to automatically request resources as properties and relationships are needed. I had noticed NSIncrementalStore in the iOS 5 docs a while ago, but it was this article that got me to realize how unbelievably cool it was.

I can't tell you how much this is going to revolutionize the way many apps integrate with their backend API systems.

Please do yourself a favor and go checkout the project's README immediately.


Cover ios 20hero

App Review: Cheddar for iOS

 •  7 minutes to read

Task management is a pretty big deal. Over the past few decades of personal computing, literally thousands of applications have tried to solve the problem of managing your "TODO" list in a sensible, useful way.

Let's see how Cheddar tackles this problem.

Read Post


Cover icon ipad 2x

App Review: Podcasts for iOS

 •  9 minutes to read

Yesterday, Apple released a new flagship iOS application: "Podcasts". Yep, only a few days after I predicted such a thing, it happens.

Let's take a look at it.

Read Post


Cover f3tgo

The Case of Missing Podcasts in iOS 6

 •  5 minutes to read

I have a theory (truthfully a wish) for the explanation behind why Apple's iOS 6 beta seems to be excluding support for browsing and downloading podcasts within the built-in iTunes Store app.

Read Post


▸ Delight Your Users By Pre-filling Forms With JBDeviceOwner

 •  3 minutes to read

Filling out forms on a phone can really suck. Heck, even on the iPad's awesome screen, I often make plenty of mistakes while typing in information.

When a user first downloads your iOS app, it's quite common for them to need to fill out some sort of "sign up" or some other kind of form.

All of this can add up to a terrible "first run" experience for new users of your app.

What's a developer to do?

Enter: JBDeviceOwner

This simple library, which comes to us from Jake Boxer, uses the name of the user's device to look up and return commonly needed user information from their Address Book record.

Here's what it looks like in action:

JBDeviceOwner *owner = [UIDevice currentDevice].owner;

// owner will be nil if the user's data could not be found.
if (owner != nil) {
  self.firstNameTextField.text = owner.firstName;
  self.lastNameTextField.text  = owner.lastName;
  self.emailTextField.text     = owner.email;
  self.phoneTextField.text     = owner.phone;
}

Jake describes how it works:

It's really simple actually.

Most iPhones are named "Jake Boxer's iPhone" ("sometimes with a different person's name instead of mine). Most iPhones have their owner saved in their address book.

JBDeviceOwner extracts the owner's name from the device name, finds the matching record in the address book, and populates the JBDeviceOwner instance with the data from the record.

If JBDeviceOwner can't figure out the owner's name, or if it can't find a matching record in the address book, it won't return anything.

Obviously this approach, while really neat, isn't going to work for absolutely every user, so you should have a sensible "fall back". I like to "try grabbing" using JBDeviceOwner, and if I don't find anything, try manually asking the user to enter their email, then using that email address to try to locate their contact record.

Try not to over-do it, but I believe when done well, this sort of approach can be an awesome alternative to requiring users to type in a ton of information.

Please Note: Try not to ask your users for a ton of information in the first place, only require what you absolutely need to make your app work.

That being said, A few big name apps are now using this technique, and their "first run" experiences are much nicer, simply prompting the user with a UIActionSheet with, for example: "Would you like to use this information?"

Check out JBDeviceOwner on Github and stop annoying your users today!


▸ Localize Your Apps With Ease Using Greenwich

Oh man, I have waited a long time for a tool like this to come around. I've even attempted to build one myself a couple times.

The process of localizing Cocoa applications has always been a bit of a chore. Various tools are available to facilitate localization of applications, but they all require a fair amount of work. Even when there is demand for localization, many applications are only available in one language. Greenwich is here to change that.

Greenwich is a new, open-source framework that greatly speeds up the process of localizing and translating an iOS or Mac app. At anytime a developer or translator (yep, Greenwich has been built with translators in mind) can make a change to a word or two, relaunch your app and see the changes reflected immediately.

Translator

Setup and usage for iOS and
Mac are very well documented on Greenwich's awesome setup page.

Do yourself a favor and check this out now, if you've ever localized a Mac or iOS app you know what a pain the process can be. Looks like we finally have a great solution.


▸ Literal Syntax for NSArray, NSDictionary & NSNumber

I can't tell you how long I've been waiting for this.

As Joris points out, it appears that Apple has committed the necessary changes to the LLVM project to allow LLVM to fully support the latest Objective-C language features.

Apple committed a new patch to the llvm project adding support for new Objective-C literal syntax for NSArray, NSDictionary and NSNumber. These have previously been documented in the Mountain Lion Xcode release notes but that was still under NDA. Now that these features have been committed to llvm I guess we’re allowed to speak about it.

...and since LLVM isn't under NDA like most of the "developer preview" stuff, this means we can all finally discuss this stuff on our blogs!

Here's a (small) taste of the great new syntax:

NSNumber

NSNumber *someNumber = @31;  // [NSNumber numberWithInt:31] 

NSArray

//NSArray *doctors = [NSArray arrayWithObjects:@"Matt Smith", @"David Tennant", @"Tom Baker", nil];
NSArray *doctors = @[@"Matt Smith", @"David Tennant", @"Tom Baker"];

NSDictionary

NSDictionary *tweet = @{
  @"text": @"Hi! I'm a tweet!",
  @"user": @"jakemarsh",
  @"timestamp": @1331664532
};

▸ Protect Your Users' Privacy With DTSHashedContacts

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 Xcode Projects from the Command Line

 •  3 minutes to read

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.


▸ The Apple Voice

Zach Holman does a great job of succinctly describing something that I've been having trouble quantifying into words for a while now.

Apple commands their words exceedingly well. They aren’t the originator — or even the owner — of their particular voice, but they are the most visible.

Mechanically, The Apple Voice is characterized by short, declarative sentences that are informally and personally delivered to you with a hint of smugness.

The Apple "voice", as Zach names it, is probably one of the most underrated parts of Apple's success.

Zach goes on to talk about how you can shape and choose your company or product's "voice".

The upshot: You need to do this. This matters, a lot.