My Passbook and iBeacon enabled business card was something of a hit at WWDC last week. Some people wanted more detail on how it worked or how to create their own version. This post describes the process, from the perspective of a software developer. If you're not a developer, there are numerous web sites that will help compose Passbook passes, but I can't personally vouch for any. The very basics: A Passbook pass is defined by a JSON file. Put the JSON file and any images the pass uses in a folder, and then use Apple's signpass tool to zip it up and sign it. Now you have a pass. Upload that to a properly-configured server and you can easily share it with others. To set up any kind of pass, you'll need: A "Pass Type ID" Certificate, which…

read more →

I'll be in San Francisco during WWDC next week (though without a ticket). This is the only time of year I ever think about business cards, and this year I decided that paper business cards suck and it was time to do something cooler. Instead I'll have an electronic card distributed via Passbook. Electronic cards are hardly a new idea but (on iOS) they usually depend on both people already having the business card app. With one of those I can't give you my card unless you already have the app or I can convince you to download it. It's the dark side of the network effect. Using Passbook nicely sidesteps this because anyone using an iPhone already has the app (people who don't use an iPhone can have a paper card to stick into their horse's…

read more →

If you're writing an iOS app and you need to know the user's current location, the answer is straightforward: use Core Location. That fires up device GPS (when available). Apple's A-GPS combines this with things like local Wifi networks and IP addresses to work out the device's location. All of this, of course, assuming that the user allows your app to know their location. That's great if you actually need nearly-exact location information. But what if you don't care about that? What if you just want to know, say, what country the user is in, or even what continent? You could of course still use Core Location. But if your app doesn't normally use location data in an obvious manner, users would reasonably be suspicious if you suddenly want…

read more →

Over at the Big Nerd Ranch blog, my friend Mark Dalrymple continues his "Inside the Bracket" series with an article on practical uses of Objective-C's run time introspection.

Last time you saw the parts of the Objective-C runtime API that let you query a bunch of the metadata the compiler keeps around once it’s done building your project. Like most discussions of API, it was pretty abstract. “Look at all the pretty tools! Ooh, we can print out Lists of Stuff! Isn’t that amazing!”

This time around is an actual application of this API for Great Justice. I was working on a client project that consumed blobs of JSON data from a third-party web service.

Converting JSON to Objective-C objects is fraught with some peril, but with the code Mark presents it becomes a lot safer.

Mark's code, incidentally, is an improved version of some code I wrote and discussed on Cocoa is My Girlfriend. Mark's version is better, though.


This week was DBX, Dropbox's first ever developer conference. The big news as far as I'm concerned is their new Datastore API. In a break from their file-oriented past, Dropbox now has an API for syncing structured data between devices. I've long been a happy Dropbox user and I've lately been a frustrated iCloud developer. So the question is, should I care? Should you? Some of the hype has suggested that the new API is an "iCloud killer". As I've previously discussed, the term "iCloud" covers a lot of ground. Some of it, like file syncing, Dropbox already does. The new API is being compared to Core Data's iCloud integration, hence my interest. Here I'm going to run through the Datastore API with an eye toward seeing how it compares to…

read more →