Xcode is a Nice Friend

A few months ago I wrote down some thoughts on the future of interaction prototyping. Those thoughts have changed in two specific ways since then. I'd like to spend a minute discussing the latter.

  1. Framer is the most promising tool for Interaction Design prototyping
  2. Getting comfortable in Xcode is a must for Interaction designers working on iOS

A few designers have written about the importance of being comfortable with Xcode. Meng To has some articles on Medium. Julius Tarng notes some thoughts as well. I'd like to add a bit to this conversation in helping designers get over the hurdle being intimidated by the IDE and Objective-C's verbose nomenclature.

Managing Assets

Without much more than a batch file drop, designers can take time of the iOS Engineers workload by simply getting confident in managing assets. Xcode makes it incredibly easy to see and manage the static image based that are part of your application. Here's an example from an App I've been working on recently.

image

Inside every iOS application is a directory named Images.xcassets. You can see it in the first pane on the left side of the above sceenshot, the selected directory. Xcode recognizes the contents and filenames of static assets placed in that folder. To add assets to that folder? Just simply drag and drop into the second pane in and bam, images added to your iOS codebase.

It is possible to manage the assets outside of Xcode, but there is a funny directory structuring and contents.json file for managing versions and sizes that makes it more difficult. The best solution, is using Xcode as is shown in the photo above.

No matter how your iOS design process works, at some point you get to that hairy asset management phase. Maybe using filenames and Slicy magic if your in Photoshop or maybe you're using Ale's Sketch Generator plugin. However you get it done, it's not fun. But you end up with a folder full of .png. If you're familiar with the naming conventions, you can drop either both regular and @2x file sizes, or just the @2x sizes right into the above window. Xcode magically integrates them into the IDE so that you can place them into your codebase, or select them from a dropdown in the attributes inspector.

Batch drag-n-dropping the images into the Imagex.xcassets directory will change the codebase and the IDE. You'll need to git push if you're simply dropping adding the images to Xcode and then you're home free.

Objective-C Nomenclature

If you're used to the anything goes, loosly typed nature of JavaScript, or just web development languages for that matter. Objective-C probably looks like something straight out of 1981 to you. The CamelCasing and oddly verbose nomenclature is definitely scary if you're not familiar with it. But, underneath the long everthing naming are some familiar programming basics we'll know from the web.

At the most basic level, it's good to know Objective-C has some familiar territory to console.log and storing text as a String. Objective-C's function for printing to the console is NSLog. How about storing at string? NSString. What's all this NS stuff about? It's a great history lesson. Remember NeXT? Yes. That's the answer.

At the core of getting confident in Objective-C is the same issue with any language, you have to read it to understand it. If you don't want to read, you're not going to start digging through the code and slowly making sense of things. Here's a really simple method.

- (BOOL)prefersStatusBarHidden {
  return YES;
}

Now, if you're confident enough, you can figure out how to write the code that makes your apps launch screen show or not show the status bar. The beneficial part about the verbose nature of Objective-C is that things basically just read out. That method reads "Prefers Status Bar Hidden", it's actually incredible helpful to be so clear.

Trust me, playing in Objective-C isn't as crazy as it sounds. Just go for it and remember to stack.

Some awesome resources if you want to look at more Obj-C

Posted February 2014