of the iOS Dev Center at developer.apple.com, with Start Your Enrollment at the bottom." target="_blank" rel="nofollow" href="#i000000920000.jpg"/>
The Official iOS SDK
The Apple iOS SDK (Software Development Kit) is a collection of tools and documentation that you can use to develop iOS apps. The main tools that make up the SDK are:
• Xcode: Apple's integrated development environment (IDE) that enables you to manage your products, type your code, trace and fix bugs (debugging), and lots more.
• Interface Builder: A tool fully integrated into the Xcode IDE that enables you to build your application's user interface visually.
• iOS Simulator: A software simulator to simulate the functions of an iPhone or an iPad on your Mac.
• Instruments: A tool that will help you find memory leaks and optimize the performance of your apps. Instruments are not covered in this book.
In addition to these tools, the iOS SDK also includes extensive documentation, sample code, How-To's, and access to the Apple Developer Forums.
The iOS SDK is available as a free download to registered members (registration is free). However, there are benefits to paid membership, including the ability to debug your code on an iOS device, distribution of your applications, and two technical support incidents a year where Apple engineers will provide you code-level assistance.
Downloading and Installing
You can download and install Xcode 7 for Mac OS X El Capitan and the iOS SDK from the Mac App Store (see Figure 1.2).
If you have a paid membership, you can download the latest version of Xcode as well as prior versions by logging in to the iOS developer portal at https://developer.apple.com/devcenter/ios/index.action.
The Typical App Development Process
Whether you intend to develop iOS apps yourself or manage the development of one, you need to be familiar with the basic steps in the development process (see Figure 1.3). This section introduces these steps briefly.
Writing a Specification
The development of an app begins with a concept. It is good practice to formally put this concept on paper and create a specification. You do not necessarily need to type this specification, although it's a good idea to do so.
At the end of the project you should come back to the specification document to see how the final product that was created compares with the original specification.
As you build your experience developing iOS applications, this difference will become smaller. The specification must address the following points:
• A short description in 200 words or less
• The target audience/demographic of the users
• How will it be distributed (App Store, or direct to a small number of devices)
• A list of similar competing apps
• A list of apps that best illustrate the look-and-feel your app is after
• The pricing model of competing apps and potential pricing for your app
Wireframes and Design
A wireframe is a large drawing that contains mockups of each screen of your app as well as lines connecting different screens that indicate the user's journey through your application.
Wireframes are important because they can help identify flaws in your design early on (before any coding has been done). They can also be used to show potential clients how a particular app is likely to look when it's completed.
There is no right or wrong way to make a wireframe. If it is for your personal use, you can just use a few sheets of paper and a pen. If it is for a client, you might want to consider using an illustration package.
Coding
The actual process of creating an iOS app involves using the Xcode IDE to type your code. iOS apps can be written in either Swift or Objective-C. This book covers iOS development with Swift only.
An iOS app typically consists of several files of Swift code along with resource files (such as images, audio, and video). These individual files are combined together by a process called compilation into a single file that is installed onto the target device. This single file is usually referred to as the application binary or a build.
Testing
It might sound obvious, but you must test your app after it has been developed. As a developer, you test your code frequently as you write it. You must also perform a comprehensive test of the entire application as often as possible to ensure things that were working in the past continue to do so. This form of testing is called regression testing. It helps to make a test plan document. Such a document basically lists all the features that you want to test and the steps required to carry out each test. The document should also clearly list which tests failed. The ones that fail will then need to be fixed and the test plan document can provide the replication procedure for the defect in question.
When your app is ready, you will want to list it in the iTunes App Store. To do so involves submitting your app for review to Apple. Apple has several criteria against which it reviews applications and if your app fails one or more of these criteria it will be rejected – in which case you will need to fix the appropriate code and resubmit. It is best to test your apps thoroughly before submitting them in the first place. Distributing your apps via the App Store is covered in Appendix D.
You must always test on a real iOS device before submitting your app for the App Store review process, or giving it to a client to test. Testing on the iOS Simulator alone is not sufficient.
If you are developing for a client, you will probably need to send the client a testable version of your work periodically for review. The recommended way to do this is by using Apple's TestFlight service, which is covered in Appendix C.
Home Screen Icon
Unless you provide an icon for your application, iOS will use a standard gray icon to represent your application in the home screen (see Figure 1.4).
To replace this icon, you will need to provide one or more PNG files with appropriate dimensions. These dimensions are listed in Table
