Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
NSHipster New Year's 2015

Season's Greetings, NSHipsters!

As the year winds down, and we take a moment to reflect on our experiences over the past months, one thing is clear: 2014 has been an incredible year professionally for Apple developers. So much has happened in such a short timespan, and yet it's hard to remember our relationship to Objective-C before Swift, or what APIs could have captivated our imagination as much as iOS 8 or WatchKit.

It's an NSHipster tradition to ask you, dear readers, to send in your favorite tips and tricks from the past year for publication over the New Year's holiday. This year, with the deluge of new developments—both from Cupertino and the community at large—there should be no shortage of interesting tidbits to share.

Submit your favorite piece of Swift or Objective-C trivia, framework arcana, hidden Xcode feature, or anything else you think is cool, and you could have it featured in the year-end blowout article. Just comment on this gist below!

If you're wondering about what to post, look to past year's write-ups for inspiration (2014, 2013).

I can't wait to see what you all send in!

@fpillet
Copy link

fpillet commented Dec 9, 2014

When you have objects in a NSArray, you can extract another NSArray with the value returned from a selector applied to each object using -valueForKey. This call will turn the string into a @selector if it doesn't find a property with the same name, and call the selector:

NSArray *array = <some array of NSObject> ;
NSArray *descriptions = [array valueForKey:@"description"];

The cool thing is that this works with any selector you define on your objects.

This is part of the key-value coding conventions. Relevant documentation for NSArray is here

@hborders
Copy link

hborders commented Dec 9, 2014

If you're repeatedly debugging the same problem over and over, you can run your app without rebuilding by using <ctrl>+<cmd>+r.

@jonfriskics
Copy link

Swift Playgrounds all share the same Shared Playground Data folder that's symlinked to /Users/HOME/Documents/Shared Playground Data.

If you like using lots of Playgrounds, you'll want to organize the data that each Playground is using into subfolders of that shared folder, but then you've got to let the Playground know where to look. Here's a helper function that I use that makes that easy:

func pathToFileInSharedSubfolder(file: String) -> String {
    return XCPSharedDataDirectoryPath + "/" + NSProcessInfo.processInfo().processName + "/" + file
}

That processName property in NSProcessInfo contains the name of the Playground file, so as long as you have already created a sub-folder in the Shared Playground Data folder with the same name you can access those files pretty easily, like reading local JSON:

var jsonReadError:NSError?
let jsonData = NSFileManager.defaultManager().contentsAtPath(pathToFileInSharedSubfolder("data.json"))!
let jsonArray = NSJSONSerialization.JSONObjectWithData(jsonData, options: nil, error: &jsonReadError) as [AnyObject]

or pulling out a local image:

let imageView = UIImageView()
imageView.image = UIImage(contentsOfFile: pathToFileInSharedSubfolder("image.png"))

@Fl0p
Copy link

Fl0p commented Dec 10, 2014

Cocoapods
@orta 😉

@palewar
Copy link

palewar commented Dec 16, 2014

Playground as Documentation.

And also Firefox coming to iOS and looks to be mostly done in Swift. It's still early days and a great opportunity for community to get involved with the development. Contributing guidelines are non existent and so are code comments, making it difficult to get involved. If somebody can do some digging and come up with some simple guidelines and code comments for existing code, it will be great for everybody.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment