1. The App Store

Written by Pietro Rea

Before the App Store, distributing software was much harder than it is today. There was a time when developers had to put copies of their apps on floppy disks or CDs and literally “ship” them to the stores. Once most people could reliably connect to the internet, it suddenly became viable to buy, download and install software from the comfort of your own home. The situation improved, but developers still had to build and maintain bespoke checkout, hosting and payment systems.

In 2008, Apple launched the App Store for its newly released iPhone. The App Store introduced the next chapter in software distribution. Developers didn’t need to worry about hosting, collecting payment or fulfilling orders anymore. Apple ensures that all the App Store visitors have a valid payment method on file, eliminating most of the friction from buying apps. Developers could now focus on building great apps and leave the rest to Apple and the App Store.

Beyond simpler distribution, the App Store is also the entry point to the most successful personal computing devices in history: the iPhone, iPad, Apple Watch, Apple TV and the venerable Mac. The App Store economy has grown relentlessly over the past decade and it now represents a huge opportunity for developers.

As of this writing, there are over 1.5 billion active Apple devices. Over 500 million people visit the App Store every week across 175 territories worldwide. Developers have also benefited financially during that time. Apple has paid developers over 155 billion dollars and has facilitated billions more in other transactions. Without a doubt, the App Store is a highly successful marketplace that provides great experiences for users and lucrative opportunities for developers. “Getting in” is a worthwhile challenge.

Third-party apps

Apple is arguably one of the most user-friendly companies on the planet. And Apple’s philosophy around third-party software comes from this user-centricity. Even though Apple doesn’t officially state its philosophy anywhere, the world view that stems from it permeates everything you’ll read about in this book. Whether you agree or not, understanding Apple’s stance will help you navigate the world of app distribution.

Most Apple devices support two large categories of third-party software. The first category is the open ecosystem of the web. Open web standards govern what kind of software you can build for the web and there are no restrictions on what you can build on the web or how you can build it. If you can use it on a mobile web browser like Safari, Apple supports it.

The second category of third-party software that Apple supports is native apps. Unlike the web, which no single entity controls, Apple controls how to build and distribute native apps. You can do almost anything on the web, but when it comes to native apps, Apple has a strong vision for its app ecosystem.

In a nutshell, Apple believes that part of building good apps means protecting end-users from bad actors. As a result, third-party apps should always be mediated to encourage and enforce good experiences for the end-user. “Mediation” in this sense means sitting between third-party apps and end-user as a kind of referee.

By default, third-party apps cannot run on a user’s device without explicit permission. To be able to run, third-party apps have to match up to officially-supported user needs. The end-user can only install third-party apps for pre-approved reasons on pre-approved devices. This is why third-party developers can only distribute native apps to the public using the App Store.

Apple’s vision for its third-party app ecosystem is a conscious strategy with many trade-offs. An obvious trade-off is the complexity of app distribution. Apple only wants good, safe, user-friendly third-party apps on the App Store, and the controls they have to enforce this can make life difficult for app developers.

App lifecycle

You might think publishing an app on the App Store is like a straight line, going from step to step until you are done. In reality, an app (like any piece of software) needs testing, bug fixes and improvements. As the saying goes, software is never done!

Once the first version is available and real users start using your app in the wild, you’ll start to receive a stream of feedback — ratings and reviews from the App Store, analytics from your analytics provider, crash reports from Apple and more.

With this feedback, you and your team can decide on the improvements you want to make, the bugs you want to fix and the features you want to add. In terms of app distribution, you have to bundle and distribute these changes into an “app update”.

As you keep working on your app, you realize that publishing and keeping an app in the App Store looks more like a circle than a straight line.

This diagram shows the different steps in the app development lifecycle. In more detail, here’s what each step represents from a distribution perspective:

1. Development: Development just means making the app. Most books about iOS development cover development in detail and leave out the rest of the lifecycle. This book is the opposite. You won’t spend much time reading about how to make the app. Instead, the book focuses on everything other than coding.
2. Upload: Once you’re happy with the app, you package it up and upload it somewhere others can download it. Immediately after development, distribution is usually internal, or at least “pre-release”. You might need to publish internal versions of the app for a product manager, a business analyst or a QA tester.
3. Testing: What to test and how to test is a big topic and also not covered in the book. In the context of distribution, you need to get your app in the hands of testers before anyone tests it manually. You can have internal testers (alpha testers) or external testers (beta testers). Hopefully, the app passes all testing with flying colors, but if not, you can go back to development, upload a new version of the app and test it again.
4. Product Page: Marketing is an important part of distribution. You know your app is great, but you also have to tell others what the app does and why they need it. After development and testing, you get to work on your app’s App Store product page. This includes setting the app’s price, adding screenshots, writing compelling descriptions, and more.
5. App Review: Apple requires every publicly distributed third-party app to go through app review. This includes the initial version of the app as well as every subsequent version that you might ship as an update. Real Apple employees look at your app to make sure it meets the App Store guidelines. If your app doesn’t pass app review, depending on what the problem is, you might have to go back to development and start the lifecycle again.
6. App Store: Once Apple approves your app submission, the approved version becomes available in the App Store! Users around the world can now find it and download it. If you have a paid app, users pay Apple, who then pays you.
7. Analytics: Did your users like your app? Does it have bugs you have to fix? After the release, you can look at analytics, app reviews and crash reports and combine those inputs with your product roadmap to determine what changes to make next. Once you decide what to do, the lifecycle beings again.

If you take “app distribution” to mean “giving your app to others”, then there’s more to distribution than seeing your app on the App Store (step 6). Developers need to compile and install development versions of the app. Internal testers need to install alpha versions of the app. External testers need to install beta versions of the app. Finally, end-users get to install production versions of the app.

Each type of “distribution” has its own set of rules and needs different things from you. This is what this book is ultimately about. In a nutshell, the book teaches you how to give your app to whoever needs it, whenever they need it, throughout the app lifecycle, in the quickest, most efficient way.

About this book

This book isn’t meant to be an all-encompassing App Store distribution manual. It also isn’t a replacement for Apple’s official documentation. Not only would this be a huge task to read and write, but it would also be a fast-moving target. Apple changes its platform every year and many of these changes affect app distribution. The App Store guidelines, the set of rules governing what third-party developers can and can’t do, is also a living document that changes frequently.

What you’ll find in this book is a deeply considered sequence of topics, narrative and advice. The book covers the fundamentals thoroughly so you can build the mental models you need to internalize the hardest parts of the App Store distribution. These mental models will help you for years to come.

The book also covers the best practices and automation. There is no definitive list of app distribution best practices, but over the last decade, teams have converged on similar practices that you’ll read about in the second half of the book.

Who this book is for

No single job description perfectly aligns with third-party app distribution. To complicate matters, the entire job of distributing an app might be chopped up into smaller pieces, with some tasks going to developers and the rest going to non-technical team members.

People with wildly different backgrounds routinely handle app distribution. We kept this in mind while writing the book. We believe that both developers and non-developers can benefit. Some chapters are geared to developers, but we aimed to explain the core concepts from first principles so everyone could learn something new.

When it comes to developers, these three types of developers would benefit the most from this book:

1. Distribution “novices”: Being an app distribution novice is not the same as being a software development novice. The most senior iOS developer at Razeware might still be an App Store novice if she doesn’t deal with the App Store regularly.

The book covers the most common distribution workflows so App Store novices can release their first app without getting bogged down with the details. In particular, Chapters 2 and 3 are a “quick guide” suited for novices with simple use cases.

2. Distribution “expert beginners”: Some apps only need updates once a quarter or once a year, giving you just enough time to forget everything. There are countless app developers who have successfully published an app to the App Store that found the process opaque and frustrating. These developers didn’t come out the other side with a good understanding of app distribution, so they’re likely to have similar difficulties the next time there’s an app release.

After reading this book, the developers who are regularly frustrated with the opaque process of publishing to the App Store will have an easier time debugging their issues. In particular, code signing seems to trip most people up at some point. If this is you, Chapter 8, explains code signing from the ground up so you can finally “get it” once and for all.

3. DevOps and automation engineers: Many things are unique to the App Store, but at the end of the day, building an app is similar to building any other piece of software. There are well-understood modern practices in software engineering, such as continuous integration (CI) and continuous delivery (CD) that can speed up, and generally improve the app lifecycle.

Even though each software development team works slightly differently, there’s a real “convergence” of best practices when it comes to the App Store distribution and automation. Chapter 11 through 13 dive deeper into setting up a build pipeline so you can distribute apps internally and externally without a lot of manual work.

We’ve written this book with the hope that we can help a great number of people involved in an app’s lifecycle exercise the very best practices in sharing their apps with the world.