Chapters

Hide chapters

iOS App Distribution & Best Practices

First Edition · iOS 14.4 · Swift 5.3 · Xcode 12.4

Section I: iOS App Distribution & Best Practices

Section 1: 17 chapters
Show chapters Hide chapters

Section II: Appendices

Section 2: 2 chapters
Show chapters Hide chapters

2. Your First App in the App Store
Written by Pietro Rea & Keegan Rush

If you’ve never published an app to the App Store, it may seem like there is an endless list of things you need to do before users can download your app. In this chapter, you’ll learn about the basic concepts related to the App Store and go through the process of uploading your first app to the App Store.

You can think of the first and the second chapters as an overview to get you started as fast as possible. Here are a few things to keep in mind as you work through the first two chapters:

  • The chapters assume that you don’t have any previous knowledge about App Store publishing. It’s perfectly fine if you’ve only ever interacted with the App Store as an end-user.

  • You might already have some prerequisites set up, like an Apple ID or an Apple Developer Program membership. Don’t worry — the sections that cover prerequisites are short and you’ll have them here if you ever have to do that again. Feel free to skip them if you need to.

  • The first two chapters focus on everything you have to do after you’re done coding so you won’t see any code samples. The content is technical but you don’t need to be a developer to follow along.

  • The first two chapters cover the “happy path” for App Store submission. Your particular situation might include special cases that are covered in later chapters. If you get stuck, you can expect to see “exit ramps” that point to other chapters. Feel free to skip ahead and come back if you need to.

  • Automated App Store submissions is a primary goal in this book, but you’ll find no automation in the first two chapters. Doing everything manually first helps you understand what to automate later on.

This first chapter walks you through setting up your developer account and uploading your app to the App Store. The next chapter walks you through working with the App Store’s “admin interface” to submit your app for App Review.

Without further ado, the first thing you need to do is create an Apple developer account.

Creating a developer account

The App Store’s success is built on trust. Trust between Apple and end-users and between Apple and developers. Practically speaking, this means Apple needs to know who you are.

Here are four things you need to do before you can submit apps to the App Store:

  1. Create an Apple ID and enable two-factor authentication.
  2. Enroll in the Apple Developer Program.
  3. Download and install Xcode.
  4. Configure your app in the App Store’s backend system (covered in the next chapter).

Creating an Apple ID

An Apple ID identifies a user in Apple’s ecosystem. You use your Apple ID to log into Apple devices, synchronize between devices and pay. If you use an Apple product, you most likely already have one.

Every Apple developer account is also backed by an Apple ID. On top of everything you can do with an Apple ID as an end-user, a developer account also gives you access to tools and resources that are not publicly available. Developer accounts also grant you special privileges, like the ability to publish your work in the App Store.

Since you probably already have an Apple ID, the more relevant question you should answer is, “should I create a separate Apple ID for my developer account”?

That depends! There are several setups to choose from. You can have multiple Apple IDs and multiple developer accounts if you work for multiple organizations. Or you can use one Apple ID for everything, or one for your personal apps and one for your professional apps.

An app in the App Store is tied to a developer account and the developer account is forever tied to its Apple ID. It’s cumbersome, although possible, to transfer an app to another developer account, but you’ll save yourself a lot of headaches if you choose an appropriate setup for your situation.

This decision tree can help you decide if you need to create a new Apple ID.

Use your Apple ID if your app’s primary purpose is to learn, or if you work for yourself, don’t ever see yourself expanding the business past yourself and don’t want the hassle of opening a separate legal entity.

In every other case, it’s better to create a new Apple ID for your new developer account.

You can create a new Apple ID directly on an iOS, iPadOS or macOS device, or you can also use Apple’s web interface at appleid.apple.com. You also need to enable two-factor authentication on your Apple ID.

Note: Apple has good documentation on account creation. Keep these links handy if you need to create a new Apple ID.

How to create a new Apple ID: https://apple.co/2S18AzU.

Two-factor authentication for Apple ID: https://apple.co/3kIy1CA

The video course Publishing to the App Store on raywenderlich.com also walks through the process of creating a new Apple ID if you prefer a video format.

Enrolling in the Apple Developer Program

After you decide which Apple ID to use, the next step is to enroll in the Apple Developer Program. As of WWDC 2020, Apple has over 24 million registered developers. This group includes big names like Facebook and Netflix, as well as all the indie developers you know and love.

The best way to think of the Apple Developer Program is as a bundle of tools and resources. When you enroll in the developer program, you get access to the following:

  • Software development kits (SDKs) for all Apple platforms.
  • Beta versions of the SDKs and developer tools when available.
  • Advanced app capabilities like In-App Purchases, push notifications and CloudKit.
  • Developer relations and editorial support. Entire teams at Apple support developers and feature the best apps on the App Store.
  • Code-level support. You can ask two detailed code-level questions per year.
  • Special programs and events like the option to attend WWDC.
  • App Store distribution.

Enrolling in the Apple Developer Program costs $99 per year and you pay for it using the Apple ID you picked in the previous section.

You only need to enroll and pay once per team. If you’re joining an organization that has already enrolled in the Apple Developer Program, you don’t need to pay separately. Someone in your organization can invite your Apple ID to their existing team and you’re good to go.

Note: You need a paid Apple Developer Program enrollment to publish apps to the App Store. If you primarily want to learn how to develop on Apple’s platforms, Apple also provides a free option.

You can’t use advanced platform features like push notifications or CloudKit with free enrollment but at least you can build and install your apps on your devices.

Apple’s documentation lays out the benefits for each type of enrollment.

https://apple.co/303Kt8j

Apple provides thorough documentation on how to enroll in the Apple Developer program, so this chapter does not cover it step by step.

You can enroll in the Apple Developer Program either on the web at developer.apple.com or by using the Developer app on iOS, which you can download from the App Store.

Apple supports two types of enrollments. Each has different legal, tax and financial implications, so make sure to pick the enrollment type that best suits you.

  1. Individuals/sole proprietorship. Publish apps under your personal name or a sole proprietorship. In this setup, you personally enter into legal agreements with Apple. This is a good option if you decided to use your personal Apple ID in the previous section.

  2. Organization. Publish apps on behalf of a company, non-profit or some other type of organization or legal entity. If you’re publishing an app for your employer, you should pick this option. In this setup, a separate legal entity enters into contracts with Apple.

Note: If you’re enrolling as an organization, you need to sign up for a D-U-N-S number through Dun & Bradstreet before you can complete your enrollment. Getting a D-U-N-S number is free but requires a verification call.

https://apple.co/308Ikbq

Apple designed the App Store’s internal tools to accommodate teams of all sizes — from solo developers to large teams with specialized roles. When you complete the enrollment, you automatically become your team’s Account Holder.

Here’s the full list of roles you can expect to see:

  • Account Holder (that’s you!)
  • Admin
  • App Manager
  • Developer
  • Finance
  • Marketing
  • Sales

There are certain tasks only the Account Holder can do, like renewing the yearly membership and accepting legal agreements. If you’re the Account Holder, be prepared to log into the developer portal periodically to perform administrative chores. Lucky you!

Note: The Account Holder role used to be called “Team Agent”. If you come across the older name in forums or blog posts, know that they are the same.

Using the correct developer account

There is one common problem with developer accounts worth mentioning. Whenever you start a new project, make sure you identify the app’s publisher and use the app publisher’s Apple developer account.

This sounds obvious, but sometimes the publisher and the developer are not the same.

Consider this common scenario: National Geographic wants to publish a new iOS app, but they don’t have any iOS developers in-house.

They hire your company, Acme Apps Inc., to develop the app for them. You develop the app in record time using your company’s developer account. When you submit the app for review, Apple rejects it. Why?

Apple wants to make sure everyone on the App Store is who they say they are. In this made-up scenario, National Geographic and Acme Apps are working together. But, you can easily imagine a scenario where a bad actor tries to impersonate National Geographic. This is why Apple rejects any app that’s not submitted by the app publisher’s developer account.

Practically speaking, even though you or your employer might already have enrolled in the Apple Developer Program, if you are a contractor or consultant, you have to use your client’s Apple Developer account. If they don’t have one, you need to help them create one.

Installing Xcode

Next, you need to download Xcode. In case you’re not a developer or have not worked with Xcode before, Xcode is the de-facto app to develop software for Apple’s platforms.

Xcode is primarily a programming tool, but it also uploads apps to the App Store. There are two versions of Xcode to choose from:

  1. The current version. Xcode is an app just like any other app and Apple publishes the current version on the macOS App Store. If your app doesn’t rely on pre-release features of the SDK, download Xcode from the App Store.
  2. The gold master (GM) version. When Apple is close to releasing new versions of their SDKs, they release a special version of Xcode to upload apps that rely on pre-released SDK features. Most people don’t fall into this category. But if you need the GM, you can get it from the developer portal.

Note: There are also beta versions of Xcode that you can download from the developer portal. Beta versions are primarily used for testing and development. You can’t upload and distribute apps to the App Store with them.

For this chapter, you’ll use the current version of Xcode. Open the App Store on your Mac, search for “Xcode” and click Download.

Xcode is a big download, so you might want to grab a cup of your favorite caffeinated beverage while you wait.

In later chapters, you’ll work with a production-ready app. In the first and second chapters, however, you start from a brand new project so you can see how to configure everything from scratch.

Open Xcode once the download completes. Xcode asks you if you want to install additional components. You can’t move forward without them, so click Install.

Next, select Create a new Xcode project from the Xcode helper screen.

Select the App iOS template from the app-modal dialog and click Next.

Fill out raywenderlich as the Product Name. Add your Organization Name and Organization Identifier and click Next.

The Organization Identifier is usually the reverse DNS notation of the app publisher’s website (e.g. “com.raywenderlich” in this example).

Your Organization Identifier followed by your Product Name represent your app’s bundle identifier or bundle ID.

In this case, the bundle ID is com.raywenderlich.raywenderlich. It’ll be different for you since your Organization Identifier is different.

Note: A bundle ID uniquely identifies an app throughout Apple’s systems. In other words, no other app on the App Store can currently be using your app’s bundle ID.

Also note that you can’t change your app’s bundle identifier later on, even if you sell your app. Don’t use your personal name in the bundle ID unless you personally are the app’s publisher.

Now that your project is set up, open the Project Navigator and click the blue raywenderlich project file. Open the Signing and Capabilities tab as shown below.

The checkbox next to Automatically manage signing is checked. Leave this default as is.

You’ll also notice a warning saying that the app requires a development team. To resolve this issue, you have to sign into Xcode with the Apple ID you enrolled in the Apple Developer Program.

Click on Xcode ▸ Preferences… in the menu bar or use the shortcut Command + , to open Xcode’s preferences screen.

Click on the Accounts tab on top, select Apple ID from the list and click on Continue.

Enter your login credentials.

Once you’re logged into Xcode, if you enrolled as an individual your name appears next to the Account Holder role.

If you joined an existing organization or enrolled as one, you’re part of at least two teams.

The first team is your personal team, which is the free developer program. The second team is the paid Apple Developer Program enrollment. The role you see next to your name depends on your team assignments. Your Apple ID can be associated with several teams and you can have a different role on each team.

Select your paid account. Click Manage Certificates. Then, click the + button on the lower-left corner. Afterward, click the Apple Development option.

You just created a development certificate, which you need to install the app on your personal device.

Note: You’ll come across terms you probably haven’t seen before, like certificate and code signing. In broad terms, these are Apple’s way of cryptographically verifying you and your app.

If you run into an issue with certificates or code signing, you can refer to Chapter 4, “Code Signing & Provisioning”.

In the project navigator, select your project file. Then, click the raywenderlich target and open the Signing & Capabilities tab.

Now that you’re signed in and have a development certificate, select your team from the Team dropdown. The warning indicator disappears.

Installing the app on a device

Plug in your Apple device to your Mac. This can be an iPhone, iPad or iPod touch. From this point on, the chapter will use the term “iPhone” instead of “device”.

Your iPhone prompts you about trusting the computer to share data with it. Tap Trust to continue. If you have set a passcode on your iPhone, you’ll be prompted to enter that.

Back in Xcode, click the Scheme pop-up menu in the toolbar next to raywenderlich and scroll up to Devices. Select your iPhone from the list.

The Scheme pop-up menu lets you select your build destination.

Note: If your iPhone is grayed out with an error message of “OS version lower than the deployment target”, update your device’s operating system in the iOS Settings app.

With your iPhone selected, click the Run button in the toolbar to install the app on your phone. Xcode asks you if you want to register your device with your developer account. Click Register Device.

Xcode starts processing your app. Towards the end, you see an alert telling you that an executable called codesign needs your keychain password to continue.

This is your Mac’s password, not your Apple ID password. Type in your password and click Always Allow.

codesign adds a cryptographic signature to your app so Apple can make sure no one has tampered with it once a device wants to install it.

Xcode now finishes processing the app and successfully installs it on your iPhone. Hooray!

If you’ve followed the steps so far, the app is just a blank screen. Remember that the first two chapters only focus on the parts of the process related to submitting an app to the App Store, not on the app itself. You’ll get to work with a real app in later chapters.

Creating your distribution certificate

Xcode can install the app on your iPhone, but it currently can’t submit it to the App Store. You’ll learn to do that next.

The first thing you need to do is to create a distribution certificate. The steps are similar to the ones you followed for your development certificate.

To open Xcode preferences, click Xcode ▸ Preferences… in the menu bar or press the Command + , shortcut.

With your paid Apple Developer Program team selected, click Manage Certificates like before. Click the + button like before. But this time, select Apple Distribution.

Your new distribution certificate now shows below the development certificate you’ve already created.

Uploading your app with Xcode

Uploading to the App Store becomes second nature over the years. But if you’re doing it for the first time, the process can be unintuitive. Before you begin, it’s a good idea to get a general understanding of what you’re about to do so you can internalize the steps as you go along.

When you submit an app to the App Store, you’re submitting a build of the app. Unless you’re a developer, you might not have heard this term before, but you’ll see it often throughout the book.

In simple terms, a build is an executable program that contains everything your app needs to run on a device: the compiled source code, embedded artwork, even the app icon!

It’s called a “build” because Xcode goes through a multi-step process, grabbing bits and pieces from different files and directories and cobbles them together into a completed product. Developers also use “build” as a verb: “Xcode builds, installs and runs the build”.

Note: Technically speaking, you upload an archive of your app. An archive is a build with additional debugging information.

Colloquially, developers use the term “build” for everything, so that’s what you’ll see in the rest of the book.

Once you create a distribution build using Xcode, Apple doesn’t just let you drag this build onto the developer portal. You have to use Xcode again to securely transfer your build to the App Store.

That’s enough theory for now. Open Xcode. Set the build destination to Any iOS Device (arm 64). Unlike other options, this build destination doesn’t represent a physical device or simulator. It’s a special configuration that tells Xcode you just want to create a build, not install it.

Next, click Product ▸ Archive in the menu bar.

Once Xcode finishes building the archive, a new window pops to the front. This window is called the Organizer and it manages the archived builds of the different apps that you work on.

If this is the only app you’ve ever worked on, clicking the top-left dropdown menu shows only one entry under iOS Apps.

Next, click Distribute App on the right-hand side to begin uploading your build. The next screen asks you about the method of distribution.

Select App Store Connect and click Next. Don’t worry if this is the first time hearing about App Store Connect. That’s the official name for the App Store’s admin interface for developers. The next chapter covers App Store Connect in detail.

Note: You might be surprised that there are so many ways to distribute an app! Apple builds general computing devices that serve all kinds of needs and they’re not all served by the App Store.

Chapter 5, “Internal Distribution,” covers all the different ways you can distribute your app — the App Store is one of several ways.

The next screen asks you if you want to upload or export your archive. Leave Upload selected and click Next.

Note: You might be wondering why you’d ever want to export an archive instead of uploading it to App Store Connect. Xcode is not the only way to upload a build to the App Store.

You can also use the command line or Transporter, another app made by Apple. If you want to use these alternatives, you’d need to export a signed archive in this step.

Leave the defaults on for the next screen. You want to include bitcode and upload your app’s symbols to Apple.

Turning bitcode on improves the performance of your app. The term “symbols” refers to the human-readable names that developers used in code. You need to upload these “symbols” to make sense of incoming crash reports.

The next screen informs you that your build needs to be resigned for distribution. Leave the default on to let Xcode automatically manage signing.

codesign might prompt you again for a password in Keychain Access. Type in your Mac’s password to grant codesign access.

Verify all your selections on the review screen. If everything checks out, click Upload.

And now the moment of truth…you’ve created a distribution build, signed it, selected all the necessary options. Now, you sit and wait for the upload to…

Wait for a second — the upload failed with the error message, “No suitable application records were found”.

There are so many configurations in Xcode and App Store Connect that it’s easy to misconfigure or miss some of them. This means you’re likely to see errors at least once in your journey to the App Store.

Don’t worry — this is normal and Apple usually gives you a detailed explanation about what went wrong.

In this case, you did everything right on Xcode’s end but didn’t configure App Store Connect. You threw the proverbial ball, but there was no one on the receiving end to catch it!

Even though there’s more to do, you’ve covered a lot of ground in this chapter. You’ve set up your Apple ID, enrolled in the Apple Developer Program and created your first distribution build. In the next chapter, you’ll configure App Store Connect, properly upload your build (finally!) and submit your app to App Review.

Key points

  • You need an Apple ID with two-factor authentication enabled to enroll in the Apple Developer Program.
  • You can use your existing Apple ID or create a new one depending on your needs.
  • You can join the Apple Developer Program as an individual or as an organization. Make sure to use the app publisher’s developer account.
  • A bundle ID uniquely identifies your app in Apple’s ecosystem. You cannot use a bundle ID that another app uses.
  • A development certificate lets you install apps on your device.
  • A distribution certificate lets you upload builds to the App Store.
  • Use Xcode to create a distribution build and upload it to App Store Connect.
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.