Why Swift isn't going to change the app industry just yet

Jun 8, 2014 00:00 · 1021 words · 5 minute read

One of the common reactions to Monday’s announcement of Apple’s new Swift language was that it’s lowered the bar for iOS development. We can look now forward to the dawning of a halycon age where apps have never been easier and cheaper to create.

The other way of looking at this idea is that as an established iOS developer, your industry might be about to get invaded by millions of newbies who haven’t had to earn their stripes learning the intricacies of ObjectiveC. Your rates are about to go down, and the age of demand exceeding supply is over.

Both those are simplistic, and missing the bigger point. The bar to entry to this industry hasn’t moved at all - if anything, it’s been raised.

And that’s because becoming a competent developer who can earn a professional living writing code isn’t about mastering one area, it’s about mastering FOUR.

It doesn’t matter if you’re writing mobile apps in a language that was announced 24 hours ago; or banking systems in a language that was designed by people who have since died of a ripe old age. If you don’t understand these four areas, you’ll suck as a developer.

You need to know the language, the paradigms, the frameworks and the environment of the platform that you’re building for.

Knowledge of the language

In order to build any kind of software, you need a working knowledge of the language that you’re using. To learn a language can be the work of a few hours; to master it can be the work of a lifetime.

Irrespective of where you lie along the continuum, there’s a certain minimum amount of expertise that you will need to get by. You need a working knowledge of grammar in order to make yourself understood in speech, and coding is no different - understanding the syntax of a language is a prerequisite to being able to work with it.

Knowledge of the paradigms

When you think hard about what programming actually is, it gets philosophical in a way that you might not expect. You’re in the business of taking tangible, real-world problems and reconstructing them in an intangible mental domain.

We talk about objects as if they’re concrete physical entities - but building an app is actually a process of making a whole series of imaginary constructs, and then getting them to interact with each other.

To do that, you need a working knowledge of the underlying paradigms. This is taking the physical form of the language and making use of it. In order to use objects to break down a problem, you need to understand what they are.

Knowing only the details of a specific language isn’t going to much use here - without the ability to comprehend the patterns of mental abstractions that you are expressing using the code of the language that you’ve chosen.

Knowledge of the frameworks

Knowing what an object is, and how you create one with Swift or Objective-C or whatever language you’re working with, still isn’t enough. Next, you need a knowledge of the frameworks.

While it might be possible to build every aspect of an iOS app from scratch, that’s not a practical way to work. So instead we rely on the frameworks that Apple provides. Table views are a standard control - but they behave in a particular way, and you need an understanding of how they fit together and operate in order to exploit them.

There are so many frameworks involved in iOS that it’s probably not a practical proposition to even attempt to understand all of them.

But some are unavoidable - you’re not going to get far without knowing even the basics of UIKit, for example.

To understand this takes not just a knowledge of the language that they’re built in, but also the underlying paradigms that they’re exploiting. Knowing how to set a table view’s delegate is one thing, but you also need to know what a delegate actually is.

Knowledge of the environment

Assuming a working ability with the language, the paradigms and the frameworks, you’re now in a position to start building things. But only knowing those three is missing one vital part - and that’s the understanding of the environment in which you’re operating.

The shorthand way of referring to this is user experience - why your interface is laid out the way it is, and the workflows that your app provides in order to solve the particular problem it is dealing with.

But this is a complex mix of physical contraints and psychology. Force your users to rely on voice input in a noisy environment - or large amounts of text input on a tiny keyboard - and they’ll struggle to interact with your app. Forcing them to think about how they need to interact, and they’re likely to give up and find an easier alternative.

Where does this leave Swift?

Swift doesn’t change the fundementals of what it takes to be a competent developer AT ALL. It’s possible that it might make picking up the basics slightly easier, although I’m sceptical. Go beyond the first few pages of the Swift guide, and this doesn’t feel like a toy language designed specifically for ease of learning.

What Swift doesn’t do is lower the bar to understanding the paradigms, the frameworks, or the environment. In fact I’d argue it actually raises the bar, at least for a while. It will probably be several years before you can fully get to grips with iOS without any knowledge of ObjectiveC, so for the interim you’re going to need to learn the details of two languages if you’re just starting out.

It might make building some chunks of functionality quicker, and you might find the syntax more expressive or the structure clearer to read.

But without knowing the abstract concepts of programming, and the details of Cocoa Touch, and the constraints of tiny screens in a world of continuous partial attention, you’re not going to succeed in this industry. So I’m not going to worry about being priced out of my chosen field just yet.