Fair Warning: This post is relatively SimCity-centric.

The title includes some strong words, yes - but you do not want your users even feeling forgotten about. In my line of work, the user is a very central part of the development cycle. This is true in part to the intimate nature of the software I write. My software travels with the user. Everywhere the user goes - my software is living in their pocket. In fact, not only is it always with the user, but the user may also be using my software in a specific environment. How the user uses and interfaces with my software is what is known as the user experience. It has nothing to do with what the UI looks like, the shadow angle of the button when pressed or the ‘flat’ nature of the design.

The User’s Experience as a Requirement

In today’s market, the user is becoming ever more selective about the applications that they use and is raising the standards to which they will use when selecting their software using. Some of us have very specific quips about what they consider a “deal-breaker”. For me, this could be something like not making your app iPhone 5 enabled when it supports iOS 5.0+ or when you still don’t have retina assets for your app. This is inexcusable. I have heard others say that they hate when apps hijack the status bar for their own temporary in-app status. I personally love how that looks.

The above is said to emphasize that consumers care now more than ever about how their software both looks, feels, behaves, and how they can use it. If your users feel confused, nickel-and-dimed, or find using your software in any way difficult, they will most likely not use it anymore. Moreover, they will not tell their friends about it. If you screw up badly enough, they will actively tell their friends to avoid your software altogether.

A coworker recently asked me at the end of last week what I thought, based on my experience on my last iOS 6-only project, would be the best approach to starting to learn and work with autolayout. He was specifically asking if he should bother working with xib files, or simply layout everything in code. He then asked that if he were to go with a xib file, what the best approach would be to balance the time/effort workflow for autolayout.

All of the below is 100% based on my experience on my last project that was iOS 6-only, where autolayout was extensively utilized.

Autolayout Layout Construction Priority

Apple states in all of their documentation the following order you should begin implementing autolayout:

1. Nib file
2. Visual formatting language
3. Individual constraints

To NIB

The priority above is, in my opinion, very dependent on what you are working on. If you have a pretty trivial layout that is simply being constrained based on something simple like an orientation change, then a xib file will probably be your best bet for a rapid layout that is unambiguous and doesn’t give you any issue during maintenance with very little effort.

Another very helpful feature of autolayout’s constraints is the fact that you can create an outlet to a single constraint. You can use this outlet to easily animate a change, change the constraints constant, or remove a constraint altogether without much additional effort. To animation a constraint change, simply update your constraint(s), call -setNeedsLayout, then call -layoutIfNeeded in an animation block. Very quick and easy.

No Touching

However, using xibs for autolayout starts to break down and become more time than it’s worth when you get into complex layouts that depend on cross-view constraints, constraints depending on a view’s content or complex constraint sets relating to many physically smaller views (the constraints simply become an absolute nightmare to physically click on and manage in the xib without screwing something else up).

As a full-time software engineer, having my legs do nothing all day but atrophy has not been helping my legs’ health - namely my knees’ health. So this week I spent big money ($6) at the local hardware store on 4 cinder-blocks. I converted my normal desk into a standing-desk to see if I liked it at all. I’ve heard differing opinions on the standing desk ranging from “foot fatigue” to “hated it”. If you’re thinking about a standing desk, hopefully this will server as another datapoint in your research.

MacGyver

The first part was actually converting my desk into a standing desk. One of my coworkers on the project I’m currently working on had already converted his normal desk to a standing desk using cinder blocks, but I never really wanted to touch his desk for fear of it falling over. I can happily say that I trust my desk just as much sitting on top of four stone blocks as I do sitting on the floor. No issues with stability and the height is perfect.

Everyone makes at least some attempt at resolutions each new year - even if they say they “don’t make resolutions”. How can you go through life without goals to better yourself as a person? Based on my past, though, we very often do not write them down or forget about them entirely before the end of January.

The problem with goals of mine in the past have always been that they are very generic and/or very difficult to satisfy. I have made a deliberate effort to make my goals for this year both small and specific. This will make it much more difficult to justify my way out of satisfying my goals for this year and much easier to satisfy more goals is they are more achievable.

Achievement Unlocked

So, in the spirit of both personal growth and gamification, I bring you a new page with my personal list¹ of “achievements” for 2013 that look like this:

Read three non-technical books

I don’t read enough. I read plenty of technical content, but not near enough book-books (some rare individuals call this “fun” reading).

1. Traffic: Why We Drive the Way We Do (and What It Says About Us) - Tom Vanderbilt

Achievements must be:

1. Specific - Specific goals have less room to be “justified” by you as “technically” completed. Examples include “Learn C”, “Run More”, etc.
2. Quantifiable - This goes with being specific. This makes it very clear as to the completion of your achievement. Did you <insert achievement title>? Yes? Achievement unlocked. Easy.
3. Achievable - If you’re a brand new engineer now, your goal should not be to become director of your department this year.

What About You?

So what are your 2013 achievements? Feel free to steal mine here if you so choose.

Update 4-15-2013: Updated for changes that came with v0.18.x and v0.17 since this page is now linked to on cocoapods.org.

Note: Cocoapods is all very new and in rapid development (currently v0.18.1 as of this update), if you are in the know and any of the below is wrong or incorrect, please let me know and I’ll change it.

If you’re reading this there is a good chance you have at least heard of Cocoapods. For the uninitiated, Cocoapods is a dependency manager for Mac and iOS projects built on Ruby and based on the Ruby community’s “rubygem bundler”. Each “pod” has a “spec” that is utilized in order to know how to integrate a given component with your project and resolve any dependencies your project may have with other libraries. I’ll be referring to these from here on out as either a “podspec” or more simply - a “spec”.

Since I’ve had some trouble easily writing my podspecs in the past (and have run into poorly-tested specs in the specs repository), I have put together a collection of knowledge on the things I have learned while building and testing my podspecs.