This page will help you understand the files and boilerplate structure of a basic iOS app. Some of the files you may never need to modify, while others will occupy much of your development time.
Depending on which language you choose to start your app, you will find different starter files in your Project Navigator panel.
In newer versions of Xcode, the file extensions are now hidden and replaced with icons. Swift files end in
.swift. Objective-C uses two files:
.h for headers, and
.m for the corresponding implementation.
AppDelegate files: This handles the application lifecycle and is the entry point for critical events in the life of your app. For instance, in
AppDelegate.m , fill in
application(application, didFinishLaunchingWithOptions:options) with any code you want run after your application finishes launching. For more, read about App Architecture
SceneDelegate files: The SceneDelegate is similar to AppDelegate in that it handles lifecycle logic, but focuses on what is displayed in the current screen instead of the whole application.
ViewController: Every screen you display will have 2 ViewController files (
.m). You will spend a large portion of your time editing these files and creating new ones.
Main (Storyboard): In more recent versions of Xcode, the Storyboard interface builder is called
LaunchScreen: Like Storyboard, but used to design the screen that is displayed when the app is first launched, but before your first view is displayed.
Assets: This is where you will add and organize image and media assets such as app icons. For icons, Xcode provides a structure for handling different image sizes for different screens and uses.
Info: This is a Property list file
Say you have a home button in your app that is 44x44 pixels. On a retina display, you would want one at twice the resolution. If you want to take advantage of the larger iPad screen, you would want one at yet another set of dimensions. In total there are four image assets-- iPhone, iPhone Retina, iPad, and iPad Retina.
This can be daunting to track in code, so instead, it's managed by an Asset Catalogue. You add one image, "Home", which would contain four assets. At runtime, you would just ask for the "Home" image, and iOS will supply the appropriate asset for the current device.
The asset catalogue is the
Assets folder. If you select this folder in Xcode, it will bring up the Asset Editor for managing assets. The screen capture below shows how to add App Icons and how to create new Image Sets. Xcode is smart enough to detect the image files you add, if the names are formatted as:
firstname.lastname@example.org and so on. The App Icon set shows the size of each icon that is expected for each slot.
You can lay out your views with a drag and drop GUI, To save time and reduce boilerplate code. These designs are saved to a
.xib file, which is loaded at runtime. The distinction between these file types is covered in a later guide. If you would rather set up your UI programmatically, for reasons covered in the Interface Builder guide, you can configure it in your
Info.plist in the
Build Settings Tab, and write the setup code in the
The Info file is a Property List or
.plist file. The
plist is a human-readable format that predates JSON, going all the way back to NeXTSTEP. It is the preferred file format of Apple. It is built with key-value pairs, with a type category as well.
Core files can be modified by top-level of your Project in the left Navigator panel.
Your project file contains all the details of your project, such as the source files to compile and build settings. You will use the General tab to set the versions of iOS and devices to support as well as orientation. You will need to use the Build Settings and Signing Capabilities when you are ready to deploy your app to the store, should you get to that point.
A basic project just produces an app, so the default project Xcode generates for you will be fine. An advanced project may produce other targets, such as static libraries, system extensions, alternative apps, test suites, and more.
For example, your shipping apps will commonly have two app targets: the app you will ship to the App Store, and an internal version of the app for testing. When you click the "Run" button in the toolbar, you want to launch the appropriate build. You can toggle this with the "Scheme Drop Down" to the right of the Run button.
The location of files in the project does not have to correlate with their location on disk. However, it's a good idea to keep things at least rudimentarily organized. It will depend on your team's conventions, but one layout might be:
ProjectName.xcodeproj src/ resources/ config/
If you move a file on disk, the filename will turn red within in the Navigation Panel, because Xcode has lost track of it. You'll need to relink the file. Click the filename, and within the Utility Panel, click the "Location" button, and navigate to the file's new location on disk.