Adapted from a reply to a reddit post from a student considering a career in iOS:
If you really want to make iOS your career, the path isn’t as simple as endless articles and tutorials, nor is it cargo culting the “clean coding” practices used to sell books and conference talks. Though sharpening your saw has a lot of value, if you don’t learn what to build with that saw, you’ll never escape the pile of hobbyists.
Once you have enough of the basics understood, you’ll hit diminishing returns if you don’t turn your attention to the real work.
If you want a career in iOS, you must learn to ship. Learn how to take an idea and make the trade offs, compromises and refinements necessary to realize it as a finished product in the hands of real users. There’s endless prattling on design patterns and code style and everything else, but less written on how to actually get a project out the door, since writing nice code in the abstract is easy compared to shipping. But it doesn’t matter because the only real way to learn it is by doing it.
True story: I was once called in to rescue a project for a multinational corporation everyone you know has heard of. It wasn’t anything important or even customer facing, just a test of a new technology for internal, employee use. The guy they’d hired, with experience working at other big companies, couldn’t ship this (simple!) feature to save his life. It was buggy and sloppy and not making any progress despite two months of work. I came in, assessed the path between brokenness and something workable, and we had the project back on track inside of a week. But the guy had a meltdown and, uh, fired himself, because the pressure of shipping this one little thing got to him.
If you don’t learn to ship, you’ll eventually find yourself at a disadvantage at work, since the point of software is to get used by customers.
iOS has perhaps the lowest tolerances for user-facing sloppiness of anything you can get paid to code. An essential meta skill here is learning how to make a reliable, refined experience within the confines of Apple’s App Review process and other rules. But it’s not just the bureaucracy of Apple. It’s the high expectations of iOS users, who expect a reliable, intuitive experience that, by the way, maintains 60 FPS of screen drawing performance.
So you need to learn skills like how to debug weird crashes, and how to interpret user feedback to find bugs. How to profile your code to find performance bottlenecks and resolve them. How to build UI components in a way that they’re easy to iterate on based on the confusion your users are having. This is the valuable experience that helps you sift through the dogma provided in books on how to code right and actually choose practices that serve your project.
This is a lot to juggle, but when you get it right, it’s sublime. The experience of building satisfying stuff on this platform never gets old.
Some important and counterintuitive advice: write shitty code. Don’t be so paralyzed about writing something “the right way” that you don’t make progress at all. Write shitty code, then rewrite it again once you have a bigger picture of the project. Premature fancy architecture can kill you, as you write elegant solutions to problems you don’t actually have, only to rip it down two months later because it didn’t address an edge case that wasn’t visible to you at the time. Write shitty code, and then use the lessons you’re picking up to refine it once you understand the larger system better.
Remember Gall’s Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Shitty code is often a great start for building a simple system you can evolve later. In professional parlance, this need for evolution is called “technical debt,” and learning how and when to remediate it is yet another essential professional skill. The best part is, sometimes you get to throw away shitty code altogether, if the feature it was serving is canceled or de-prioritized, so building it the “right way” will have been wasted effort. The tension between code that’s good enough for right now, versus investments in code that make the project easy to enhance later on, will be present throughout your career.
If you’re going to ship things, you’re going to need to worry about design. Maybe this makes you uneasy: many people who enjoy code don’t have the same confidence with the visual arts. What you must understand is that the most important part of design is how your product works. A minimal visual design that makes it easy for your users to accomplish their tasks is much more valuable than a beautiful design that introduces friction. How it looks does matter: people don’t take ugly software as seriously. But you can get far using the basic system elements tastefully, while observing people actually using your project and improving on the steps they take to meet their goals. Confusing button? Give it a better label. Too many steps to accomplish a common task? Change your navigation around. You can get far by making things work well, even if your ambitions don’t include visual design.
So if you’re asking me, I say that once you’re confident enough from your studies to write workable code, it’s time to pick a project you want to build that solves a real problem, test it with real users, integrate their feedback, and get the code approved in the App Store. Go do that a few times and I suspect your options will be wide open. Best of all, that skillset will serve you no matter the stack or platform you’re using to build user-facing software.
Because maybe the most important advice I can offer is this: platforms come and go. Once upon a time, iOS appeared out of nowhere and changed the face of computing.
Someday, it’ll happen again. Maybe your existing language and API experience will be immediately transferrable—Apple does like to cannibalize its own products to stay on the cutting edge. But maybe it won’t be: surprises are always possible.
Either way, you’ll have to adapt.