If you think of the developer as the person who deals with the How of a project, the designer is the person who actually determines the What. Designers are responsible for developing what the application looks like, and the content that is inside of it. They will often approach problems from both a psychological and aesthetic point of view, trying to tie the two together to create an experience that is seamless and intuitive.

When working with a designer, communication is key. You are both trying to solve the same problems, but from very different angles; it is common to not understand where the other person is coming from. But remember, the success of the project depends on your cooperation. Taking a moment to explain a technical limitation (or to listen to feedback about your implementation of their design) will not only help avoid similar problems in the future, but will also promote trust within the team.

In addition to designers, the other role you will be spending the most time with is… more programmers. While some small projects can get by with a single programmer, it is much more likely that you'll be working with at least a few other programmers. With multiple programmers on one team, you'll be split up in all kinds of ways. Sometimes you will be evenly split between different major features. Other times each developer might be in charge of different tasks (build master, unit tests, etc.). It all depends on the needs of the project and the size of the team.

While there won't be as much of an understanding barrier between other coders as there might be with designers, there are still plenty of issues that can arise from working with other developers. It is common for every programmer to have his or her own unique style of coding, but when working on a team it is important to have at least some ground rules so that everybody can understand everyone else's code.

Sometimes, you will also be working with developers who might not be as experienced in a topic as you are (or maybe you will be the inexperienced one!). In those cases, it's still important to be patient and help those people understand what's going on. Teams thrive on trust, and you never know what that person might be able to teach you down the line.

A project manager's job is pretty self-explanatory. They need to make sure that everyone on the team is making progress towards whatever goal has been set. Perhaps more than any other role, the project manager can come in many different shapes and sizes. Every company, every team, every project even will approach the management of a project differently.

Many teams these days use some form of agile development, but the implementation varies greatly. Generally, the goal of an agile team is to work in short bursts called sprints that last for a week or two. During each sprint you'll be working on only a handful of tasks, with the intention of lightweight and rapid iteration.

On these kinds of teams, the project manager might be a dedicated person, or even a hierarchy of individuals responsible for leading small feature teams. Whatever arrangement you find yourself in, it's important to work with your project manager (or project management software) to make sure that your progress is being tracked properly.

An investor is one of the people (or perhaps the only person) who has a financial stake in your project. Investors could range from parents, to clients, to venture capitalists. The important thing is that they have put up some amount of cash to fund the project, and are most likely expecting to get a return on that investment.

Depending on your seniority in a team, or the type of project you're working on, you may or may not ever have to deal directly with an investor. While every investor you have to deal with is guaranteed to be very different from the last, it's always important to treat them with respect and honesty (unless the honesty will compromise the respect!). Remember, they're the ones putting food on your table.

Xcode is Apple's full IDE (integrated development environment) for building software for any Apple platform. First used for Mac OS X development, then expanded for iOS, watchOS, and tvOS, if you're making apps for Apple hardware you're using Xcode. Luckily, it's chock full of features, easy to use, and looks great:

Figure 1.1: The main Xcode application window

Xcode has several primary features. As an IDE, it uses a custom .xcodeproj file format to manage all of the code, asset, and configuration files that you create and import. It also has a fully-featured source code editor that is optimized for Objective-C and Swift languages, including file presets made for macOS/iOS development, and built-in documentation viewing. Finally, Xcode compiles your code and makes it easy to deploy the resulting packages to simulators, test devices, and even the App Store.

There's no reason to go any deeper than that for now, since the rest of this book is about doing exactly that. However, I would like to introduce you to some other major tools that are hidden within the Xcode application that you will be seeing again later.

The iOS and watchOS simulators are small applets that make it easy to test the applications you make without needing a dedicated testing device. With the variety of screen sizes now available on iOS devices, the chances are slim that you will own one of every size to test on; luckily, the simulators make it easy to check your app's layout on every screen size:

Figure 1.2: The iOS and watchOS simulator windows

The Apple watch is also a relatively new product. Leading up to its launch (and shortly after), limited availability of Apple Watches made it near impossible to get a hold of one for testing. Even now, it isn't nearly as ubiquitous as an iPhone, and not every developer has access to a real device. Finally, sometimes your devices are preoccupied, and you just need to test some code!

When creating an app, you spend most of your time dealing with high-level concepts, like the sequential logic of a function, or the layout of a screen. At some point, though, it is important to get a better understanding of how your app works under the hood:

Figure 1.3: The Instruments application's template chooser

Instruments is an analysis and profiling tool that can help you do just that. It is made to help you understand how your application's processes are running on the CPU to help you reproduce hard to find logic errors, patch memory leaks, and stress test different parts of your app.

Application Loader is a small application that ships with Xcode with the sole purpose of uploading data to the App Store servers. In the standard workflow of iOS development, managing the App Store side of things can usually be taken care of with iTunes Connect in conjunction with Xcode directly:

Figure 1.4: The Application Loader template chooser

However, some people prefer to use Application Loader to upload app binaries and in-app-purchase content. Essentially, they accomplish the same tasks, but Application Loader tends to be a bit clearer.

At the very core of an application is its data. In a music app, that would be the music files and associated metadata. In a contacts app, it would be a database of your saved contacts. In Twitter, it's the tweets. You get the idea. The model of an application is all about how you represent and manipulate that persistent data.

Let's use the contacts app as an example, and assume that the database of contacts is stored locally on your device. The model for that data would need to do several things. There needs to be a way to load contact information from the database into an object in code. There should also be ways to modify and save that data, for times when a user might want to change a contact's information, or add a new contact altogether. Finally, the model needs to be able to tell a controller when any of the contact data has changed:

Figure 1.6: How the model functions and interacts with a controller

While the first capability (having a container to load data into) is an internal feature of the model, the other two capabilities are essential exposures needed for the model to communicate with the controller. The controller will be capable of sending updated information to the model, which needs to be able to receive that data, format it correctly, and save it back to the database. Likewise, the model needs to let the controller know when its data has changed, so that the controller can react accordingly.

This creates a clean, separated relationship; the controller sends simple data to the model and handles general update events, while the model takes care of all the saving, loading, manipulation, and formatting.

While the model is taking care of the raw data, the view is in charge of what is actually being seen by the user. Continuing the example of a contact management app, let's take a look at how the view might be handled:

Figure 1.7: The view of a contacts app, shown interacting with a controller

Here, we can see that the view is showing the user some nicely formatted contacts. On the left is a round portrait of the person, followed by their name, and less important on the right is a greyed out word that signifies if the contact is for that person's home or work information. You can also see that the controller is sending the view the information to display, and that the view is relaying any user input back to the controller.

What's powerful about decoupling your view from all of the other application logic is that you can rapidly iterate how your app looks and feels, without having to worry about breaking any of the important logic underneath. It also keeps the amount of data needed in your model to a minimum. For example, our model has no idea that the portrait image will be cropped to a circle, or what size the font needs to be on a contact's name. The view keeps track of everything related to presentation, often in a way that is highly reusable.

We've seen how the controller works independently with both the model and the view and we've got a pretty good idea of how everything works together, but let's look at a little bit more of a detailed big picture to really see what the controller is doing:

Figure 1.8: How the controller ties everything together

Looking inside the controller, you can see that we've elaborated a bit on what's going on. You'll notice that the controller is capable of receiving notifications from both the model and the view, and then make decisions based on those notifications. It is also capable of sending updated information back to the model and the view.

This cycle repeats for the duration of the controller's existence. Listen for changes. Process notifications. Update appropriate objects. Listen for changes. Process notifications. Update appropriate objects. It's a very elegant solution that keeps your code decoupled while still making it easy for changes on both sides to be properly dealt with throughout the application.

However, this diagram shows a very generic representation of controller logic. Often when developing an app, you'll write many unique controllers that all need custom logic, and each handle things a little differently. At each controller's core though, you'll find that they all need to implement this functionality in some way.

Now, we've spent some quality time with the theory of the Model-View-Controller software architectural pattern, but I find the best way to learn is through examples. So let's take a quick look at how MVC is used on an Internet browser, something most people use every single day:

Figure 1.9: HTML is used to define the "model" of a web page

One of the most interesting parts of how the web works is that it has several different languages, and each one handles a different function. HTML is a markup language that defines the content of a web page. This means that HTML defines our model. There usually shouldn't be any formatting in an HTML file, so viewing one directly will be an unformatted jumble of source text and images. In Figure 1.9, you can see how the HTML document contains the data for the website title, along with images and captions:

Figure 1.10: The CSS files define the formatting of a web page

Separate from HTML is a style sheet language called CSS. CSS knows nothing about the data in your HTML files, and is only responsible for defining the visual rules for how HTML elements will be displayed. It determines things like the height and widths of different elements, color information, and rules for how text should be displayed. This would make CSS in charge of our view. In Figure 1.10, you can see how the CSS file results in a basic layout of a web page, such as position and size information. However, all of the content is blank, to reinforce that it does not know anything about the content that will be displayed:

Figure 1.11: The browser is the controller, and uses JavaScript to implement additional logic

Finally, we have the browser itself, which loads both the HTML data and the CSS rules to give us the final rendered page. The browser uses a third language, JavaScript, to dictate its behavior. It can receive input events like clicks and key-presses, and listens for changes in the model. It can then respond to these events with JavaScript callbacks. Our browser is our controller.

Hopefully, looking at MVC through a piece of software you are already familiar with has given you a stronger grasp of these concepts, in addition to giving you a bit of insight into how the web works! Now let's jump back to iOS and put everything together.

As I alluded to earlier, Xcode and the entire iOS toolset and APIs are built around the concepts of Model-View-Controller. I'd like to point out a few of the more obvious ways in which the concepts are enforced, but as you read through the book and eventually go out to explore and learn on your own, keep an eye out for all of the ways that MVC is present:

Figure 1.12: A sneak peek at the CoreData model editor in Xcode 8

As we've been doing, let's start with the model. Usually when working on an iOS application, your goal is to represent some kind of data. Sometimes it is a small amount of simple data, like in a weather application, and you can just retrieve it from the web on demand each time you load the app. Other times, you'll be storing and processing large amounts of data, usually in some type of database.

The simple cases don't require too much thought, but there are some great features in Swift that we'll cover in Chapter 3, Introduction to Swift 3, that make simple models easy to code, and easy to use.

For the more complex scenarios, there is CoreData, which is essentially an Apple-developed solution for building data models. CoreData is built into iOS, and a visual CoreData model editor is built right into Xcode (see Figure 1.12). This means that implementing a complex data model is fast, easy, and native to the development environment. We'll talk more about CoreData in Chapter 9, Working with Core Data:

Figure 1.13: Interface builder lets us create the views for iOS apps

Next, let's talk about views. When we talked about a web browser in the last example, we looked at how CSS dictates the appearance of a web page. On iOS, there's an even better way to build out our visual layouts: Interface Builder (see Figure 1.13). As the name implies, Interface Builder allows us to directly drag and drop UI elements in a visual What-You-See-Is-What-You-Get (WYSIWYG) editor. We can move things around, set different properties, and then even set constraints that allow us to dictate how they should look when the screen changes orientation, or when displayed on different screen sizes. This means that building views is done in a way that makes the most sense: visually. We'll be covering Interface Builder in Chapter 4, Using Storyboards, Auto Layout, and Size Classes.

So now we've discussed how to build models and views for iOS apps, and we haven't even talked about coding yet! That's a bit of a lie though, since there is a little more programming than was mentioned in the model section, but still! If we think about how MVC works, though, this should make sense. Models and views are mostly things that need to be defined; all of the action happens in the controller.

On iOS, controllers are usually implemented by creating a sub-class of a UIViewController, a class built into the UIKit framework. We could talk about UIViewControllers for hours (and in fact, we will throughout the rest of the book), so for now just know that this is where you will be doing a good chunk of your coding: handling input events, updating the views, and running supplementary logic.

The free account will be good for those just starting out, as it provides access to a handful of important features. You have full access to the Xcode developer tools, in addition to beta releases of new versions of Xcode. You'll also have access to the developer forums, where you can chat with other developers about issues you might be facing. Most importantly, however, is that you can test your apps on a real device.

The $99 account gives you everything else. This includes access to betas of new versions of iOS, all of the app services that Apple provides (iCloud, Game Center, and so on), and of course the ability to publish your app to both TestFlight and the App Store.

For most of this book, you will be able to get by just using a free account. However, there will be some parts of chapters (in addition to the entire chapter about distribution) where you will need a paid account to be able to follow along. So, let's get you set up with this one last thing before we embark on our journey!

Signing up for a free developer account couldn't be simpler. First, make sure you have an Apple ID. If you already have an iCloud or iTunes account, you probably already have one. If you'd like to create a separate Apple ID for development, you can do that at https://appleid.apple.com/, although it isn't really necessary.

Once you have determined what Apple ID you want to use for your developer account, head over to http://developer.apple.com/membercenter, and log in with those Apple ID credentials. You should end up on the following screen:

Figure 1.14: The iOS developer member center home page

If so, you're done! In the next chapter, we'll be covering everything you need to know about getting your account set up with Xcode.

Registering a paid developer account is quite a bit more tedious. When you sign up for a paid account, there are legal and financial formalities involved since you will be able to sign contracts and sell digital products on the App Store worldwide.

To begin the process, start from where the previous section left off. Make sure your Apple ID is set up properly, and log in at http://developer.apple.com/membercenter. Once you've done that, click on the Join the Apple Developer Program area at the bottom of the page (the arrow in Figure 1.14), and then the Enroll button in the upper-right corner on the next page.

Follow the instructions and fill out the information that it asks for throughout the signup process. Finally, you'll have to pay the $99 fee, and submit your application. The application usually has to go through a review period before you are approved.

Once you're approved, congratulations! You're now officially licensed to create and sell iOS, watchOS, and even Mac OS X apps on all of Apple's App Stores! All you have left to learn is… everything else.