"Building iOS applications with a preemie in the NICU", an 81-day bootcamp featuring alarms, crying, emergencies, life-and-death worries… and code. We are home now, but this was a rough stretch to say the least.

"Building iOS applications with a preemie in the NICU", an 81-day bootcamp featuring alarms, crying, emergencies, life-and-death worries… and code. We are home now, but this was a rough stretch to say the least.

10 iOS Developer Topics That Will Help Prepare You For Client Work

Having built more than 50 iOS applications now, many of them contract work for clients, I’ve been able to pick up some common threads, which I thought might be valuable to share.  As someone new to iOS, it can be challenging to narrow down the scope of what you should learn to prepare yourself for potential contract jobs or even steady employment at a dev shop or agency. Unless you have your own company doing a specific thing, or get a job for a company doing a specific niche type of app, you’ll probably run into these elements frequently.  I’m also assuming here that you have some Objective-C knowledge, and understanding of the iOS SDK and its basics. Build a few basic apps from the instruction books. Those fundamentals are obviously the first things to learn. 

So here’s my list, with some additional notes about why they’re good to get under your belt. 

1. Cocoapods

There are some holdouts who don’t use cocoapods, but it seems to be catching on. This is a way to centrally manage all of your app’s 3rd party libraries. You’ll probably encounter existing projects that already have it, and once you’ve got the hang of it, you’ll probably want to use it on your own projects.

2. Networking

Most iOS apps utilize AFNetworking to build the backbone of their networking code. There are certainly other ways, and some people like to “roll their own” solution, but getting familiar with AFNetworking will be valuable. It’s a 3rd party library, and has a cocoa pod if you have that setup. Get your head around REST. Understand how to create and convert JSON data structures. Learn how to set and read your request headers. Learn your networking error codes.

3. Push & Local Notifications

A lot of clients seem to “want” push notifications, even if they don’t have a real backend setup to send them. Push notifications can target specific users, but that means having a server that manages these users’ device tokens. Urban Airship is a (Portland-based) company that takes the server-side burden off of clients, and I’ve recommended them more than a couple times. 

4. Autolayout

Apple’s big shift from “springs and struts” in Xib files into a much more complicated “Autolayout” system came a few iOS generations back. With all the new iOS screen sizes, this is now critical stuff to know.  Personally I setup most of my auto layout code in the Xib, then set a few IBOutlets for those NSLayoutConstraints that might need tweaking in code. This works pretty well for most layout situations. 

5. Custom Table Views and Cells

I find that a lot of client work consists of customized table views.  These are usually table views with jam-packed cells, designed in ways that mean building custom cells with dynamic heights. It sounds like Apple may finally be addressing the nuisance of dynamic table view cell height, but up until now it’s meant a lot of extra coding.  Either way, practice building cells in different ways. 

6. Blocks

You’ll certainly see blocks throughout the iOS SDK, lots of completion blocks and what not. It’s good to practice writing some of these, as they’ll come in handy whenever you want to create some asynchronous code, sometimes with just a completion block, or maybe alternate success/fail blocks (like with networking). 

7. Delegates

Get good at defining delegate protocols, and use them. It can be tempting sometimes to fire off notifications to get two classes to talk to each other, because that might feel easier, but generally it’s best to setup a delegate relationship that is well defined and easy to follow, especially if someone else has to navigate your code.

8. Notifications

You will need to send and receive notifications via the NSNotificationCenter class, so now that I’ve made my point about delegates, hopefully it’s safe to say you will still be using a decent number of notifications. Learn how to pass data through them, and learn which system notifications are good to listen for, like when the keyboard shows and hides.

9. Web Views

Apple’s UIWebView class doesn’t give you a ton of flexibility as a developer, and we should be building a native app, really, but web views are going to rear their head more often than you’d expect. Some uses are appropriate and totally fine, and others will have you shaking your head. Regardless, it’s good to know your way around them, and make sure you understand what you can and can’t do with them. 

10. Encryption

Many clients will want to be sure their data is encrypted, either when stored on the device, or when sent to their server. Apple’s CommonCrypto library handles this, and there are several open source classes that provide a simplified interface for this encryption, such as RNCryptor. AES256 is pretty standard encryption, so get a handle on how to use it. Also learn to use the iOS keychain to store your username and password strings if your app has a login.


There are certainly other key topics (Core Data, NSCoding, NSCopying), but I’ll cut the list here for now. I think the challenge of learning something as huge as “developing iOS apps” is what to focus on. Beginning developers might be tempted to spend time in other corners of the iOS SDK that aren’t quite as useful in everyday client work, so I thought I’d help highlight some of the things that make up my bread-and-butter work. 



Goldie has BEEN our family for so long. Did my 10 years with Goldie just go by? Wait—wasn’t there going to be some time in here for that one thing we wanted to do? That trip we wanted to take? What about that plan we had? Life happens at us fast. Time waits for no man. Clichés maybe, but I feel as if I wrote them, just for me, today. 

Goldie was born in Oklahoma, and lived in California, Hawaii and Oregon. She has seen and done a lot. My life before Goldie feels as distant as life before the Internet. I don’t know what it will feel like from here on without her. 

I think we all personify our pets to some degree, but I am probably one of the worst offenders. I sing popular songs and change the lyrics to be about my pets. I make pet cartoons, pet Facebook pages. I build up huge personalities well beyond what a dog or chinchilla might actually have. Sometimes I have to remind myself that the animal I have built into a person has also been pooping in her bed, and can’t hear me when I yell a few feet from her. Losing Goldie also means losing something I’ve strangely concocted, like a piece of my personality I’ve allowed to run around dangerously outside of me.

But Goldie, the dog, is great. All my projections aside, she has been an amazing companion for Maureen, Graham and me. She will be with us always. Great pets help us get through life in ways that even friends and family have difficulty approaching. Goldie’s companionship has molded us, reinforced us, and brought us years of joy.  Today may feel like reason enough to never have a pet again, but the enormity of happiness she has brought us makes today look microscopic.

I have so many great memories with her: At Runyan Canyon, in Maureen’s old back yard on Ventura Blvd., in our backyard on Mary Ellen, Sauvie Island, the Portland Waterfront. She ate an entire roast off our kitchen counter once! She was at our wedding. Losing Goldie throws the last 10 years into sharp relief. It brings out all the good and bad lived, all with The World’s Greatest Dog at my side.


Three years ago, Goldie could still walk pretty well, but her legs certainly weren’t what they were in her youth. Maureen, Goldie and I were at the Oregon Coast, walking down through some wooded camping areas, then into some tall beach grass. I spotted a path down to the beach, and took off running full-tilt out to the water, knowing Goldie would put on the afterburners in hot pursuit. I loved to run with Goldie and hear her go all out, like a thundering horse.  Maureen yelled to stop, that Goldie shouldn’t be running, that it would be too hard on her legs. It probably was—but running all-out on the beach with someone you love is the kind of thing you’re always glad you did.

Maureen snapped this picture. 


Until our tracks meet again, Goldie, someday soon.







Sperner’s Lemma

New York Times has a fun article today on using Sperner’s Lemma to find fair rents for roommates.  It can be used to calculate a fair division in other game theory scenarios, too, and I’d imagine there are other interesting uses for it in business dealings. 

At each corner one “thing” shoulders the entire shared cost, and at the other two corers it’s free. Divide the triangle into smaller triangles, and each interior point represents divisions of those prices. The more triangles you divide it into, the more “fair” the prices become. Each participant decides if they’d be willing to accept one of the items at that cost.

Sperner’s Lemma is interesting because it bypasses potentially complex calculations for objective value, and players may give different values to things. Instead this “feels them out” to see what’s fair. The further towards the center of the triangle you get, the harder the decisions become for the players.


Why HBO’s “Silicon Valley” Would Never Happen In The Real World


The new HBO series ‘Silicon Valley' has been really fun. Mike Judge has again created something hilarious and quotable, targeting a community that is ripe for parody.

There’s just one problem: The premise of the show is almost certainly impossible.  

In the premiere our main character Richard works at a large tech company named “Hooli”, a play on Google.

Richard has built a music program on the side, which includes a revolutionary compression algorithm. When Hooli finds out about it, they try to buy it from Richard for ten million dollars. Other entrepreneurs circle, attempting to buy in.  

Hold on—would Hooli (Google) really try to buy a piece of software from one of its own employees? Back when I started at Intel, I had to sign an agreement that basically said that the company owned anything I created while employed there, regardless of where or when I might’ve conceived or constructed it. Companies like Intel, Google or Apple own their employees and all of their creative output.  

In the real world, Hooli (Google) would have just taken Richard’s compression algorithm, as Richard would’ve certainly signed something saying they owned it. If he tried to resist, they would probably sue him.

As I mentioned in a previous post, I flirted with a software engineer position at Apple, but was scared off by a similar draconian “employee ownership” policy. I asked the interviewer if I would be allowed to have any other business dealings outside of work hours, and his reply was “maybe if you were, like, selling oranges on the side of the road… but other than that, no.” You could have absolutely nothing to do with software after hours, unless you had zero aspiration of exposing it to the world.

But ‘Silicon Valley’ is still funny, and I understand that the “Hooli” setup provides great opportunities to poke fun at the “Google culture.” But I worry young entrepreneuring programmers might be misled into thinking that a job at one of these tech behemoths is a step in the right direction towards building something of your own. You might be able to work there a couple of years, learn valuable skills, leave, and then start something of your own. But are you sure you won’t come up with your great idea while still working for “mega-company”? And if you do, are you going to hide or destroy any evidence of its existence that might date it to your time at mega-company? If your idea or product is really good, are you willing to take that chance?


Silicon Valley is airing Sunday nights on HBO.