13

Releasing on the App Store Written by Marin Bencevic

If you’re reading this book in order, by now you have a pretty good grasp of how to bring an iPhone or an iPad app to macOS. Now it’s time for the next step: Getting the app in the hands of users.

The good thing about Catalyst is that once you have a Mac app, it’s your choice what to do with it. There are three ways you can distribute your app to your users:

• The App Store: The Mac App Store works almost the same way as the one on iOS. All existing iOS apps already follow Apple’s app review guidelines, so you should have no issues going through app review. You can either release your app as a standalone Mac App Store product or offer a universal purchase so that your customers can buy your app on one Apple platform and have it everywhere else.
• Third Party Distribution: As long as you sign the app and get it notarized by Apple, anyone can simply download and launch the app. The distribution, in this case, is up to you.
• Developer Signing: Similar to third party distribution, this option requires that you sign your app with a development certificate. The certificate includes a whitelist of specific devices that can install the app, so you can’t use this for distributing to the general public. Since macOS doesn’t have TestFlight support, this is your best bet for testing the app while it’s in development.

Updating existing Catalyst apps

If you made your Catalyst app in Xcode 11.3 or earlier, there are a few steps you need to take to get your app up to speed. Before Xcode 11.4, Catalyst apps had an automatically-assigned bundle ID with a maccatalyst. prefix. If you want to offer universal purchase or just want a custom bundle ID, you’ll have to make a quick change. Go back to your main target’s settings and open the Build Settings tab. Scroll down to the User-Defined section and set DERIVE_UIKITFORMAC_PRODUCT_BUNDLE_IDENTIFIER to NO. This will tell Xcode to stop generating a bundle ID automatically, and let you change the bundle ID in the Signing & Capabilities tab. From there you can decide how you want to distribute your app.

The App Store vs. third party distribution

Since developer signing is only for testing, you’re probably trying to decide whether to use the App Store or distribute the app on your own. There are pros and cons to each approach. The App Store has several benefits including:

• Apple manages the storage and distribution of the app.
• Apple handles payments, including the initial purchase of the app, in-app purchases and subscriptions. They also manage complaints and refunds.
• You can offer a universal purchase and make your app available on both iOS and macOS with a single purchase.
• There’s a chance that Apple might feature your app, giving you access to a lot of users that otherwise might not have heard of the app.
• You get access to App Store’s analytics and crash reporting with no additional effort.

That said, distributing on the App Store does come with downsides:

• Most notably, Apple takes a cut from all App Store sales (30%), subscriptions (30% then 15% after a year) and in-app purchases of digital goods (30%).
• You’re tying the app’s destiny to Apple’s. If they decide to move the App Store in a different direction, you get no say. Apple could potentially hurt your sales or make your app unavailable.
• It limits your business model options. Offering dynamic or tiered pricing, enterprise deals, or other more creative business models can be difficult or impossible.

While Apple takes a sizable cut of your income, it also gives you the most convenient way to sell your app. It’s your choice whether to invest significant effort and be the master of your destiny or save time by letting Apple take care of distribution for you.

If you really can’t decide, Apple lets you sell your app on your own and on the App Store at the same time.

The chapter you’re reading right now will teach you how to distribute your app on the App Store, as well as how to offer a universal purchase. The next chapter deals with distributing your app on your own. If you need help deciding, read both chapters and see how you feel after you know what goes into both approaches.

In other words, now that you’ve got your app — it’s time to make it rain!

Offering a universal purchase on the App Store

By default, Xcode sets up your project to offer a universal purchase, meaning that users buying your app on the iOS app store will get it for free on macOS. With this approach, you might forego the income you’d usually get from a single user, but you give your users a better experience and a better value for the same price. If your macOS and iOS apps are the same and there’s a reason to expect users to want to have both versions, consider offering a universal purchase. This section covers the steps you need to take to make your app available in both stores. Later in this chapter, you’ll see how to sell your macOS app separately.

The process of distributing your app via the App Store is tedious but simple. All you have to do is click a bunch of things! Before you get started, take note of some basic terminology you’ll need when going through this process.

Code signing

Xcode does a good job of automatically code signing your app. As the name suggests, code signing is a way of verifying that you’ve written the code inside the app and it hasn’t changed since you wrote it. Code signing is required before a user can install an app on a device. Your signature is a distribution certificate which you get from Apple and is unique to your developer account.

However, the certificate alone is not enough. You also need an App ID: A value that uniquely identifies your app among all other apps on the App Store.

Together, your App ID and distribution certificate make up a provisioning profile that you include in the app’s binary. The profile verifies that (a) this is your unique app and (b) it was signed by you and didn’t change after that signing.

You can see all of these parts in Xcode. Open the starter project (or the app you want to distribute). In the Project navigator, click on the name of the project and then on the app target. Open the Signing & Capabilities tab.

You can see all the relevant information for signing your app under Signing. The Provisioning Profile is the same for both iOS and macOS. This makes macOS distribution much simpler.

Setting up an App ID

The first thing you need to do is create an app ID for your app. You can do that in Apple’s developer portal. Head over to developer.apple.com, and click on Account in the top-right corner. Log in with your Apple Developer ID.

Once you’ve logged in, navigate to Certificates, IDs & Profiles and then to Identifiers.

Click the + button next to the header to add a new app ID. Select App IDs and click Continue.

On the next screen, select App as the type. Next, for the Bundle ID, enter the one you saw earlier in Xcode. The Description isn’t public — it’s to help you remember which identifier is which — so pick something memorable. Click Continue.

Note: If you’re using features like CloudKit, push notifications or other capabilities, this screen is where you should enable them. Most of them are self-explanatory and if you don’t know what they are, you probably don’t need them. You can also enable these later.

The next screen is just an overview of the App ID. If everything looks good, click Register. Now, you have a fresh App ID that you can use to create a new app on App Store Connect.

Adding an app entry

Note: If you already have an existing app entry on App Store Connect, skip to the next section.

App Store Connect is where your app’s binary meets the App Store. This is where you create new App Store apps, add data like the app title, description or screenshots and — most importantly — upload and release the app.

Head over to appstoreconnect.apple.com and click My Apps. Click on the + button in the top-left corner and select New App.

For the Platforms select macOS and, optionally, iOS. Now comes one of the most important decisions of your app’s life: its name. This is the name that will appear on the App Store. Call upon your inner Don Draper and enter something short but catchy. I’ll enter “Journalyst, An app to remember”. See what I did there?

The Primary Language determines which language to use to display the app’s name and description if there’s no localization for the user’s locale. For the Bundle ID, choose the one you just created in the Developer Portal.

At this point, you might be thinking “What the heck is an SKU?” This is short for Stock Keeping Unit, and it comes from the retail world, where each product would have a number to identify it. All you need to know is that this should be a value that’s unique among your applications. Your bundle ID will do just fine, but feel free to use whatever identifying system you like.

User Access refers to members of your development team. It determines which of your colleagues will be able to edit the app’s information. I’ll choose Full Access because my team of experts consists of only one developer — me. :]

Note: Don’t worry about getting something wrong. You can change all of this later, except for the SKU.

Finally, click Create to make a new app entry.

Welcome to your app’s dashboard!

There are four tabs at the top of the dashboard:

• App Store contains everything related to your app’s presentation on the App Store. This includes the app’s title and description, keywords, prices and released app versions.
• Features is where you can add information related to different app services, like in-app purchases, game center groups, etc.
• TestFlight lets you manage beta versions of your app and distribute them to your testers.
• Activity shows all of your uploaded builds as well as user ratings.

The next step is to upload your 1.0 build.

Uploading a build

Note: While macOS Big Sur is still in beta, Xcode will not allow you to upload builds to the store. The following instructions are based on previous versions of macOS and may change before Big Sur is released. Once that happens, this section will be updated with the latest information.

Your app entry can hold apps for multiple platforms, as well as versions of each of those apps. To add a macOS app, click Add macOS App in the sidebar on the left of your app’s dashboard. You’ll see a new macOS App section and a new version called 1.0 Prepare for Submission. You now have a place to upload your app.

Next, it’s time to go back to Xcode to upload a new build of your app to App Store Connect.

First, make sure your project compiles without any errors. Then, in the menu bar go to Product ▸ Destination and make sure you’ve selected My Mac. Click Product ▸ Archive. This compiles your app and creates an executable that you can upload to the app store. Depending on the size of your app, this process might take a few minutes, so make sure to bring snacks! :]

Once it has finished archiving, Xcode will open the Organizer and show your app’s archives. Select the one you just created.

First, click Validate App. Make sure you’ve checked the checkmark for uploading symbols and click Next. Select Automatically manage signing and click Next again. On the next screen, Xcode will ask you to generate a Mac Installer Distribution certificate. Check that checkbox, and click Next.

Xcode will create a new Mac Distribution certificate and store it in your Keychain. I recommend you click Export Signing Certificate… and save it somewhere secure. This allows you or your colleagues to make builds from other machines, as long as you send them the certificate. Click Next. Make sure you’ve checked Generate an Apple Distribution certificate and click Next again. Export that one too and — you guessed it — click Next.

Finally, you’ll see an overview screen of your app’s package. Click Validate to make sure there are no issues with the app.

Now you’re back to where you started, in the organizer window. It’s time to upload the app by clicking the big blue Distribute App button. Select App Store Connect and click Next. Select Upload and click Next again.

I did promise that uploading to the app store is just clicking a bunch of buttons, didn’t I?

Make sure you’ve checked the checkbox for uploading symbols and click Next. Select Automatically manage signing and on the next screen, click Upload. Depending on your connection, this might take a while, so give your clicking finger some rest.

Once it’s uploaded, go back to App Store Connect and open your newly created app. In the sidebar, click on 1.0 Prepare for Submission under macOS App. This is where you’ll edit all the information about the 1.0 version of your app.

There’s a bunch of fields to fill out here. Here’s some basic information about the most important fields:

• App Preview and Screenshots: These are videos and screenshots of your app. For macOS, the screenshots need to be 16:10 and can only be a specific set of predefined resolutions, as described in the Screenshot specifications under Mac at the following website: apple.co/2KcRFZK. App previews should be 1080p videos with some additional requirements described here: apple.co/2twCcJL.
• Promotional Text: This bit of text shows up under the title of your app. It’s a short description of what the app does. Aim for something that will make the user click on your app.
• Description and Keywords: These are very important for ASO or App Store Optimization. If you describe your app well and choose suitable keywords, it can make your app show up more prominently when users search for related terms.
• Build: This is where you select which uploaded binary of your app you’re releasing. Click on the + button, select the 1.0 build you uploaded earlier and click Done.
• App Review Information: This is where you can write notes for the person reviewing your app. I trust you took a good look at the App Store Review Guidelines (apple.co/1lz8Lit). If your app does things that would make a reviewer suspicious, make sure to explain why you’re not breaking any guidelines here. Also, if your app has login functionality, create a fake user and provide the username and password. This saves the reviewer time and reduces your chances that they’ll reject your app for silly reasons.

The rest of the fields should be self-explanatory. It may seem like a lot of information, but investing time in getting your metadata right could be the difference between a hit and an app nobody ever heard of.

If your app is free, that’s all you need to fill out. Feel free to skip the next section. If you have a paid app, take a look at the following section on how to price your app.

Pricing your app

While you’re in the App Store tab, head over to Pricing and Availability in the sidebar. You can set up the price of your app under Price Schedule. You can choose from almost 100 different pricing tiers for your app. Each of the tiers has a roughly similar price in all currencies. Once you select a price you can click on Other Currencies to see the exact values in each territory.

You can also make your app available for pre-order. This makes your app show up in the App Store even before you release your first version.

If you want to charge a subscription price or offer in-app purchases, you can do that by clicking Manage under In-App Purchases in the sidebar.

Submitting for review

Once you’ve filled everything out, click Save in the top-right corner and then click Submit for Review. A reviewer from Apple will take a look at your app to make sure you’re following the guidelines. This can take up to a few days. I know, there’s something very frustrating about having a completed app that’s just sitting there waiting to be reviewed. Hang in there!

Once your app passes the review, you should get an email notification and the name of the version will change to 1.0 Pending Developer Release. In the top-right corner, you should see a new button titled Release This Version. Click that button and pop a bottle of champagne! You just released an app!

Keep in mind, the App Store might need a few hours to propagate your app, so make sure to wait a while until you start telling all of your friends.

Note: Your app won’t be available for universal purchase until you fully release your app on at least two platforms.

Selling your macOS app separately

Instead of offering a universal purchase, you can also sell your macOS app completely separately. You can do this by using a different bundle ID for your macOS app. Head back to Xcode and, from the Project navigator, click on the name of the project and then on the app target. Open the Signing & Capabilities tab. Uncheck the Use iOS Bundle Identifier checkbox and enter a new bundle identifier for your macOS app.

Note: You may have to delete the build setting DERIVE_UIKITFORMAC_PRODUCT_BUNDLE_IDENTIFIER in order to change the checkbox.

You can distribute your app on the Mac App Store by repeating the steps described in the previous section using this new bundle ID.

Key points

• You must sign each app with a provisioning profile, which combines a certificate with an app ID.
• You create app IDs in Apple’s Developer Portal.
• Manage the app on the App Store by going to App Store Connect.
• Upload new builds from Xcode.

Where to go from here?

To make sure you’re not violating any of Apple’s guidelines, make sure to carefully read through Apple’s App Store Review Guidelines: apple.co/1lz8Lit. Apple also provides a helpful list of common app rejection reasons, which you can use as a checklist before submitting: apple.co/2ltWgeB.

Now that you have a grasp on how to upload new builds, think about automating this for continuous integration by using tools like Jenkins and Fastlane. You can see an example of how to do this for iOS apps in the Continuous Integration tutorial: bit.ly/2YT52pa.

Since you uploaded your app to the App Store, it’s time to think more about optimizing it for App Store’s search. Apple provides some useful tips on their site: developer.apple.com/app-store/search/.

Finally, make sure to spread the word about your app anywhere you can! App-making is a tough business, so good luck out there. The whole raywenderlich.com Team is rooting for you! :]