Jeremy W. Sherman

stay a while, and listen

HTTP Library Survey

15th century print of skeletons dancing and playing musical instruments. Working with the Web seems to be all apps do these days. The stock Foundation URL loading system requires endless ceremony and a lot of work to try to patch it up to anything resembling watch-batteries-included.

It doesn’t have to be this way. Perhaps you’ve seen Kenneth Reitz’s quick and easy Requests library for Python.

Well, you’re not the first person to think that it doesn’t have to be that way in Cocoaland, either.

Better Dead than Red?

A quick survey of search results for “http” over at Cocoapods yields:

  • HTTPRiot

    • Inspired by Ruby’s httparty.
    • README’s documentation URL 404s.
    • Last updated 2 years ago.
    • “Get/post/delete with options” is the name of the game. See Tweet.m for how it gets woven into a model object and HRResponseDelegate for the optional (last resort) delegate methods.
  • ObjectiveResource

    • A 4-year dead port of Ruby’s ActiveResource to Cocoa.
    • Possibly also a great name for an Objectivist weekly newsletter.
  • LRResty

    • Inspired by the Ruby RestClient library.
    • README still treats ARC as new and iOS 4 as something to care about. No recent updates.
    • The website is pretty though.

Perhaps you’re starting to see a pattern:

  • Take Ruby library
  • Make Obj-C library

Tacking For the Horizon

The next few take a different tack. They also seem to be actively maintained.

  • RequestUtils

    • Hews close to the standard Foundation conventions of separating URLs from strings, but makes it easier to build a more complex request without having to repeatedly mess with a mutable URL request.
    • Simplifies form and URL encoding and decoding, with options for how to handle repeated specifications of the same query key.
    • Recently updated.

    • ARC-only.
    • Uses before/success/failure/finally-style continuation blocks.
    • Avoids manual string->URL coercions.
    • Convenient support for downloading and working with JSON, image, and file content.
  • AFIncrementalStore

    • Bridges Core Data to a REST backend.
    • Works by your telling it how to un/pickle a resource and map objects and relationships onto paths and IDs.
    • Convenient if you’re using Core Data.
    • One of those Hell-cobblestones if you’re also hooking into iCloud. (And who doesn’t want to be cloud-high these days?)
  • AFNetworking

    • Continuation-based with a reactor.
    • Minor class-splosion for handling various response Content-Types, but it’s a reasonable way to bake in support for common response types.
    • By far the most popular option of all of these (judging by Github stars, as you do).
    • Under active development.

    • I mean, you knew we’d end up here eventually.


The road to the Web from an iOS app is littered with corpses. We’re stuck with the Foundation mummy, but you might as well pick a fresher partner for your own Totentanz. AFNetworking certainly has some life left.

There’s also room for a Cocoa Toolbox site along the lines of the Clojure Toolbox. It’s great we’ve something of a dependency management system now, but without a well-curated guide, we’ve more of a run-down museum than a lively workshop.

The image above is a 15th Century print by Michael Wolgemut, found on Wikipedia. Dude’s been dead long enough we can at least use his work freely. Unless someone holds a submarine patent on display of over-half-a-millenium–old prints on the Internet. I mean, shopping carts on the Internet were a major brainwave, right? No-one would ever have thought of that.