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. She’s discovered that programming, and in particular iOS development, speaks to her (see Figure 1-1). Whether it’s solving complex problems, having the freedom to choose when and where to work to make a better life for herself, or just that it’s fun—I want everyone to succeed.
Figure 1-1. The creativity of development captures our imagination and draws us in to solve problems the likes of which we never imagined
Goals
For me, this is personal. As a business owner, I continually find that there are not enough app developers available to help us grow and expand the business. In particular, finding a capable mobile software engineer with whom I can easily communicate is the most significant problem my company faces. As a bit of background, we design electronics equipment that connects to Apple devices, so we really look to our software contractors to not only understand coding, but also to know how to get the final product, the app, out into the world. We don’t want to hire a developer whose end result is to send us an Xcode project file. She needs to take charge, to create the final product as if it were a thing of beauty, an art form extending from her own soul. As such, we assume a more than introductory level of expertise with Xcode, Swift, and, to some extent, Objective C. Many books, online tutorials, video courses, instructor-led courses , and so on exist to help you learn the basics. Apple’s own developer portal offers more than enough instructional information and sample applications to take your coding skills to the intermediate level and beyond. More importantly, the real-time, interactive nature of online media lets you stay current and up to date as new features are released and bugs requiring work-arounds are corrected.
This book shows you how to work with all those other pieces of developing an app that you don't typically find in introductory material. Let’s look at an example.
You’ve downloaded Xcode and watched a YouTube video or three on how to write simple apps. After a few easy-to-fix missteps, you not only have your “Hello, World!” app running on the simulator, but you’ve got a three-level table view and are even displaying jpegs of your cat. Good job. But you want to have it run on your iPhone. What do you do?
Note
This book, unless otherwise noted, uses the term iPhone to describe the broader set of Apple devices for which we will be developing, including the iPad and iPod Touch. This serves a couple of purposes. First, it makes the text much more concise. Again, as an intermediate-level developer, you already know that we can create iPhone-only, iPad-only, or Universal apps. Second, our example projects use the iPhone as a target device. In some cases, such as when we’re targeting Apple Watch using the currently available tools and frameworks, this is actually required, as Watch can only be paired with an iPhone at this time.
Like just about anything else when creating software projects, all the individual pieces are pretty simple. You follow a predefined sequence of steps to achieve your goal. Just like the first time you became comfortable with the if-then-else clause, getting to the point of delivering an iOS app to the Apple App Store requires several actions that become more and more familiar each time you go through them. That’s one of the purposes of this book. I want to go through them with you in order for you to gain that familiarity. But more than that, I want to show you the obstacles you might encounter along the way, confront them with you, and work out how to make it to a successful conclusion. In a sense, I’m being a bit selfish. I want to make you into the kind of developer with whom I would choose to work.
So, back to the problem of getting your app into the App Store. We will, of course, go through this in great detail later in the book, but let’s look at a simple preview.
You first buy an Apple developer license, log in, and then create and download developer certificates to your computer (Figure 1-2). Next, you create your app identifiers, which are basically the names of your apps, then you add your device or devices on which you intend to execute your code. Next, you create provisioning profiles that you download to your device.
Figure 1-2. While it may seem daunting at first, I’ll walk you through a simple, step-by-step procedure to take your app from the simulator to your device in no time
While this may sound like a bunch of gibberish when you’ve had your head buried in for-loops, alerts, libraries, debuggers, and all that, once the setup steps are done correctly, you can build your app from Xcode and run it on your device. It’s no more complicated than learning to effectively use your IDE or the simulator.
As an intermediate developer reading this book, you’ve most likely done this many times already. If you haven’t done it, don’t worry; we’re going to go through it in agonizing detail in Chapter 3. If you have been through these steps, it probably seemed daunting at first, and some of the things that were supposed to work didn’t, but either by perseverance or blind luck you got it to run on your phone. Let’s hope it was the former.
But what a sense of pride! You created something that you can take with you to show your friends and family. I’m not being sarcastic; you’ve truly accomplished something. I remember the first years that Xcode was available for iPhone OS (as it was called back then). Everyone that had seen an iPhone downloaded it to try it out. What happened? It was so complicated to use and the process was so convoluted that the vast majority simply gave up.
Of course, things are much better now. The tools and processes streamline the work flow, and in many cases Xcode can fix most of the common problems associated with not only your code, but the process as well. Just as code hinting provides invaluable assistance in writing correct syntax, and the quick look help delivers just about whatever property and method formats you might need to access, Xcode now includes built-in assistance, much of it automated, to deal with these process problems.
Still, you must understand each of the steps if you’re to ever deliver your work to the App Store, or work at a medium to large software agency, or even work as a freelance coder. The tools help you, but they won’t do it for you. Even more importantly, they have this knack of letting you down when you need them the most.
How does this book help?
In this book I try to focus on reducing the frustration that comes with iOS and Xcode. Most of the time, in the early stages of development things usually work well. But once you move past those first few apps, expand functionality, increase the number of views, start running parallel tasks, access web services, or any other function typically required of “real” apps, things start to fall apart. That’s when the simplest things drive you crazy (Figure 1-3).
Figure 1-3. My number one goal with this book is to reduce the frustration you experience in your early development career
You’ve worked for two hours to get a view’s layout to look good, but when you rotate the simulator screen it falls apart. Or worse, it looks great on the simulator but on a real device it becomes unrecognizable. Similarly, you work through your app’s design, coding, functionality, testing, and it’s perfect, but when you try to upload it to the App Store, dozens of issues prevent you from leaving your computer to do something else. This and other similar problems create a sense of failure and, more devastatingly, a desire to just give up and do something else. You need to understand that you will never be 100 percent ready for this. If you are and have never experienced any such frustrations, then you’re probably not pushing your limits. And to be honest, I really don’t want to work with someone who doesn’t push themselves. After all, there’s not a project that I work on in Xcode where some frustration doesn’t send me into a panic thinking I’ll never get it to work. I question myself. Did I not think clearly about the design? Did I not understand the description of the framework? Or is this just beyond my capabilities?
There will be problems, and those problems will create frustrations that in turn may create doubt in yourself and in your own abilities to pursue this as a viable career. I often talk to aspiring developers, especially women and girls, who want to pursue software development as a career. Without getting into the socio-political issues surrounding males versus females in technology, quantitative information confirms that such a disparity exists. You can read pretty much any article and find that women are somewhere around 25 percent of the tech workforce. From a purely anecdotal, but personal perspective, I see this as well. At technology meetups, excluding those that are female focused such as Women Who Code , I’ll see one or two females at most. When I’m at a software agency interviewing for my own projects or in support of one of my clients, I rarely talk with female engineers. Admittedly, I’ve become somewhat biased in this and actively seek out female-owned or female-run businesses with which to consult.
And that’s not the way it should be. In my company, we want the best, most cost-effective software developers for our projects that we can find and afford. We don’t always need the developer with 200 projects under their belt; we may need basic development skills but with the ability to meet tight deadlines. In the latter case, the essence of what I talk about in this book is still critical. The developer still needs to understand how to get the app to market, but she might not have to be an advanced game theory programmer.
As women, many of us see things differently. I can’t speak for anyone other than myself, but early in my engineering career I found myself shying away from taking on projects or applying to jobs where I did not think I was 100 percent ready and qualified. I thought I had to meet every single requirement and “nice to have” on the advertisement. Many of my male friends with less experience and, I’d like to think, with less qualifications than I possess applied for and often got the position. This drove me crazy. What made it worse was when they would ask me for advice on how to do something.
Through these frustrations, the idea that I would never be 100 percent ready surfaced. More importantly, I understand now that this is okay. Much of the time, no one meets all the requirements of an advertised job position. In talking to technical people working at various companies as well as some human resources professionals, what the companies look for is the ability to learn and adapt in addition to the basic needs of the job. That said, I came up with this mantra:
1. You’re never going to be 100 percent ready.
2. Do it anyway.
3. Just get started.
This works for just about anything where the odds seem like they’re against us.
When you see your dream position open up at a company where you’d love to be employed, but you just don’t think you have those last two skills, give it a try. While every case is not the same, sometimes your passion for the position or the company might be more important to the interview team than whether you have Scrum certification.
If you’re fortunate enough to land that interesting job you discovered and want to excel at it, even if it seems overwhelming at times, just keep going. The information is all out there. Hundreds, if not thousands, have gone before you. You’ll get there.
That’s a lot of what this book is about. It shows that you are going to encounter problems along the way, but that those problems are solvable. Having been through most of these problems before, how am I going to convince you I know what I’m talking about? I’m going to make my friends suffer. In fact, I personally put in the roadblocks that they will soon encounter. But don’t tell them.
For fun, I recruited several of my good friends (or at least they were at the start of all this) as “guinea pigs” to do some app development. These are smart people who understand technology but have never written code—well, not this type of code, anyway (Figure 1-4).
Figure 1-4. To try and understand the actual problems new developers face every day, I recruited friends to start down the path of an app developer. I’m hoping they’ll remain friends at the end of all this
One good friend who was recruited as a social media engineer took on website maintenance with a decent familiarity with HTML and CSS, but not much more than that. My friends all use an iPhone , and some have an Apple Watch ; even more importantly, they all have ideas for apps they’d like to create. Some are what you might call “power users ,” while others are just very comfortable with technology.
I decided to help them with their various projects because the ideas were pretty sound and were different enough to cover a broad set of skills and challenges that were reflective of many of the problems that you’ll see as you travel down this path. We banged our heads against the keyboard so you don’t have to. We explored some of the most common issues of app development. Think of them as the nuances—the subtle things that just seem to show up when working on your project. Not all of the nuances are huge problems or bugs, but if you haven’t seen them before or don’t have a clue as to how to address them, they have the same head-banging potential as any app crash.
We’ll get into each of these issues in the individual chapters that follow, but let’s take a look at an example. Many self-employed developers don’t use source-code tools or develop unit tests despite the cost and time savings being widely documented. It’s just too easy to create a new single-view app project and start prototyping. Before you know it, the app is too far along to consider it just a prototype. It’s working fine and you can figure out how to archive the code later. Or, there’s so much “meaty” code that it would take too much effort to start developing unit tests. Where would you begin, anyway?
Take any post-secondary development course and two things that are bound to come up are source control and testing. It only makes sense. Lose your project code without a backup and you’re nearly back to square one. Or send an app out into the field, even if it’s just beta testing, without proper code coverage using unit tests, and the problems will start rolling in. What’s worse, you won’t really have a place to start.
Source-code control , especially using Xcode’s integrated git and Github support, should raise your confidence level. You can work and test and try new things without fearing that you’ll lose track of where it last all functioned correctly. It’s easy to roll back your project to any stage in your development as long as you follow a few simple rules.
In researching this book, I met with many app developers in the early stages of their iOS careers. Generally, the breakdown was about half looking to get into any technology and thought creating apps sounded like a good idea. The other half included people from different technical disciplines, but mostly web developers who saw more potential in or just liked the idea of mobile software.
This book exists as a combination of two styles. First, the bulk of the writing describes the concrete, the objective scope of the work . . . you need to do this, here’s how you do it. But, because this book is not just about fixing problems, but also fixing frustration, I chose to include some of the subjectivity. What does it feel like when you come across a stumbling block or seemingly insurmountable problem? How do you get past it?
At the time of writing this paragraph, I don’t know exactly what will happen. As I’ve said before, I see so many people give up because of the seemingly nonsensical steps a developer must take to accomplish what should be straightforward. Though there are reasons for the complexity, that is no help when you’re banging your fist on the keyboard two hours past your bedtime.
This book attempts to help the developer push past those stumbling blocks and move toward a rewarding career that can last a lifetime.
Career
In the previous section, you found references to career opportunities sprinkled throughout the text. Why is that important in this book? Wouldn’t everything here be equally applicable no matter where you worked? Before we get to that question, I want to discuss the three basic career paths that I’ve had the fortune to enjoy.
When apps started appearing in 2008–2009 there were stories of developers, young and old, striking it rich with their great ideas. Games took center stage, but utilities, educational software, and various other categories had their fair share of breakout hits as well. Early on, you didn’t see lots of mobile software companies stand out. I remember when I wanted to take a break from working for myself, at home and somewhat alone, it was tough finding companies here in Denver that actually did iOS development. Most companies were in the Bay Area, Los Angeles, Seattle, and on the East Coast.
That, of course, changed pretty quickly. iOS, Android, and Windows development firms exist in Denver, Boulder, Colorado Springs, and everywhere in between. This is most likely the situation you’ll find where you live or nearby.
Career Path #1: Employee
Without revealing my age, when I attended college any career other than working for a large company seemed like a second-rate alternative. Big companies offered higher starting salaries, medical insurance, vacation, benefits, retirement, and even bonuses. Working for a company like IBM was the dream of everyone in my engineering class. There was the security of knowing you’d always have a job. I was fortunate to be one of two graduates to actually go to work for IBM, and my mother was so very proud. When I told her a few years later I was leaving for another company she actually cried and told me what a mistake I was making. Back then IBM was a real player in technology. Today, I couldn’t tell you what they do.
In the late 1990s dot-com startups were everywhere. I lived in Silicon Valley at the time (Figure 1-5) and had first-hand experience seeing the lavishness, office and housing shortages, and traffic jams. You could leave a job one day and have something new before cocktail hour. I remember banner planes flying over our parking lot displaying URLs of companies that would up your salary no matter what you made.
Figure 1-5. Silicon Valley at the turn of the twenty-first century became the litmus test for ventures capable of survival in the dynamic world of technology
These companies were not like IBM, and nobody expected they would work 30 years and retire from pets.com. Everybody’s dream seemed to be to work a few years and cash out when the company was bought out. Most companies failed. At the time I worked for Lockheed-Martin in a very stable but unremarkable career as an aerospace systems engineer. My work interested me, it made an impact in the world, and I was financially comfortable.
Several of my friends joined startups and guess what? None of them made it big. In all cases the startups disappeared after suffering months or even years in a business coma where there were no customers and the funding well that had seemed endless dried up.
Today’s software companies offer a seemingly mixed bag. You get the structure and security of a steady paycheck, insurance, and other perks but operate in a mostly startup-like mode. Many companies claim to offer unlimited vacation time. To me, that makes no sense, because if it were true I could get hired and go on vacation for the rest of the year or longer. Now, of course there are limitations to this, but then why advertise unlimited vacation if it is not, in fact, unlimited? It’s more like you’re not set at two or three weeks when you start and if, say, you finish a major assignment, then get married, your boss will probably let you have an extra week or maybe two. In all cases management has final say on this.
The point is to not be swayed by the promises of job postings or recruiters. Sometimes the people you interview with may give you the facts, but those cases are rare. Just have an open but skeptical mind when interviewing. Assess the good, the bad, and what seems too good to be true.
To get a job with an established software company, from small, locally owned shops to the major players, you want to have the basic set of tools addressed in this book. Everything we cover, except for issues dealing with starting your own business, should be part of your skill set or at least your vocabulary. You may not know exactly how to use Quartz or Metal, but at least by understanding the basic concepts you won’t turn a highly interactive interview into one where it seems like they want to push you out the door.
Career Path #2: Entrepreneur
While having a bad boss when working for a larger company can be disheartening, and dealing with traffic two or three hours a day may drive you to madness, neither compares to the stress of doing everything yourself. You still have the constant barrage of bosses (clients) telling you that what they need is not what is written on their contract. You’ll suffer constant pleading to reduce your rate, or your hours, or take an equity stake, or some other offer that’s not likely to pay the rent or get that new water heater you need.
And on the other side will be the constant paperwork dealing with licenses, tax filings, and investor meetings—if you’re lucky enough to get investors. Speaking of investors, unless you have enough free capital to fund your startup, you’ll want to use other people’s money if you can. That’s why having a great idea can boost your potential.
But a great idea is only the seed. You must have a business plan (Figure 1-6) to succeed. And yes, most business plans are not worth the electrons used to create them, but any investor will need to see yours. This brings up the question: What will your business do?
Figure 1-6. Without a well-thought-out business plan , you’re setting your company and yourself up for failure
Generally, your best option is to start a consulting business where you take on development projects. Let’s say a couple of entrepreneurs come to you with an idea for the latest social media breakout, perhaps Facebook but with a different color scheme. They have a lot of money and really want you to build their app for them. What do you do?
With a consulting company , you’ll be hard pressed to find investors to get you started. Money people just won’t see the ROI (return on investment) they’re looking for via your writing a hundred lines of code or so each day. Luckily, there are other funding options, which we’ll talk about in the next chapter.
If you have a great idea for an app, get in line. It’s like any diner in Hollywood circa 1960. Every bartender has a script and every waitress is an actress looking to break out. Fortunately, social media tools such as Vimeo and YouTube have leveled the playing field somewhat.
Everyone seems to have a great app concept. Mention yours to a few people and you’ll likely hear, “Oh, it’s like such-and-such.” The good news, I believe, is that there are still a lot of opportunities for mobile software development . In late 2015 Apple introduced the iPhone 6S and 6S Plus along with the iPad Pro. Both device types offer new, unique features that can be leveraged, such as force touch on the iPhone and the larger screen size and stylus capability with the Pro. Coming up with a unique concept that can utilize new features in an exciting and novel manner sets you apart from the crowd. As with the other two types of career paths, we’ll discuss this shortly, but if you can create something that provides recurring revenue, such as the in-app purchases of gaming, you might have a chance to attract some investors.
Career Path #3: Contractor
We’ve talked about starting your own business as an alternative to working for someone else, so think of contracting as the bridge between working as an employee and running your own business. Working as a contractor, like anything, has its plusses and minuses, but it all depends what you’re looking to find. I’ve been on all three paths. For many years early on, I worked at large companies offering lots of job security, but as the economy changed, those promises evaporated quickly.
Being somewhat older, I found myself at loose ends. Should I find another company, participate in the dot-com boom that was happening in the Valley, or do something else? I was fortunate, because the business explosion escalated property values, giving me some choices. I took some time off but stayed current with my skills. Then the iPhone came out and changed everything.
A lot of us in technology at the time were skeptical of Apple getting into the phone business. Sure, the iPod and iTunes were doing incredibly well, but phones were changing so much at that time. The trend was definitely to go smaller, and the iPhone seemed counter to that. Plus, there was the Newton fiasco.
It, of course, took off, and all my non-techie friends had an iPhone long before I did. About a year later Apple opened things up to allow user-created apps, which was about the time I got my iPhone 3G, and things really went crazy. Each day you heard of another app success story.
I developed my iPhone OS skills and created my first app, a slot machine game (Figure 1-7). I was fortunate to have worked in embedded systems for many years, enabling me to quickly understand the concept of running small programs on a phone with limited memory and processing power.
Figure 1-7. Your first app idea can be as simple as this slot machine game developed by the author to gain experience coding for the iPhone in 2009
With some app ideas in hand, none of which seemed all that great—plus I was still at the early stages of developing my Xcode skills—I started looking to work for someone else. There were some opportunities here in Colorado, and I eventually landed a 1099 contract position with an up and coming software agency trying to establish a Denver office.
We’ll talk about this more in a later chapter, but even though you’re an independent contractor, you have to follow the rules set down by the company but without the perks and benefits. Also, you’re not guaranteed a 40-hour work week, so if you’re looking for a steady paycheck, this might not be the best choice. It really depends on the company, the projects they have in the queue, and how well you fit in with the culture.
Working as a contractor for a company, however, is not your only option. If you’re okay with sporadic income you can create a profile on a freelancing site. Upwork, formerly Elance, allows customers to locate project-based talent directly and choose based on their needs and resources (Figure 1-8). As a developer, you list yourself, your specialty, and any other information you want to advertise on the site to get projects. Much like airbnb, this concept brings together the service provider with the customer, mostly eliminating the middleman and managerial overhead.
Figure 1-8. Companies such as Upwork offer you the tools and resources to get you started as a freelance developer
As a freelancer you can set your rates and choose which projects would be a good fit for your skills and lifestyle. According to the site, each year freelancers earn over one billion dollars through the online workplace. You can work by the hour or per project, and if you choose to go hourly, the site has tools to let you track your time. If you choose to work on a project basis, then you’re paid at completion of milestones you set with your client.
Okay, this connected workspace seems like a really good thing, but it still has a very important point to consider—you still have a boss. Your client is now your boss, and they can be incredibly demanding. When you interview at a company, most of the time you’ll meet your boss and co-workers during the interview process. You’re able to tell if it’s a good fit or not. You won’t have that when you’re a freelancer. We’ll discuss this at length in Chapter 2.
Our Plan
With the understanding that our goal is to develop the skills necessary to further our career in iOS development, how are we going to get there? Attaining a comprehensive set of skills in this area does not lend itself to a linear process. That is, we don’t learn source-code control after learning UX skills after setting up our provisioning. It’s more of a need-to-learn-it-all-at-once kind of thing. Unfortunately, no one I know can read multiple chapters simultaneously, so we just have to make do with a sequential process.
I’ll go through a sequence of instruction based on the experiences that got me to where I am today. That’s not to say I’m regurgitating how I did it; in many cases, I learned things in the wrong order. Now’s my chance to correct the situation so you don’t make the mistakes that hindered me.
First, we want to figure out how you plan to use your mobile development skills. By first understanding where you want to go, we can reshape our plan to fit your specific path. Do you need to understand automated builds if the plan is to develop your killer app during your spare time? After we talk in detail about career direction in Chapter 2, we will get into the more technical aspects of app development and the problems you’re likely to encounter. Because we want to address problems, we of course will speak to the overall procedures for each particular subject.
Because getting your app onto an actual device is the most critical aspect of showing off your skills, we take that on early in Chapter 3. As someone who already has a few apps in her portfolio, we’ll go through the process rather quickly and try to hit the high points of where things can and often do go wrong. Fortunately, Apple in its latest releases of Xcode has made much of this semi-automatic. But, like most things Xcode, this type of automation tends to work only in the most basic of use cases. For example, if you have one developer account and forgot to create a provisioning profile, the automation tools will generally work well. But if you have several developer accounts or belong to more than one team, things become a little more unwieldy. Those are the points I’ll try to address. Having individual accounts as well as managing a team, I come across these at least every week or two.
Chapter 4 presents an overview of the code we’ll be developing and referencing throughout the book. We’ll tackle four major projects plus a number of smaller, partial ones as we move forward. The four major projects, including source code, are detailed in the last chapters as reference and are included because I have devoted significant time to them over the years. As needed, we’ll look at smaller projects, code snippets in some cases, that act as a better reference depending on what we’re discussing.
If you’re developing apps for profit, whether as a contractor, employee, or running your own business, please get started with source-code control, which we discuss in Chapter 5. A few years ago when Apple first started integrating Git tools into Xcode I was so happy, until I tried to use it and everything broke down and I lost some of my files. I still maintained backups on Github, but I never used Xcode to do it, relying instead on third-party tools such as Tower. Even while I was working at a company a few years ago, Tower was the de facto standard for managing backups and source control.
My writing style, or perhaps it’s the way I think and form concepts, causes me to shift around a bit, not necessarily keeping to a purely sequential organization (Figure 1-9), so in Chapter 6 we’ll take a step out of the trenches and spend some time talking about methodologies. If you come from large corporate engineering firms you’re most likely familiar with the waterfall project design. For years this was the norm. First, you design everything until it’s perfect, then you start coding or developing. I must have worked on two dozen projects this way; ISO standards, six-sigma, and all kinds of other buzzwords were tossed around with statistics explaining why this was the best way to do things. Fact of the matter was that of all two dozen projects, or however many it actually turned out to be, none came out on time or on budget.
Figure 1-9. I’ll occasionally change up the flow to engage you and keep things from getting too stale or boring
Agile development, while not by any means perfect, provides a completely different mindset to development. To provide a spoiler, you start developing almost immediately and see what happens. This works really well if you’re a tinkerer like me. When I see a new feature or framework, I quickly create a simple project and play around. While not exactly the agile process we’re looking for, the gist of it is the same; you want to quickly see what works, and more importantly what doesn’t work, so your time is better spent during the development process.
For the customer, this results in quicker delivery. For your organization, you spend less time going down paths that don’t return good results, which lowers your cost of project development and increases profit, assuming project-oriented pricing. Even if your company bills its clients hourly, and the reduction in number of hours may appear to lower your revenue stream because you’re doing less work, in actuality you will almost always wind up using that “found time” for other aspects of the project. This extra effort increases the quality of the project, which in turn gets you more business from the existing client as well as better referrals that let you capture new business.
Chapter 7 takes us back into being hands-on with Xcode and specifically into how we develop the user interfaces and overall user experience. Quite frankly, I am not an expert in UI/UX creation. In most companies you generally find these functions split between two departments or sections. The design group develops the look and feel of the app—the colors, the sizes, and the shapes of the buttons or windows. Think of them as the CSS portion of a website. The engineering group creates the coding; for us, this would be the Swift code using the Xcode development environment. As an interesting crossover, the engineering group also usually instantiates the UI/UX from files delivered from the design group. Basically, you take the design group’s “wireframes” and convert them into storyboards and .xib files inside of Xcode.
Continuing our work with Xcode , in Chapter 8 we get serious about building our final products for release into the real world. Specifically, we’ll discuss schemes and manual builds. When working in your own business, manual builds are really all you need. But if you intend be employed by, or to act as a contractor for a larger, more established software agency, you’ll need a little familiarity with automated code builds. As continuous integration (CI) becomes more and more prevalent at software companies, you’ll want to have a handle on the concepts (Figure 1-10). Apple introduced bots a couple years ago in an attempt to supplant the more established Jenkins/Hudson or Travis CI servers. Like all new technology, bots have had their share of issues, and many companies still use one of the other servers as their baseline. But, like what happened with source-code control, the tight integration with Xcode may offer bots an advantage once things become a bit more streamlined.
Figure 1-10. Continuous integration streamlines the testing and distribution processes when multiple developers work on projects together
We won’t go into great detail on either option, with the exception of making sure you have enough of a comprehensive understanding to be prepared for your next job interview, either as a direct-hire employee or a contractor.
In Chapter 9 we once again step out of the depths of writing code and look at the world of embedded systems. My experience for the past twenty years focused almost entirely on the embedded space. That’s why I was drawn into the world of mobile development. Embedded systems offer a huge variety of real-world things you can interact with. It’s no longer just stuff on a display or pulling data from a PHP (PHP: Hypertext Processor) server. With embedded systems, we interact with stuff. For me, this is what it’s all about and why I still have passion for the field.
We’ll cover how embedded systems began and evolved through the years to become what we now consider everyday devices such as our phones, music players, fitness monitors, tablets, and so on. But then we will move into the world of IoT, the Internet of Things (Figure 1-11). Many see IoT as the next major revolution. We interconnect all the capable devices in our homes and apartments through our mobile devices. We can monitor our doors, feed the dog, start tonight’s dinner, track our movement, set the mood, draw the shades, or any of a countless pool of functions that exist today, and many that haven’t yet been conceived. As part of a plan creating a modern, connected town, my team uses IoT beacon technology that establishes directed advertising to the consumers in our business district to increase traffic and provide targeted advertising to consumers.
Figure 1-11. We’ll cover one of the most exciting new areas of development, the Internet of Things, where we connect and communicate with devices of all kinds including Apple iBeacon technology
Back to the tools in Chapter 10 as we cover getting our app published in the App Store. We’ll talk about the App Store in general terms, as anyone familiar with iOS devices must be familiar with the basics if only to update apps and the operating system from time to time. What we’re going to focus on are the tools used through each step of the process—specifically, using the iTunes Connect portal to publish our works of art.
Publishing an app really consists of, once we have something we’ve deemed worthy of putting out into the world, two parts. The first part we mentioned earlier and cover in Chapter 8. We create the archive that gets verified and sent to the App Store. But before that, we need to configure what our app is all about and how it will appear in the store. If you haven’t noticed it previously, the non-linearity of the process steps should start to become clearer. We can’t publish an app until we have a build to upload, but we can’t upload a build until we set up our information in the App Store using the iTunes Connect portal (Figure 1-12). But what if we want to change things a bit before publishing to the App Store? We may want to get a workable build that we can archive and distribute ad hoc before even bothering with iTunes Connect and the App Store. We may not even want to distribute through the App Store if we can distribute through the enterprise.
Figure 1-12. To publish, advertise, and sell our wonderful application, we’ll discover how to work with, and not against, iTunes Connect
For the most part, once we get to an app build that functions well and is reasonably bug free—we can’t find every problem at the start—the steps to get it published in the App Store are pretty straightforward. The problems come in all the details that must be attended to when setting things up to display to the store’s subscribers.
One thing you find often in apps other than simple utilities or games is a connection to an external database. Most often we do this through Representational State Transfer Services (REST) . Essentially nothing more than reading or writing to a website, our app can share and gather data from any number of users worldwide. We can search business listings, find our way through map databases, or store our own personal information to share with whomever we choose.
As with build automation from Apple trying to supplant the more widely used Jenkins servers, CloudKit (Figure 1-13) provides much of the functionality of REST but is easier to use. The drawback comes from CloudKit currently only working with Apple devices. As such, for the broader mobile ecosystem, it has limited use in its current state. Still, as with other features Apple has added over the years, this will likely change, and it’s best that we look at it as an option, especially if you’re focusing on iOS only at this time. We’ll look at both options and how they might be used in our projects.
Figure 1-13. Apple’s CloudKit framework , while limited to iOS and OS X devices, offers a very easy-to-use set of tools for working with information on the Internet
To make a product with which people will interact, testing cannot be overlooked. Just as you wouldn’t release a new drug or even food item into the marketplace without testing, neither should you let your apps out into the world unless all the functionality has been rigorously exercised. A few app crashes with cranky customers and your app could be dead before release 1.0 hits the store.
Once your app is ready to go out into the real world, but is not yet available to the general population, you’ll distribute your beta release to be tested. Now, with TestFlight integration , you no longer have to create a complex combination of your app bundle and provisioning profile to send to authorized users via email. TestFlight and Xcode have built-in support to make this nearly painless. You have options of either testing internally with your in-house company team or, with a little more work, distributing to a broader set of beta testers.
In Chapter 13, I cover my specialty area, iOS Accessories. We’ll look at the various input–output ports by which data can be brought in and sent out of the iPhone. From a simple headphone jack device such as the Square credit card reader (Figure 1-14) to high-speed proprietary connections such as wireless Bluetooth or the wired Lightning connector, the iPhone offers many ways to gather information and provide control capability. I’ve worked on iOS accessories as part of Apple’s MFi program since 2009, when I also developed a credit card reader and companion payment application. Working in the MFi program requires strict adherence to Apple’s non-disclosure policies, so many of the details of the plan are, of course, confidential. But the whole point of the plan is to assure customers that a particular device or accessory is compliant with the Apple device to which they intend to connect their purchase. Our discussion of the MFi program, though we’ll shy away from the program details and not get into any technical specifics, will look at the types of devices that we can use with our iPhone. We’ll look at a wide range of products from personal to B2B (business to business) as well as how we might use the HomeKit framework to integrate devices into our own IoT ecosystem.
Figure 1-14. The Square credit card reader, one of the earliest iPhone accessories, used the headphone jack instead of the 30-pin dock connector, making it cross-platform compatible
In the final few chapters, the projects that we use throughout the text will be described in detail as a reference. I chose four sample projects to cover in their entirety, primarily because they interested me and because they addressed the issues we’re discussing in this book. I tried to pick things that I thought would be enjoyable and interesting and spur a sense of creativity and passion but that would also provide useful skills and experience. And, for the most part, I wanted to try to have a little fun by building some things that might be a little different.
Fun
The most important aspect of my life centers on the ability to have fun, so each and every project I take on needs to have an inherent enjoyment to it. I know that, in the early stages of a developer’s career, she needs to build her skills and confidence level in order to command a specific salary and work environment. But that doesn’t mean I’m going to overwhelm you with writing table view after table view because it’s an easy direction to take. As long as I’m running the show, or writing the book anyway, I’m going to do my best to keep you engaged by creating as much interest and enjoyment as I believe possible.
So what are these so-called fun projects I’ve been going on about? First, we’ll tackle a simple conversion from Objective-C to Swift for the slot machine game app that I mentioned earlier. Called Town Slot, a play on words of course, the app contains three spinning wheels, a couple of betting choices, and a spin button. Originally written for the iPhone 3G, the code mostly contains deprecated function calls. In preparation for this book, I converted it to more modern Objective-C and have successfully operated the app on iOS 9 devices. Starting from there we’ll make the transformation to a full Swift project.
While this may not seem like that much fun, because Swift is still relatively new, having both Objective-C and Swift coding skills might be the differentiator you need to land that developer position. Eventually, Objective-C will likely become less and less supported, so many companies with existing apps may need to convert their old code into Swift. This in and of itself could be a source of income as a freelance developer. Because the conversion is mostly straightforward, less skilled engineers will likely want to take on such mundane projects. As you are trying to expand your skills while building your own portfolio, this could be just the right job for you to take on.
We want to start playing around with the Apple Watch , as it is currently the “latest and greatest thing.” As new and creative uses for the Watch start to reveal themselves, development companies and freelancing sites may rapidly increase their need for skilled Watch coders. My very first Watch app was a simple coin-flip game just to get the feel of how everything works. As I was working through it I was surprised how much it took me back to the early days when I did the slot machine game. I felt a sense of freshness that really drove me to complete the project. My friends were so fascinated with something so simple, a number of them have decided to give app development a chance. Through that simple action, making an almost trivial app that actually does something, I may have given people I know, friends, a chance at a better career and life.
As mentioned previously, the Internet of Things is becoming bigger every day. Someone seems to be coming up with a new connected piece of equipment hourly. So let’s have fun with it. Apple’s HomeKit framework makes this pretty simple and offers built-in security features not currently found in the vast landscape of IoT products out there today. We’ll extend what we cover in the main part of the book with a project that allows us to control a power outlet in our home. Recently, I was asked to give a talk about HomeKit and the Internet of Things and so I created the demo on which this project is based. I could have turned on a simple lamp, but instead chose to start up a flashing, rotating, colored disco ball (Figure 1-15). The audience loved it, and I got so much attention after the talk, the organizers had to shoo us all out of the auditorium. The point again being, have fun in and passion for what you’re doing and you’ll likely never dread going to work.
Figure 1-15. Using HomeKit to monitor and control devices provides an easy-to-use, flexible, and rational way to control everything from doorbells to disco balls
Our final project incorporates elements near and dear to my heart. I take my experience and interest in embedded systems and combine that with a need to create an impact in the world and form something that could potentially assist thousands, if not millions, of older individuals.
By profession I’m actually an electrical engineer; I took on iOS development to create near off-the-shelf tools that were affordable for a larger percentage of the population. Frankly, as I’ll try to continue to stress, I couldn’t find developers with the needed skills at an affordable rate. In fact, I couldn’t find any developers early on that really understood all the aspects of iOS development needed to make real, interactive hardware systems that were truly useful. I’m not saying I’m special, just that the dictates of the broader market were elsewhere at the time. My concept is to minimize new and complex development to only that which is absolutely required. For everything else—reuse, reuse, reuse. That’s what we’ll do here.
Last year I designed and built a small sensor that provides information on movement and orientation. It’s really just a printed circuit board (PCB) containing what everyone already has in their smartphone or fitness monitor without everything else. We’re going to capture a couple pieces of information from that sensor to tell us its orientation. Imagine an XY plane parallel with the ground. If you change the angle in either the X, or the Y, or both axes, we’re going to receive that information, really the two angles, and do something with it. Okay, here’s where you get to know me a little better. I’m going to measure the angle of the foot. Specifically, I’m going to look at the pitch of the foot and the side to side roll of the foot.
Why? Well, I’m a dancer, a ballroom dancer to be clear, and I was looking for a way to judge how correct or incorrect a student’s foot positions were while learning. This sensor could be mounted on a shoe (Figure 1-16) or within an orthotic insert and in real time measure two angles of the dancer’s feet. And although we’ll look at one sensor to make things easy, multiple sensors are no problem at all. Combined with the haptic feedback provided by using an Apple Watch, the dancer immediately knows whether or not to correct her stance without deviating from her frame.
Figure 1-16. In one of our projects we’ll explore measuring the angles of a dancer’s feet in order to quantify and help perfect her artistic performance
While this is fun, for me anyway, and I hope for you, it’s not really taking on the impact feature I mentioned a couple paragraphs ago. What does it do for humankind? Let’s extrapolate a bit. What if this same sensor were placed on a person at their core or center of gravity and could determine how much they were in or out of balance. More than just tracking falls—anyone remember, “Help, I’ve fallen and I can’t get up?”—this technology, so simple at its origin, can teach us the why of geriatric falls (Figure 1-17). That’s the basics of it anyway; the actual implementation is a touch more detailed, this is the space where I find the motivation to get up in the morning and get started. And it’s not just my uncle or your grandmother; this type of creativity potentially helps everyone. Quickly, let’s look at a few statistics. According to the National Council on Aging, one-third of Americans aged sixty-five and older fall each year. Every thirteen seconds an older adult is treated in the emergency room for a fall, and every twenty minutes an older adult dies from a fall. From a fiscal standpoint the numbers get worse in a few years. In 2013 the total cost of fall injuries was $34 billion and is expected to be over $60 billion in 2020. Passion and impact plus financial opportunity; that’s what we want to look for when choosing our future. It’s not about just doing what makes you happy or becoming a millionaire. Make the difference that you want to see happen in an occupation that affords you all you need to be happy.
Figure 1-17. More than just work, the things we do, the devices we make, and the software we write can deliver an impact that changes lives for the better. For me, making a difference is why I do what I do
My goal throughout this book is for you to find your motivation, or more specifically, your passion. Maybe it’s in sports performance, or rehab because your grandparents are getting older and you care about them. Maybe your passion lies somewhere else altogether that I have no concept of. Whatever it is, wherever it lies, seek it out, and when you can, use your newfound skills to do what you truly love.
You can do it. Just get started.