I came across a really interesting article about the surprises of designing an iPhone app. It includes a lot of sage advice, but a few things really struck out at me.
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
NSAttributedStringand 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.
And this one:
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.
YES. A thousand times YES.
I work with and for developers who are used to developing server-side components. It drives me bananas when I mention something off-hand about iOS development and they look at me like I’m crazy. Or if I give out an estimate they think is ridiculous, I have to justify the time I will need to spend on such-and-such a feature.
Turns out, developing iOS apps is different from developing web apps. Like, hella different. For any server-side readers out there, I thought I’d hit you with a few big ones:
So, server guys, please stop making assumptions about how easy or difficult tasks are on iOS. iOS development is a completely different world from web apps and it has its own challenges and costs; don’t shoehorn your view of software development into the constraints unique to iOS.