Your first iOS Application (II): Creating a projectFebruary 4, 2017 in
This is the second episode in the series “Your first iOS Application”. In the first episode, we saw an introduction on the requirements and tools for starting developing apps for iOS. Here, you will learn how to create your first project for an iOS App, how projects are structured, and gain some acquaintance with Xcode, the tool that you are going to be using for turning your ideas into reality. Let’s start!
On the right, you will see your recent projects. For now, it’s empty, so let’s start our new project. Click on “Create a new Xcode Project” on the left.
Xcode allows you to create applications for any Apple platform, including iOS, MacOS, tvOS, and watchOS. For each of them, you have several templates available that will make your life easier by adding the necessary boilerplate code and dependencies for your particular project. To be honest, 99% of the times, when creating an iOS Application, you will just need to choose the “Single View Application” template. It will create a very simple project structure, with just one screen. Let’s click on it. A new dialog will appear where we need to configure some basic data for our newly created project:
- The first thing we need to setup is the name of the application. This name will also be the title of the App in the iOS home screen. Let’s call this (appropriately) “MyFirstApp”.
- The team of the application refers to the developer account or team this application will belong to. If you register for a developer account in the Apple developer website, you will have a pair of certificates that will be used to sign an application and identify it as your application in the Apple Store. However, you might find yourself working for different companies, with different developer accounts, and different teams and associated certificates. This team option will allow you to choose the team you are creating the app for. However, as probably you don’t even have a developer account right now, you can safely ignore this. We’ll talk about certificates and signing applications in another tutorial series.
- The organization name is related to the team and your developer account of course, and will serve to identify your application. For now, you can leave it as “My Organization”.
- Related to the previous one, “Organization Identifier” will be used to for the unique identifier for your app in the App Store. Usually, this identifier follows a reverse domain name syntax, so for example, let’s say that your organization is Digital Leaves, and your domain is digitalleaves.com, then your organization identifier will be its reverse: com.digitalleaves. As you see, we will add the application name to form the bundle identifier (i.e: your app unique identifier).
- Language: choose swift, because, trust me, you don’t want to be coding in Objective-C in 2017.
- Devices: this allows you to specify if the app’s going to be available for all iOS devices, or just iPhones, or just iPads. In our case, our first application will happily run on all iDevices, so let’s leave it in “Universal”.
Click “Next”, choose a proper directory for your project, and Voila! You have created your first iOS project, Congratulations!
Welcome, Mr. Xcode!
Xcode will generate your project structure, the basic files, and setup the compiler environment for you. This process usually takes just some seconds, after which you are presented with the main Xcode interface:
So we have four main areas in Xcode. Let’s get to know them:
The Toolbar contains the main action buttons. You will notice how minimalist this toolbar is when compared to other IDEs such as Android Studio (see picture below):
This minimalism has been, for me, one of the main allures of Xcode. Often in Android Studio I find myself lost in the many buttons and options plaguing the toolbar (it’s not show in the image, but you have also other toolbars extending through all the edges of the IDE, left, right and bottom. Anybody remembers JBuilder?).
This is the Xcode toolbar:
On the left side we can find:
- The play button allows you to run the application (or test, profile and analyze it)
- The stop button stops the current running application (if any)
- Next to the stop button we have a a selector that allows us to choose the target that we are going to run (in case we have multiple targets like an iOS App and an Apple Watch extension), and a device selector for selecting the simulator that we are going to use to run the application.
In the middle we have an information area that displays what’s going on in the IDE right now, and in the right we have two set of buttons:
- The first three will allows us to show just the editor screen, the assistant editor, or the version editor. The assistant editor is just an additional screen that splits the main one horizontally, and it’s really useful specially when designing interface elements and linking them with their code representations. The version editor is useful for checking versioning differences between files if you are using Git or any other source versioning software.
- The second three will allow you to show or hide the navigation area, the debug area or the utilities/inspectors area respectively.
The navigation area gives you access to the different information contexts of the project. Let’s have a quick overview of them:
The project navigator will show you the files of your project. This is probably the view that you will be using more. Here, you have quick access to all the files of the project. I recommend you to always keep a tidy project folder hierarchy that allows you to quickly find any file, specially when you revisit a project months after its initial development, as I explain in this article.
The project navigator is probably the most useful view of the navigation area. Here, you can easily navigate from source code files to any kind of resources, like images or asset folders, the Info.plist file containing the project’s properties, storyboards, swift files, etcetera.
The symbol navigator presents a logical abstraction of the classes and methods of your project, so if you think in terms of “This class has these methods”, it might be useful to get to a concrete function or class you want to modify. Honestly, I don’t find this view specially useful, and never use it to navigate through my project. However, your experience may be different.
You can use the symbol navigator to quickly look for a concrete method on a class, or having a quick look at all the methods of a concrete class, looking for an specific implementation. It can also be useful to locate symbols or have a general view of the data model of your project.
The Find navigator works as a “global search” view to quickly locate something in the whole project. I use it a lot to find where I’m using a concrete method or function, or where a property is used. It will also allow you to do search/replace operations globally in the project. The “Find > Text > Containing” functionality is specially relevant, and useful when you can’t locate a concrete method, a global function, or a specific constant defined in your project. I use it a lot also to look for places where I have used a specific method, to make sure it’s used properly.
Another important functionality of the Find navigator is allowing you to perform global replacements on your code. Say you want to change a variable name from “MyVariable” to “ThisIsMyVariable”. Previously, Xcode would allow you to “refactor” the code to rename this property everywhere in the project (like Android Studio does), but since swift, that functionality is not available anymore, so the replace comes in handy for these kind of replacement operations.
The Issue navigator will display all compilation errors and warning of your project. Is a view you don’t want to see frequently. When you start compiling and trying to run your projects, you will be taken to this screen frequently when there are problems in your code that need your attention. It also displays linking and runtime errors, of course. We will be talking about this section (and spending a lot of time in the debugger, of course), in another tutorial when we discuss debugging applications in Xcode.
The Test navigator is not specially useful for us right now, we’ll talk about it in a series of tutorials about testing and TDD (Test Driven Development). For now, all you need to know is that this screen is the one in charge of showing and managing your tests and allowing you to specify and take actions on those tests.
The Debug navigator shows, when running an app, some stats about the CPU, memory, disk and network usage. This is specially useful when live-debugging an application, to observe its behavior, and make sure that it’s not showing an excessive memory or CPU consumption on concrete places of the code. Of course, this screen only gives you a very high-level overview of the situation, and a more in-depth profiling is necessary to locate concrete problems and solve them. We will be talking more about debugging, profiling and measuring our app’s performance in further tutorials.
The Breakpoint navigator will allow you to set and control breakpoints, that are interruption points you set in your code to debug the application, usually when there’s some kind of error. We’ll talk about them later, in a debug tutorial series. For now, you should think on this area as a handy list of all your breakpoints, where you can enable/disable them, or have a look at which classes and pieces of code have breakpoints defined for them.
The Report navigator gives you information about what’s been going on in the project, the compilations, builds, debug sessions, etc, that you have done recently. Honestly, I never check this one, it’s pretty useless to me.
Don’t worry if this seems like a lot of information right now. You probably won’t need to access more than 2-3 of this tabs regularly, and you will get used to it just by working with Xcode. You don’t need to memorize any of this information, thankfully, Xcode is intuitive enough to let you focus in your project.
Main editor screen
The main editor screen is where you will spend the majority of your time in Xcode. It will show you an edition screen that will vary depending on the file that you are editing, from a full interface builder with visual controls for storyboards to plain code for .swift files, and everything in between.
Utilities and inspectors screen
This right panel is specially useful for choosing visual elements and controls to add to your application screens, and also inspect these elements and define their properties. We will talk about this later in this tutorial series.
Running the project
First, we are going to choose a simulator device to run our application. Click on the device selector on the toolbar, where you can see a device listed or “Generic iOS Device”.
You will be presented with a list of devices. Choose any of them, like iPhone SE. This will then configure the runtime simulator to launch an iPhone SE device to test the app.
Next, we’ll launch the application. Simply click on the play icon on the toolbar and “Voila!”, you should see the simulator starting and, after some time, a white screen will appear.
Congratulations! You have just run your first application on the simulator.
Not really fancy or interesting, right? Just a blank screen. Don’t worry. We’ll take care of that later. For now, you just can click on “stop” to finish the execution of the app.
Where to go next
In this episode of “Your first iOS App”, we delved into the process of creating a project, its structure, and got a glimpse of the Xcode IDE. In the next episode, we are going to discuss the MVC (Model View Controller) paradigm, that is probably the best paradigm for approaching the design and development of an iOS app for beginners.