Skip to main content
main-content
Top

About this book

App Development Recipes for iOS and watchOS explores the technical side of app development with tips and tricks to avoid those little things that become big frustrations, outside of the realm of development, causing many people to throw up their hands and say “It’s just not worth the hassle!”
The experiential nature of this work sets it apart from other iOS and watchOS books. Even if you are a developer who is completely new to Swift, iOS or watchOS, you’ll find the right experienced-based answers to important questions like “Why do I need version control?”, “Why is testing so important?” and more specific problems directly related to iOS and watchOS development with Swift. We discover and summarize the most common problems and derive the solutions; not just a short answer and screenshot, but a systematic, logical derivation, that is, how we got to the solution.
After the introductory basics, each chapter delivers a problem statement and a solution. The experienced developer may, without losing anything, skip to whatever problem with which they are currently dealing. At the same time, we guide the less experienced developer through the process with focus on solving problems along the way.
What you will learn:iOS career options for the new developer
Working with Source Code and Version Control
How to work with iOS accessory devices
Understanding development methodologies such as Agile/Scrum
User Experience Development and UI Tools
Unit, UI, and Beta Testing
Publishing your work


Who this book is for:Developers who need to find specific solutions to common problems in developing apps for iOS and watchOS.

Table of Contents

Chapter 1. Introduction

Abstract
I wrote this book for the aspiring app developer who wants to move beyond the level of hobbyist and become a true professional in the field of software.
Molly K. Maskrey

Chapter 2. Career Direction

Abstract
As mentioned in the previous chapter, we’ll discuss the three basic career options afforded to most app engineers—specifically, to iOS software engineers. There will always be variations that exist, but in general, what follows is a pretty good classification of your options. These are the three options to which I can personally speak, as I’ve tried them all. Each has its pros and cons, but only you can determine for yourself the differentiators and their importance to your future plans. You may want the consistency of a steady paycheck and are willing to sacrifice choosing what projects you want to take on and give up the freedom of your days. Or, you might go all in deciding to form your own startup to take on the world knowing the risks inherent in that path. I want to give you enough insight to choose wisely or at least to give it some thought before committing.
Molly K. Maskrey

Chapter 3. Setting Up Xcode

Abstract
In this chapter we go beyond the initial Xcode setup that most first-time developers experience to the point where we can build apps for sale and distribution.
Molly K. Maskrey

Chapter 4. Project Descriptions

Abstract
For the rest of this book I’ll be referencing four different types of projects when describing the various problems and solutions that we need to solve. I’ve purposefully kept these projects as small and self-contained as possible in order to focus on just those elements we need to address.
Molly K. Maskrey

Chapter 5. Source-Code Control

Abstract
Without a doubt, protecting the investment you’ve made developing your iOS application by preventing loss due to a system crash or other mishap has to be done whether you’re working for a company or a contractor or running your own business. Not too long ago we backed up our work to floppy disks or separate hard drives, even USB/Flash drives. When cloud storage services such as Dropbox became available, things became a bit easier, but these still did not offer the services required for maintaining more than rudimentary file backups. What we really needed was some type of version control; that is, a way to not only store back-up files but also keep track of changes so that it would be possible to revert to an earlier version if something we tried didn’t work out.
Molly K. Maskrey

Chapter 6. Development Methodology

Abstract
The thing was, however, that the soup was pretty, well, bland. It’s not that it wasn’t good or healthy or anything like that—it just had no kick. Also, I live at an altitude of 6300 feet. Water boils at a lower temperature than it does at sea level, which is where most recipes tend to be baselined. Like any project, I had to make adjustments to the process. I added this or that spice, varied the types and amounts of primary ingredients—for example, tomato sauce, meat, vegetables, and so forth. This is when cooking started to really become fun. I was experimenting, but not just trying things randomly. I varied the process depending on the needs of where I was in my development. If I didn’t think something was spicy enough, I added spice. If I thought the soup was too thick, I’d add broth or a little water. I adjusted on the fly in accordance with the needs of the process.
Molly K. Maskrey

Chapter 7. UI/UX

Abstract
We all know the value of a first impression and that you never get a second chance at one. Because there will almost always be one or more competitors to your iOS app in the App Store, if you fail to keep the user engaged from the very beginning, chances are she’ll just download the next app in the search results.
Molly K. Maskrey

Chapter 8. Targets and Schemes

Abstract
We even talked about how branches can be used by different development teams or individual engineers to test out just different types of ideas. Basically, when you want to try something different you create a branch, which in Git is a complete set of all the files and changes so far. From there, you make all the changes you want and test out your ideas. This does not affect the main branch, which is just as you left it. If your ideas don’t work out, you can get rid of the branch or just leave it as a note for future work. If it does turn out to be better, then you merge your new work into the main branch to include the changes.
Molly K. Maskrey

Chapter 9. Embedded Systems

Abstract
To take you to that point, I’ll offer some basics about embedded systems and some options for you to get started, and will try to connect the dots as to how and why embedded systems mean so much to us as iOS developers.
Molly K. Maskrey

Chapter 10. Publishing Our Work

Abstract
The first thing we need to do is to create the archive, which contains the app bundle and debug information that we will validate and upload to the App Store.
Molly K. Maskrey

Chapter 11. Web Services

Abstract
While most of our initial app creations are fairly simple and well contained, within a short period of time we’ll need to access external information if we’re doing anything serious as an iOS developer. We talk in several places about accessing data from sensor systems or controlling home automation devices using Apple’s HomeKit ecosystem. However, if we want to download music or video, upload game scores to our own database, or share files or even small pieces of information, we’re going to have to use some type of web services to move data between the cloud and our device.
Molly K. Maskrey

Chapter 12. Testing

Abstract
In this chapter I’ll focus on three types of testing. The first two types, Unit and User Interface testing, are integrated into Xcode and are added in when you initially create your project if you’ve selected them in the appropriate dialog. These are tests managed by you, the iOS software engineer. You create Unit Tests first, knowing what is and is not acceptable behavior in your code. By setting up these behaviors as tests before you code, it’s easy to test against your requirements as you code. That’s really the point. Don’t think of these Unit Tests as something we add on to a project to check off a box somewhere; imagine them as a slightly different way to write the software project requirements. Even the most loosely based development houses manage their requirements in some manner. Using Unit Tests not only provides a convenient centralized spot to do so, but because of their tight integration with Xcode, you get requirements verification basically for free.
Molly K. Maskrey

Chapter 13. iOS Accessories

Abstract
What do we mean by accessory? I define an accessory as any external hardware device that connects to the iPhone via the Lightning connector at the bottom of the phone or via Bluetooth 2.1+EDR wireless signal, i.e., standard Bluetooth. Connecting electronic equipment to an iOS device by either of these means requires the developer to be part of Apple’s MFi program. You can, of course, connect other accessories to your iPhone through Wi-Fi, Bluetooth 4.0 Low Energy (BTLE), and, with a little work, the headphone jack.
Molly K. Maskrey

Chapter 14. Swift Conversion Project

Abstract
In this chapter we’re going to start with an existing, very old iOS project I wrote around 2009. It’s a very simple slot machine app that came out for the second-generation iPhone, the iPhone 3G. In fact, at that time there was no iOS. Apple called the operating system iPhone OS, even though it worked on the iPod Touch device as well. There was no iPad released yet.
Molly K. Maskrey

Chapter 15. Coin Toss Project

Abstract
In this chapter we’ll move into developing a more up-to-the-minute kind of application. We’ll work with Swift and the Apple Watch to create a very simple game of flipping a coin. I’ve actually used this on occasion, out in the world, to choose a path when I’m confronted with a couple of different, seemingly equal choices. I often wonder why I make so many wrong decisions.
Molly K. Maskrey

Chapter 16. Home Automation Project

Abstract
With the Internet of Things (IoT) space surging and new products being added daily, it seemed fitting to explore how to use Apple’s version of home automation. HomeKit can be thought of as many things: a label on products to assure consumers of compatibility, a set of software frameworks to create HomeKit apps, and even a hardware set of specifications if you’re developing hardware under the MFi program. For this section, we’ll start by using the HomeKit framework to create a simple, on-off toggle of an AC outlet to control a disco ball (Figure 16-1). Why a disco ball? Well, why not? Seriously, though, you can use any AC-powered device; a desk or table lamp, for example, works just as well.
Molly K. Maskrey

Chapter 17. External Sensor Interface Project

Abstract
In this chapter we examine two of the ways to connect external hardware to iOS devices. We saw in the previous project how we could use Apple’s HomeKit framework to do pretty much the same thing. However, while many of the same types of hardware devices can be controlled by various means, HomeKit projects are restricted to HomeKit-certified accessories. Some electronics, such as sensors, drones, medical devices, and so on, use a more generalized mechanism for moving data to and from an iPhone, for example.
Molly K. Maskrey
Additional information