The Changelog

Open Source moves fast. Keep up.

Mike Ash reimplements most of NSObject functionality with MAObject for educational purposes #

Mike Ash wrote a fantastic article about reimplementing NSObject. It’s really fascinating.

From his post:

The NSObject class lies at the root of (almost) all classes we build and use as part of Cocoa programming. What does it actually do, though, and how does it do it? Today, I’m going to rebuild NSObject from scratch, as suggested by friend of the blog and occasional guest author Gwynne Raskind.

He goes through memory management, inheritance, performing selectors, etc. Most of the heavy lifting is done by the runtime. It’s really amazing to see how simple it is to make this. I know I’ve thought the source code for NSObject must some crazy magic.

I highly recommend reading his article and checking out the source on GitHub.

Rack::CoreData – Automatically generate REST APIs for Core Data models #

An interesting project from Mattt to scaffold RESTful web services based on CoreData models using Rack.

require 'bundler'

# Rack::CoreData requires a Sequel connection to a database  
DB = Sequel.connect(ENV['DATABASE_URL'] || "postgres://localhost:5432/coredata")

run Rack::CoreData('./Example.xcdatamodeld')

View the Source for this project on GitHub.

SSPullToRefresh – Simple pull to refresh view for iPhone #

As I continue to dive into iOS development, I’m on the lookout for time saving Cocoa projects. Sam’s SSPullToRefresh is an easy, customizable way to add pull-to-refresh views like those made popular in Loren Brichter’s original Tweetie for iPhone app. SSPullToRefresh hides all the pulling and animating logic away, leaving you to implement what you care about – fetching and refreshing your view.

- (void)viewDidLoad {
   [super viewDidLoad];
   self.pullToRefreshView = [[SSPullToRefreshView alloc] initWithScrollView:self.tableView delegate:self];

- (void)refresh {
   [self.pullToRefreshView startLoading];
   // Load data...
   [self.pullToRefreshView finishLoading];

- (void)pullToRefreshViewDidStartLoading:(SSPullToRefreshView *)view {
   [self refresh];

You can use a couple of provided content views or you can subclass and implement your own. Check out the source on GitHub or see it in action in Cheddar.

INAppStoreWindow – A Mac App Store style Cocoa NSWindow subclass #

This is handy NSWindow subclass that lets you center the traffic lights (close, minimize, and zoom) or do custom drawing in the window’s title bar. INAppStoreWindow doesn’t use any private APIs, so it’s App Store friendly. It also supports ARC or non-ARC.

The custom drawing is really simple. You just give it a block:

[self.window setTitleBarDrawingBlock:^(BOOL drawsAsMainWindow, CGRect drawingRect, CGPathRef clippingPath){
    // Custom drawing code!    

David Keegan has a little demo app you can checkout as well.

Episode 0.7.8 – CocoaPods, MacRuby, and more with Eloy Durán

Wynn caught up with Eloy Durán, creator of CocoaPods to talk about the project, MacRuby, and his favorite Objective-C libraries. Items mentioned in the show: Eloy Durán, Ruby developer and creator of CocoaPods. CocoaPods, “the best way to manage library dependencies in Objective-C projects.” CocoaPods uses a Podfile to specify project dependencies. Eloy aspires to […]

MBRequest – Easier API wrappers in iOS and OSX #

A good API wrapper should handle network transport, payload serialization/deserialization, and authentication, abstracting these details away in order to let the developer deal with the business domain of the API. Projects like Faraday, Requests, and others have made creating higher level wrappers much easier.

MBRequest from Mobiata does the same for iOS and OSX:

NSURL *url = [NSURL URLWithString:@""];
NSMutableURLRequest *urlRequest = [NSMutableURLRequest requestWithURL:url];
[urlRequest setValue:@"gzip" forHTTPHeaderField:@"Accept-Encoding"];
MBJSONRequest *jsonRequest = [[[MBJSONRequest alloc] init] autorelease];
[jsonRequest performJSONRequest:urlRequest completionHandler:^(id responseJSON, NSError *error) {
    if (error != nil)
        NSLog(@"Error requesting top-rated videos: %@", error);
        NSArray *videos = [[responseJSON objectForKey:@"feed"] objectForKey:@"entry"];
        for (NSDictionary *videoInfo in videos)
            NSString *title = [[videoInfo objectForKey:@"title"] objectForKey:@"$t"];
            NSString *author = [[[[videoInfo objectForKey:@"author"] objectAtIndex:0] objectForKey:@"name"] objectForKey:@"$t"];
            NSLog(@"'%@' by %@", title, author);

Check out the examples folder in the project source for implementation ideas.

X-Callback-URL: URL specification for iOS interapp communication #

URLs are one of those things about the web that we often take for granted. As developers, we can request resources and send users to other destinations just by knowing a location on the Internet.

The mobile landscape is a bit different. While most mobile applications speak Web, consuming REST-ful APIs and other web resources, quite often they’re little silos of vertical, site or brand-specific functionality. Did you know that for iOS developers Apple makes it possible to register your own URL scheme, as in this Gowalla example:

The list of known iOS applications supporting OpenURL is growing daily.

Beyond application launching

As handy as these custom iOS URL schemes are in launching other applications, mobile developer Greg Pierce wants to the community to extend the idea of custom URL schemes and adopt a standard for inter-app communication. X-Callback-URL is a draft specification for one-way and two-way communication between mobile apps on iOS and looks like this:

[scheme]://[host]/[version]/[action]?[x-callback parameters]&[action parameters]

Let’s look at a real world example from Greg’s popular Terminology, a language reference app for iPhone and iPad:

  • scheme: The app’s custom URL scheme, terminology in the above example
  • host: Callback URLs are identified by a host value of x-callback-url
  • version: The X-Callback-URL spec version, currently 1.0
  • action: The action to perform in the target app. In this case, Terminology will perform a lookup action.
  • x-callback parameters: Optional. Not used in this example
  • action parameters: The parameters to pass to the executing action, “a good deal” in this example

This approach provides a robust way to not only launch an app, but also request that the app handle an action, which may or may not have a UI associated with it.

Two-way communication

The real power of X-Callback-URLs lies in two-way inter-app communication. By using the x-callback parameters in the spec, we can ask the target app to call us back on our own URLs, even handling success and error scenarios. Sort of like custom HTTP headers, these callback parameters are identified with an x- namespace:

  • x-source : The friendly name of the source app calling the action. If the action in the target app requires user interface elements, it may be necessary to identify to the user the app requesting the action.
  • x-success : If the action in the target method is intended to return a result to the source app, the x-callback parameter should be included and provide a URL to open to return to the source app. On completion of the action, the target app will open this URL, possibly with additional parameters tacked on to return a result to the source app. If x-success is not provided, it is assumed that the user will stay in the target app on successful completion of the action.
  • x-error : URL to open if the requested action generates an error in the target app. This URL will be open with at least the parameters “errorCode=code&errorMessage=message. If x-error is not present, and a error occurs, it is assumed the target app will report the failure to the user and remain in the target app.

Here’s how you’d build a URL to allow your users to select some text in your app, choose a replacement in Terminology, and have to return back to your app.


Greg has a great screencast that demonstrates the process end-to-end:

Be sure and check out the full documentation for all of Terminology’s callbacks on Greg’s site as well as implemenation examples on GitHub. If you decide to implement X-Callback-URL in your application, please add it to the directory so the community knows how to integrate with you.

[Source on GitHub] [Home page] [@xcallbackurl on Twitter] [Discuss on HackerNews]

Canabalt: Engine behind popular iOS game now open source #


In a blog post announcing their part in raising over $25,000 for charity, Semi Secret Software has released the source to Flixel iOS, the game engine behind their popular iOS title Canabalt.


A port of Flixel, the Action Script Flash game framework, Flixel iOS handles texture atlas generation, particle rendering, collisions, and animated sprites.


#import "Smoke.h"
#import <SemiSecret/SemiSecretTexture.h>

static NSString * ImgSmoke = @"smoke.png";

@interface Smoke ()
- (id) initWithGLData:(SmokeGLData *)glData texture:(SemiSecretTexture *)texture;
- (void) setupVertices;
- (void) setupTexCoords;


If your app does Twitter, check out their previously released Twitter xAuth project. Need more? Go ahead and fork the project and improve upon it.

Game over

[Source on GitHub] [Blog post]

kod: CSS3 themable, Node.js powered editor for OS X #

It’s a very Merry Christmas for Mac developers. Rasmus Andersson has open sourced Kod, the “programmers’ editor for OS X.”

Built from the ground to feel like a native OS X app, Kod sports Chrome-style tear-off tabs and aims for full concurrency, taking advantage of additional CPU cores when loading files, performing syntax highlighting, and other intensive tasks.

Even with the provided integrated scripting environment powered by Node.js, perhaps the most impressive feature for the web geek is that Kod is fully themable using CSS3.


So if you’re still waiting on TextMate 2.0 and Vim or emacs isn’t your bag, then give Kod a try.

[Source on GitHub] [Web site]

Hubcap – A GitHub client for Mac OS X #

Hubcap Dock Screenshot

We are a bit late to blog about this, but if you follow The Changelog on Twitter you would have seen tweets from us mentioning this project.

On December 3rd we chipped in to back a Kickstarter project started by Erik Michaels-Ober to fund Hubcap, a proposed native Mac client for GitHub. Erik’s plan is to bring the elegance of various Twitter clients for the Mac, including Tweetie, Hibari, Itsy, and Echofon to GitHub and increase social engagement. Obviously, we’re excited about this project, as are the guys at GitHub.

As of today’s date (Sunday – December 12nd, 2010) the Kickstarter project has 93 backers and has raised over $3000 dollars. Erik’s original goal was to raise $2222 (I’d love to know where that number came from) by December 16th, so that means this project “is on”, and awaits the release of the funding this Thursday on the 16th at 5:00pm EST.

If this is something you are interested in suporting, consider making a pledge to the cause.

Hubcap will leverage the GitHub API to display your activity feed, notifications, and inbox messages. It will also allow you to compose and send new messages, follow new people or projects, and read the news feed of individuals, organizations, or projects. Hubcap will be a Cocoa app written primarily in MacRuby.

Erik tells us to expect to have an alpha version completed in April 2011, with beta versions coming in the early summer and the 1.0 shipping in the fall. What’s the best part? Once the 1.0 ships, the source code will be made available on GitHub to everyone.

[Project on GitHub (private for now)] [Kicksarter Project]

GithubNotifier: Growl notifications for GitHub updates #

In Episode 0.3.5, Max wished for an app that would give him Growl alerts any time someone added a Homebrew formula to any Homebrew fork.

Well, Clint Shryock has created just such an app. Github Notifier is a simple menu bar application for OS X that listens for GitHub updates in any of your repos and then alerts you via Growl:

To install, you can download the latest release and drag to and launch from your /Applications folder. Add your GitHub login and API Token

Pref pane

… and set your refresh interval.

Pref pane

[Source on GitHub]

OmniGroup Frameworks: Objective-C frameworks for Mac OSX and iOS apps #

The Omni Group, makers of wildly popular Mac and iOS products such as OmniFocus and OmniGraffle, want to share some of their code with you.

The OmniGroup Frameworks are a set of Objective-C code libraries for both Mac and iOS that peform a wide range of common tasks.

  • OmniFoundation includes a set of low-level objects like OFStringScanner for scanning Unicode strings, OFRegularExpression for Regex, and OFMessageQueue & OFQueueProcessor for multithreaded operations.
  • OmniDataObjects resemble CoreData light, built on top of SQLite for Mac and iOS.
  • OmniAppKit provides types like OAOSAScript for enabling AppleScript in your app, OAPreferences for multi-pane preferences windows, and OAFindPanel for find-and-replace tasks.
  • OmniInspector is the inspector seen at work in OmniGraffle, OmniFocus, OmniOutliner and OmniPlan
  • OmniNetworking provides higher-level types to work with TCP, UDP and Multicast networking.

[Source on GitHub] [Framework forums]

SimFinger – make awesome screencasts of your mobile apps on your Mac #

SimFinger is a screencasting tool from Loren Brichter aka @atebits, author of popular apps like Tweetie for the iPhone as well as the desktop. SimFinger is a Cocoa app for the Mac that adds some polish to your mobile app screencasts by providing:

  • A frame that sits on top of the simulator and adds shine and an iPhone 3G look
  • A halo around the pointer to indicate touch events
  • Ability to set the carrier text
  • Fake apps (and dock badge counts) so that your app isn’t so lonely on the home screen.

Notice that we say ‘mobile apps’ and not ‘iPhone’ or ‘Touch’ apps because a fork from @kreutz adds support for the PalmPre simulator.

[Source on GitHub] [Original blog post] [Palm fork]