Heads up... You're reading this book for free, with parts of this chapter shown beyond this point astext.
You can unlock the rest of this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.
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:
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.
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.
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.
Adding an app entry
Note: If you already have an existing app entry on App Store Connect, skip to the next section.
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.
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.
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!
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.
- 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.