Reflecting on 6 Years as a Full Time iOS Developer
I’ve been working full time as an iOS developer since 2014. Before that I was a full-stack web developer.
I was reluctant to get into mobile development at first, never quite accepting what I saw as Apple’s usurping of the web. I saw it as a usurping because as soon as the iPhone came out, web developers were no longer at the cutting edge of progress.
The iPhone was a bit of a shock to the web. It quickly became apparent that for an organization to remain relevant it would need a presence on the App Store. And to get on the App Store, you must go through Apple’s approval process.
Prior to the iPhone, the web was the premier software distribution platform for indy and corporate producers alike. On the web, anyone can publish anything at any time. No gatekeepers. But after the iPhone, in order to reach the widest audience possible, developers had to start subjecting their work to a behemoth corporation to be approved or denied at its discretion.
I recall quite a bit of internet-outrage at the time from myself and other developers accustomed to free reign. But apparently it was easy to ignore and Apple remains unstoppable to this day. Adapt or die.
Anyway, writing software for iOS has been overall quite rewarding. At the heart of the platform is a fundamental appreciation for art.
You can tell when something was created through intrinsic motivations, birthed with a love for the fusion of engineering and art. And while they remain the legal property of a corporate monolith, preserved in Apple’s APIs is a reverence for creative endeavors.
iOS is more restrictive in terms of what you’re allowed to do than, say, Android and in some ways this is unfortunately restrictive but in other ways it is ironically liberating.
You can think of Apple’s restrictions and guidelines as a form of insurance against stupid ideas. For example, imagine that you’re working full time as an iOS engineer at software startup X. It is inevitable that management at startup X will dream up some ridiculous new gimmicky feature promised to make boat-loads of dough. Such features are inevitably annoying and eye-rolling for engineers to work on. However, as an iOS developer you are somewhat protected by Apple’s guidelines which contain provisions against gimmicky, anti-user practices.
Many (perhaps most) developers spend their days compelled by their employers to do work they wouldn’t otherwise be interested in performing. One is less likely to find meaning in such work. But meaning can be had when one can focus on creating an excellent user experience in a product people enjoy using under their own volition. And from what I can tell, although much of it is legal ass-covering, Apple’s user interface guidelines and approval process are largely designed with these user-centric ideals in mind.
Another benefit offered by iOS is tight control over the user experience. When developing for iOS hardware you can expect a relatively uniform experience across devices which means less time tweaking your software to suit the idiosyncrasies of a specific device or flavor of OS.
As far as developer tools and the developer experience in general, Apple leaves a lot to be desired. XCode is notoriously sluggish and unstable where force-quitting is a routine occurrence. And it is behind feature-wise in terms of what you’d expect from a modern IDE. And it can be painfully slow to compile unless you’re coding in pure Objective C. There is one alternative I’m aware of, App Code by JetBrains, which offers a better coding experience but unsurprisingly, being Java based, it simply feels alien on Mac OS.
Continuous integration, fortunately, is made bearable by open source developer tools like Fastlane and Jenkins but you inevitably must interact with TestFlight, and App Store Connect which is one of the most consistently slow and unresponsive web-based interfaces I’ve ever experienced.
While they get the job done eventually, it is clear that Apple doesn’t invest as much in the refinement of their developer tools as they do in their consumer-facing experiences. This is somewhat understandable as this is what the majority of their customers see. But it’s perplexing given that it costs developers $100 a year just for the privilege of appearing on the App Store, not to mention the 30% commission on sales.
Although it leaves you expecting more from their developer tools, $100 a year in addition to Apple’s approval process is enough of a barrier to prevent millions of low quality apps from muddying up search results. So at least you are likely to get more engagement with your creations on the App Store than elsewhere.
Additionally, iOS users, as with other luxury brand consumers, are more likely to pay for stuff. So you’re more likely to make money with your apps on the App Store.
Overall, independent app developers who are typically focused on the end-product, who want to create user-centric experiences, should master Apple’s ecosystem. And by this I don’t mean hurrying to adopt every new API, extension or sub-platform that is likely to emerge on an annual basis from a company which is after all a corporate entity, like other publicly traded monoliths, trying to force innovation into a fiscal calendar.
