Surprises when Designing an iPhone App

We launched SeatGeek’s iPhone app today. I’ve been creating websites for years, but until this project had never made anything native for a phone. As a first-timer, I was struck by some of the differences between web and mobile app design, which I’ll describe below.

First, a caveat: I worked on designing the SeatGeek app but not coding it [1]. What follows is relevant to web/app design more than development.

Designs magically look better on a Retina Display #

Retina Displays are rose-colored glasses for Photoshop comps. Take an average design and put it on a Retina Display and it will look above average. Good designs become gorgeous. This discovery makes the whole process more fun. Designing for the Retina Display makes you feel like you have an extra 20% dose of talent. The effect never fully wore off for me; each time I beamed a design from Photoshop to my phone, I was pleasantly surprised [2].

You never know what it’ll look like until it’s on a phone #

This is related to the above. Since things look different on a Retina Display, you can’t trust what you see on your computer. Things look better, but they also look different. Texture that seemed over-the-top in Photoshop is almost invisible on a Retina Display. A button that may seem appropriately-sized on your monitor looks far too small on a 320 x 480 display. So I got into the habit of constantly checking my work on a phone. Silkscreen proved invaluable for this; I recommend it.

Designing for 1x requires more than just downsizing #

My first attempt at turning one of my 2x comps into a 1x version was to just decrease the image size in Photoshop. That was naive. Some elements don’t scale well when simply downsized; they require special attention.

The version is on the left is a 2x PSD with its image size cut in half. The version on the right is the same interface optimized for 1x. There are a number of problems in the left version: the stroke around the options button is fuzzy, the white inner shadow in the upper-right info button lacks clarity, the lower border on the top bar is too strong. These visual bugs are fixed in the optimized version [3].

Then again, maybe you should just downsize and move on #

Perhaps it isn’t worth optimizing for 1x. As fewer folks own pre-Retina iPhones, you’re spending a lot of time catering to small group of users. The crudely downsized version isn’t pixel-perfect, but it’s still usable. For all future SeatGeek iOS work, we’re going to approach 1x iPhones like we approach IE7–we’ll make sure that the experience is solid, but won’t require it be perfect.

Simple things can be damn hard #

Our app’s home view has a little tagline below the main search bar: “Your ticket to every ticket.”

In the PSD, the word “every” was bolded, which makes the phrase more intuitive. It seemed like a simple thing to implement–there must be an iOS equivalent of the <strong> tag, right? Apparently not. Eric, our CTO, spent a long while messing around with NSAttributedString and a couple of open-source libraries before finally giving up and using an image in the interest of time. We talked to more experienced iOS devs who confirmed that bolding a single word is indeed non-trivial.

Interface iteration is more cumbersome #

We should have finalized our design before we began coding. We didn’t, and it created a lot of additional work. On the web, I’m used to a workflow where a backend developer can create a page’s core logic and a designer can then beautify everything. Or the designer can do their work first and the backend engineer can hook up the UI afterwards. That fluidity doesn’t exist with the iPhone. When we wanted to make UI changes late in the game, it slowed everything down.

On the web, a designer is often comfortable with frontend markup. HTML/CSS are accessible and easy to learn, even for those without a programming background. Objective-C is not. So on the iPhone, the technology draws a bigger barrier between the person creating the design and the person implementing it. Iterating on the interface involves more friction [4].

Provisioning and distribution is a nightmare #

Want to set up your phone to test local builds of your app? If it’s your first time, hopefully you have the entire afternoon free to figure it out [5]. Otherwise, it’s not going to happen. Want to set up TestFlight so that multiple people can distribute builds? It so was difficult that we never even bothered.

The Xcode/iOS distribution process needs serious work. But distribution inconveniences aside, I had a lot of fun making this app. Most core web design techniques also apply in the iOS world. So someone comfortable building web UI’s can create an interface that looks good on an iPhone without much trouble. If you’re given the chance to design your first iPhone app, jump at it.

Self-serving plug We’re hiring an iOS Developer at SeatGeek to lead all future development of this app. If you’re interested, drop me a line.

[1] I’m a little ashamed about that. I hated the feeling of being helpless when any change needed to be implemented. But that’s how we decided to divvy up the work. For context, I created the wireframes/flows for the app, designed much of it in Photoshop (but I wasn’t the only one…Chris, another engineer at SeatGeek, also played a big part), and did a lot of QA-related things. But my only Objective-C commits were trivial copy changes.

[2] I was working on a MacBook Air and Thunderbolt Monitor, neither of which are Retina. I’m guessing the effect is less pronounced if you have a Retina MacBook Pro.

[3] Most of these issues could be avoided if we always used evenly-spaced elements in the 2x version.

[4] None of this applies if the same person is designing and coding the app, which is clearly preferable.

[5] Or, at least, you’re friends with an experienced iOS developer who can walk you through each arcane step.