The four pillars of iOS app development

- It's very common for people to jump into the world of iOS development and get immediately overwhelmed by a tidal wave of terminology. So you download Xcode and start to learn Swift. But with that first iOS project you will quickly encounter terms like App Delegates and View Controllers, Storyboards and XIB files, Asset Libraries and First Responders, whatever those are. Terms like Cocoa Touch, Frameworks, Automatic Reference Counting, Multitasking and App Switching and Delegation, and Model View Controller and Key Value Observing, and Provisioning and Certificates.

But, what's not apparent is the priority of any of this, what is most important here, and is there anything that's not important, can we ignore some of it, what do we need first, how do these things support and build on each other? Now while you can learn this all by just throwing yourself into it randomly, what I found more useful is to think of any iOS application you want to build as supported by four pillars, four separate areas of knowledge you need to grow equally to support the apps you want to make.

The first pillar is the tools. You start with Xcode and the iOS simulator. And there's certainly plenty to learn with those. Later you'll add another program called Instruments, and you already have this, it's included in that Xcode download. And with Instruments you can dive deep into analyzing how well your app is performing using diagnostics to make it faster and more efficient. The second pillar is the language, you need to know Swift, but more than just the syntax you also need the coding patterns that we use in iOS development like protocols and delegation, and the supporting frameworks, all the prewritten code Apple have provided to make iOS app development easier.

And the next pillar is the application design. Now I don't mean design just in the sense of things like alignment and color, but the overall design of the app itself, how we would break an application functionality and data across multiple screens, and flow through those screens. How to choose the right kind of user interface for the right part of the application, and we'll encounter the official Apple Human Interface Guidelines, or HIG for some of this, for even core questions like, "Should this application work in portrait, "or landscape, or both?" "Should it support user resizable text?" But as important as all of this, is the fourth pillar, learning the rules of programming iOS applications.

Now I've used other terms for this idea in the past, I've called this the "process" or the "structure", and those are okay, but you know the rules is better. These aren't guidelines, these are rules. And what I mean by this is that when you program an iOS application, you are not starting with a blank slate. You don't just create a new empty document in XCode and start filling it up with Swift, as if you'd been handed a blank piece of paper and you just start writing on it. No, we're in iOS, this is a controlled formal system, there is a tremendous amount of structure, already written, already defined by Apple about what it means to be an iOS application.

And we are volunteering to go along with that. So programming for iOS is less like starting with a blank piece of paper, and more like starting with a formal document, like a house contract or a tax return or say, an application for a Passport, meaning that we are given a structure, a framework, a set of rules already done. It is completely true that this Passport form could have been written in a dozen different ways. But it wasn't, it was written like this, and if we want a Passport, we'll be pragmatic, we'll read and understand, and we'll work with this structure, with these rules.

We'll see that are specific things for us to do, exact information to provide, and precise places to put it. And it's the same with iOS. When we make an iOS app, there is a structure, a framework, a set of rules already provided and we are fitting our content into that existing world. Now the huge benefit, there is a ton of stuff that you don't need to write, all the core life cycle events of a basic iOS application are already taken care of. You don't have to write any code that handles booting your application up, reacting to someone touching the icon for your app, to load it into memory, to show the first window on the screen, to keep your application alive, and running, and waiting for input, able to react to swipes and presses, that's already done.

Now likewise, you do not need to write any code to react to someone pressing the home button on an iOS device to tell your application to exit. That behavior is already baked in, it will happen. If somebody presses this button, your application is exiting, whether you like it or not. However, while you can't stop it, what you may want to do is add to that default behavior, to react to a home button press when your application is running, so you can run a few lines of your own code to quickly save the unique state of your application before it exits to the home screen.

And you absolutely can do that. But that block of code will need a very specific name and there is a particular place to put it. And that's what I mean by, the rules. That there are, predefined ways to accomplish hundreds of different tasks in iOS. And our job as developers is not to invent everything, it's often just to understand what's already there, so we can opt into it. As an example, if you wanted an app to play video, there's already a way to do it. To play audio, there's several ways to do that.

To work with the camera, or the motion detector, or the accelerometer, to animate a character across a screen, to customize a button, to load data into a table, to react to a long press on the screen differently than reacting to a short tap. All of that, and a lot more, is baked in there already, and our job is to understand it, to learn the rules, whether that's in knowing what's already there or figuring out how to customize or add to that existing behavior.

And we follow those rules all the way to how we need to sign and submit apps to the App Store. So it's not just about knowing Swift. It's not just about knowing Xcode. It's not just about being able to arrange user interface nicely on a screen. It's also about understanding the world of iOS that's provided for us, and how we fit our content into that existing world. Now while you can study each pillar independently, they are complementary. We don't want to be purely linear, it's not learn everything about Xcode and then learn everything about Swift and so on.

We develop skills in all four at the same time, and even the simplest iOS application needs us to know a little about each area. Now as we get more complex we'll build deeper skills across all of them. So let's begin with a little time in the first pillar, with Xcode 6.